Bağımlılık enjeksiyonunun (DI) ve otomatik testlerin büyük bir hayranı olduğumu bilmeme izin verin . Bütün gün bunun hakkında konuşabilirim.

Arka fon

Son zamanlarda, ekibimiz sıfırdan inşa edilecek bu büyük projeyi yeni aldı. Karmaşık iş gereksinimlerine sahip stratejik bir uygulamadır. Tabii ki, güzel ve temiz olmasını istedim, ki bu da benim için kastedilebilir: test edilebilir ve test edilebilir. Bu yüzden DI kullanmak istedim.

Direnç

Sorun ekibimizdeydi, DI tabu. Birkaç kez büyütülmüş, ancak tanrılar onaylamıyor. Ama bu beni caydırmadı.

Benim hamle

Bu garip gelebilir, ancak üçüncü taraf kütüphaneleri mimar ekibimiz tarafından genellikle onaylanmaz (düşünün: " Birlik , Ninject , NHibernate , Moq veya NUnit , parmağınızı kesmeme izin vermezsiniz"). Bu yüzden kurulmuş bir DI konteyneri kullanmak yerine, son derece basit bir konteynır yazdım. Temelde başlangıçta tüm bağımlılıklarınızı bağladı, herhangi bir bağımlılığı enjekte etti (yapıcı / özellik) ve web isteğinin sonunda atılabilir nesneleri attı. Son derece hafif ve sadece ihtiyacımız olanı yaptım. Sonra onlardan incelemelerini istedim.

Tepki

Kısa yapmak için. Ağır bir dirençle karşılaştım. Asıl argüman, “Bu karmaşıklık katmanını zaten karmaşık bir projeye eklememiz gerekmiyor” idi. Ayrıca, "Farklı bileşen uygulamalarına bağlayacağımız gibi değil". Ve "Basit tutmak istiyoruz, mümkünse her şeyi tek bir düzene sokmak istiyoruz. DI faydasız bir istenmeyen karmaşıklıktır".

Sonunda benim sorum

Durumumu nasıl idare edersiniz? Fikirlerimi sunmakta iyi değilim ve insanların tartışmalarını nasıl sunacaklarını bilmek istiyorum.

Tabii ki, benim gibi, DI kullanmayı tercih edersiniz. Kabul etmiyorsan, lütfen nedenini söyle, böylece madalyonun diğer tarafını görebilirim. Aynı fikirde olmayan birinin bakış açısını görmek gerçekten ilginç olurdu.

Güncelleme

Herkesin cevapları için teşekkür ederim. Gerçekten işleri perspektife sokuyor. Size geribildirim vermek için başka bir göze sahip olmak yeterince güzel, onbeş gerçekten harika! Bu gerçekten harika cevaplar ve sorunu farklı açılardan görmeme yardımcı oldu, ancak yalnızca bir cevabı seçebilirim, o yüzden en çok oyu seçtim. Cevap vermeye zaman ayırdığınız için herkese teşekkürler.

DI'yi uygulamak için en iyi zaman olmadığına karar verdim ve buna hazır değiliz. Bunun yerine, tasarımımı test edilebilir hale getirme ve otomatik birim testini sunma girişiminde bulunacağım. Yazma testlerinin ek bir ek yük olduğunu ve ek ek yükün buna değmeyeceğine karar verilirse şahsen, tasarımın hala test edilebildiği için şahsen bir kazanma durumu olarak göreceğimi biliyorum. Ve herhangi bir test veya DI gelecekte bir seçim ise, tasarım kolayca üstesinden gelir.

Bir kaç tane argüman alarak:

"Basit tutmak istiyoruz, eğer mümkünse her şeyi tek bir düzene sokun. DI faydasız, istenmeyen bir karmaşıklıktır".

"farklı bileşen uygulamalarına bağlanacağımız gibi değil".

İstediğiniz şey sistemin test edilebilir olması. Kolayca test edilebilmelidir projenin (veritabanı, iletişim vs.) çeşitli katmanlarını alay bakıyor olması ve bu durumda ihtiyacınız olacak bileşenlerin farklı uygulamalarda takmayı olun.

DI'yi size sunduğu test avantajlarından satınız. Eğer proje karmaşıksa, iyi, sağlam birim testlerine ihtiyacınız olacak.

Diğer bir avantaj, arayüzlere kod yazarken, bileşenlerden birinin daha iyi bir uygulamasını (daha hızlı, daha az belleğe aç, ne olursa olsun) bulabilirseniz, DI kullanarak eski uygulamaların yerini almayı çok daha kolaylaştırır. yeni.

Burada söylediğim şey, DI'nin uğruna DI için tartışmak yerine DI'nin getirdiği yararları ele almanız gerektiğidir. İnsanların ifadeyi kabul etmelerini sağlayarak:

"X, Y ve Z'ye ihtiyacımız var"

Sonra sorunu değiştiriyorsun. DI'nin bu ifadeye cevap olduğundan emin olmanız gerekir. Bunu yaparak iş arkadaşlarınız, onlara dayatılan hissini vermek yerine çözüme sahip olacaksınız.

Yazdıklarınızdan, DI'nin kendisi tabu değil, farklı bir şey olan DI kaplarının kullanılmasıdır. Sanırım ekibinizle, örneğin yapıcı tarafından ihtiyaç duydukları diğer bileşenleri geçiren bağımsız bileşenleri yazarken hiçbir sorun yaşamayacaksınız. Sadece "DI" deme.

Bu tür bileşenlerin DI kap kullanmamalarının sıkıcı olduğunu düşünebilirsiniz ve haklısınız ancak ekibinize bunu bulmak için zaman verin.

Sizden beri, ekibinizin DI'ye karşı tarafını ele alacağım.

Bağımlılık Enjeksiyonuna Karşı Dava

"Enerjinin Korunması" adlı fizikte kurala benzeyen "Karmaşıklığın Korunması" olarak adlandırdığım bir kural var. Hiçbir mühendislik miktarının bir soruna optimal bir çözümün toplam karmaşıklığını azaltamayacağını, yapabileceği tek şeyin bu karmaşıklığı etrafında kaydırmak olduğunu belirtiyor. Apple'ın ürünleri Microsoft'tan daha az karmaşık değildir, yalnızca karmaşıklığı kullanıcı alanından mühendislik alanına taşır. (Yine de kusurlu bir benzetme. Enerji üretemezken, mühendisler her dönüşte karmaşıklık yaratma alışkanlığına sahipler. Aslında, birçok programcı karmaşıklık eklemekten ve sihir kullanmaktan hoşlanıyor gibi görünüyor.tanımlayıcı olarak, programcının tam olarak anlamadığı bir karmaşıklıktır. Bu aşırı karmaşıklık azaltılabilir.) Genellikle karmaşıklığı azaltmak gibi görünen şey karmaşıklığı başka bir yerde, genellikle bir kütüphaneye kaydırmaktır.

Benzer şekilde DI, istemci nesnelerini sunucu nesnelerine bağlamanın karmaşıklığını azaltmaz. Yaptığı şey onu Java'dan çıkarmak ve XML'e taşımak. Bu, her şeyi bir kod (veya birkaç) XML dosyasına / dosyalarına merkezileştirmesidir, burada olan her şeyi görmenin kolay olduğu ve kodları yeniden derlemeden bir şeyleri değiştirmenin mümkün olduğu yerlerde. Öte yandan, bu XML dosyaları Java olmadığından ve bu nedenle Java araçları için kullanılamadığından kötüdür. Onları hata ayıklayıcıda hata ayıklayamazsınız, çağrı sıradüzenlerini izlemek için statik analiz kullanamazsınız. Özellikle, DI çerçevesindeki hataların tespit edilmesi, tanımlanması ve düzeltilmesi oldukça zorlaşır.

Bu nedenle DI kullanırken bir programın doğru olduğunu kanıtlamak çok daha zordur. Birçok insan DI'yi kullanan programların test edilmesinin daha kolay olduğunu iddia eder , ancak program testlerinin hiçbir zaman hata bulunmadığını kanıtlayamayacağını iddia eder . (Bağlantılı makalenin yaklaşık 40 yaşında olduğunu ve bazı gizli referanslara sahip olduklarını ve bazı güncel olmayan uygulamalardan alıntı yaptıklarını, ancak temel ifadelerin çoğunun hala geçerli olduğunu unutmayın. Özellikle, P <= p ^ n, P sistemin hatasız olma olasılığı, p bir sistem bileşeninin hatasız olma olasılığı ve n bileşenlerin sayısıdır elbette, bu denklem basitleştirilmiştir, ancak önemli bir gerçeğe işaret etmektedir. Facebook IPO sırasındaki NASDAQ kazası, yeni bir örnek.kodu test etmek için 1000 saat harcadıklarını ve hala çökmeye neden olan hataları çözemediklerini iddia ettiler . 1000 saat, bir buçuk yılın yarısı kadardır, bu yüzden teste göz atmadıkları gibi değil.

Doğru, pek kimse hiç bir zaman, herhangi bir kodu resmi olarak ispat etme görevini (tamamlarsa bile tamamlamaz) doğruluyor, ancak ispat için zayıf girişimler bile hataları bulmak için çoğu test rejimini yendi. Örneğin L4 tarafından onaylanmış olan güçlü kanıt girişimleri, testin yapmadığı ve test edicinin tam olarak ne olduğunu tam olarak bilmediği sürece muhtemelen ortaya çıkmayacak kadar büyük miktarda hata ortaya çıkarmaktadır. Kodu denetim tarafından doğrulamayı zorlaştıran herhangi bir şey, test etme kabiliyetini arttırsa bile, hataların tespit edilme şansını azaltmak olarak görülebilir .

Ayrıca , test için DI gerekli değildir . Bazı alternatif test sürümlerinden ziyade, sistemi sistemdeki gerçek yazılıma karşı test etmeyi tercih ettiğimden, bu amaçla nadiren kullanıyorum. Testte değiştirdiğim her şey, programı prodüksiyon ortamından ziyade test ortamındaki kaynaklara yönlendiren özellik dosyalarında saklanıyor. Üretim veritabanının bir kopyasıyla birlikte bir test veritabanı sunucusu kurmak için zaman harcamayı tercih ederim, çünkü sahte bir veritabanını kodlamak için zaman harcıyordum; ) ve sistem entegrasyon hataları ve kodun geri kalan kısmındaki hatalar.

Bağımlılık Enjeksiyonu, Bağımlılık Tersine Çevirme için de gerekli değildir . Bağımlılık İnversiyonunu uygulamak için statik fabrika yöntemlerini kolayca kullanabilirsiniz. Aslında, 1990'larda bunun nasıl yapıldığı.

Aslında, on yıldan beri DI kullanmama rağmen, ikna edici bulmamı sağladığı tek avantaj, üçüncü parti kütüphaneleri diğer üçüncü parti kütüphaneleri kullanacak şekilde yapılandırma yeteneğidir (örneğin, Hazırda Bekletme ve her ikisini de Log4J kullanacak şekilde ayarlayın. ) ve IoC'nin proxy'ler aracılığıyla etkinleştirilmesi. Üçüncü taraf kütüphaneleri kullanmıyorsanız ve IoC kullanmıyorsanız, o zaman çok fazla bir noktaya değinmez ve gerçekten de karmaşık olmayan bir karmaşıklık ekler.

İş arkadaşlarınızın sorunuzda söylediklerini göz önünde bulundurarak, yaşadığınız sorunun teknik değil siyasi nitelikte olduğunu söylediğim için üzgünüm . Aklınızda tutmanız gereken iki mantra var:

• "Her zaman bir insan problemidir"
• " Değişim korkutucu"

Tabii ki, sağlam teknik sebepler ve avantajlar ile birçok karşı tartışma ortaya koyabilirsiniz, ancak bu sizi şirketin geri kalanıyla kötü bir duruma sokacaktır. Zaten istemediklerine dair bir duruşları var (çünkü şu anda işlerin nasıl yürüdüğü konusunda rahatlar). Bu yüzden ısrarcı kalırsanız, diğer meslektaşlarınızla olan ilişkinizi bile incitebilir. Bu konuda bana güven, çünkü bu başıma geldi ve sonunda birkaç yıl önce kovuldum (genç ve saftım); bu, içine girmek istemediğin bir durum.

Mesele şu ki, insanlar mevcut çalışma tarzlarını değiştirecek kadar ileri gitmeden önce bir güven seviyesine ulaşmanız gerekiyor . Çok güven duyduğunuz bir konumda değilseniz ya da bir mimar veya teknoloji liderliği rolü gibi bu tür şeylere karar veremiyorsanız, meslektaşlarınızı geri döndürmek için yapabileceğiniz çok az şey vardır. Şirket kültürünüzün değişmesi için güven kazanmak için (küçük iyileştirici adımlar atarken) ikna ve çaba ile çok zaman alacaktır. Aylar ya da yıllardan oluşan bir zaman diliminden bahsediyoruz.

Mevcut şirket kültürünün sizinle çalışmadığını tespit ederseniz, en azından bir sonraki iş görüşmenizde sorulacak başka bir şey biliyorsunuzdur. ;-)

DI kullanmayın. Unut gitsin.

GoF fabrika modelinin , kendi bağımlılıklarınızı "yaratan" ya da "bulan" bir uygulama yaratın ve bunları nesnenize aktarın ve buna bırakın, ancak DI olarak adlandırmayın ve karmaşık bir genelleştirilmiş çerçeve oluşturmayın. Basit ve ilgili tutun. Bağımlılıkların ve sınıflarınızın DI'ye geçmenin mümkün olduğu şekilde olduğundan emin olun; ancak fabrikayı usta tutun ve kapsamı oldukça sınırlı tutun.

Zamanla büyüyeceğini ve hatta bir gün DI'ye geçeceğini umabilirsiniz. Liderlerin kendi zamanında sonuca varmasına izin vermeyin ve itmeyin. Bunu asla başaramasanız bile, en azından kodunuz DI'nin avantajlarından bazılarına sahiptir, örneğin birim test edilebilir kodu.

Test etmek ve nesneleri alay etmek için DI'yi aşırıya götüren projeler gördüm. Öyle ki DI konfigürasyonu, gerçek bir kod gibi çalışan bir sistemi elde etmek için gereken konfigürasyona sahip kendi başına programlama dili haline geldi.

Sistem şu anda test edilemeyen uygun API'lerin eksikliğinden dolayı acı çekiyor mu? Sistemi bir DI modeline geçmenin ünite testini daha iyi yapmanıza izin vermesini mi umuyorsunuz? Kodunuzu test etmek için bir konteynere ihtiyacınız yok. DI modelini kullanmak, Mock nesnelerle daha kolay test etmenizi sağlar, ancak gerekli değildir.

Aynı anda DI uyumlu olması için tüm sistemi değiştirmenize gerek yoktur. İsterseniz keyfi olarak Ünite testleri de yazmamalısınız. Özelliklerde karşınıza çıkan refactor kodu ve böcek çalışma biletleri. Sonra dokunduğunuz kodun kolayca test edilebildiğinden emin olun.

CodeRot'u bir hastalık olarak düşünün. İsteğe bağlı olarak bazı şeyleri hacklemeye başlamak istemezsiniz. Bir hastanın var, ağrılı bir nokta görüyorsun, böylece noktayı ve etrafındaki şeyleri düzeltmeye başlarsın. Bu alan temiz olduğunda bir sonrakine geçersiniz. Er ya da geç, kodun çoğunluğuna dokundunuz ve bu "büyük" mimari değişime gerek yoktu.

DI ve Mock testlerinin karşılıklı olarak özel olmasını sevmiyorum. Ve devam eden bir projeyi gördükten sonra, daha iyi bir kelime eksikliği olduğu için DI kullanarak çılgınca, yararı görmeden de bıktım.

DI kullanmanın mantıklı olduğu yerler var:

• Veri erişim stratejilerini takas etmek için Veri Erişim Katmanı
• Kimlik Doğrulama ve Yetkilendirme Katmanı.
• Kullanıcı Arabirimi için Temalar
• Hizmetler
• Eklenti uzantı puanları kendi sisteminizin veya üçüncü tarafların kullanabileceği noktaları gösterir.

Her geliştiricinin DI konfigürasyon dosyasının nerede olduğunu bilmesini istemek (konteynerlerin kod aracılığıyla başlatılabileceğini biliyorum, ama neden bunu yaparsınız.) Bir RegEx gerçekleştirmek istediklerinde sinir bozucu oluyor. Oh görüyorum ki IRegExCompiler, DefaultRegExCompiler ve SuperAwesomeRegExCompiler. Yine de hayır, kodda, Default'ın nerede kullanıldığını ve SuperAwesome'nın nerede olduğunu görmek için analiz yapabilirim.

Birisi bana daha iyi bir şey gösterdi , sonra beni sözleriyle ikna etmeye çalışırsa, kendi kişiliğim daha iyi tepki verirdi . Sistemi daha iyi hale getirmek için zaman ve çaba harcayan biri hakkında söylenecek bir şey var. Pek çok geliştiricinin ürünü gerçekten daha iyi hale getirmek için yeterince özen gösterdiğini bulamıyorum. Sistemdeki gerçek değişikliklerle onlara gidebilir ve bunun sizin için nasıl daha iyi ve daha kolay hale getirdiğini gösterebiliyorsanız, bu, herhangi bir çevrimiçi araştırmadan daha değerlidir.

Özetle, bir sistemi değiştirmenin en iyi yolu, her geçişte dokunduğunuz kodu yavaşça daha iyi hale getirmektir. Er ya da geç, sistemi daha iyi bir şeye dönüştürebileceksiniz.

DI, invaziv Kontrol Ters Çevirme konteynerleri veya alaycı çerçeveler gerektirmez. Kodu çözebilir ve basit bir tasarım aracılığıyla DI'ye izin verebilirsiniz. Dahili Visual Studio yeteneklerini kullanarak birim testi yapabilirsiniz.

Adil olmak gerekirse, çalışanlarınızın bir noktası var. Bu kütüphaneleri çok kötü kullanmak (ve onlara aşina olmadıkları için, öğrenme sancıları olacak) sorunlara neden olacaktır. Sonunda kod önemlidir. Testlerinizi yapmak için ürününüzü mahvetmeyin.

Sadece bu senaryolarda uzlaşmanın gerekli olduğunu unutmayın.

DI'yi daha fazla satabileceğinizi sanmıyorum, çünkü bu dogmatik bir karar (ya da @Spoike'ın daha politik olarak adlandırdığı gibi ).

Bu durumda, SOLID tasarım ilkeleri gibi geniş çapta kabul görmüş en iyi uygulamalarla tartışmak artık mümkün değil.

Sizden daha fazla politik güce sahip biri DI kullanmama konusunda (belki de yanlış) bir karar vermiştir.

Diğer taraftan siz, kendi konteynerinizi uygulayarak bu karara karşı çıktınız, çünkü yerleşik bir konteyner kullanmak yasaktı. Bu başarısızlık politikası, denediğinizin durumu daha da kötüleştirmiş olabileceği anlamına geliyor.

analiz

Benim düşünceme göre, test edilmiş gelişme olmadan DI (TDD) ve birim testi, başlangıçtaki ek masraflardan ağır basan önemli bir avantaja sahip değildir.

Bu mesele gerçekten mi

• DI istemiyoruz ?

ya da bu daha mı

• tdd / unittesting, kaynak israfı mıdır?

[Güncelleme]

Projenizi proje yönetim görünümündeki klasik hatalardan görürseniz,

#12: Politics placed over substance.
#21: Inadequate design. 
#22: Shortchanged quality assurance.
#27: Code-like-hell programming.

diğerleri görürken

#3: Uncontrolled problem employees. 
#30: Developer gold-plating. 
#32: Research-oriented development. 
#34: Overestimated savings from new tools or methods. 

Ekibinize bir prensip "satmak" zorunda kalıyorsanız, o zaman muhtemelen yanlış yoldan birkaç mil uzakta olursunuz.

Hiç kimse fazladan iş yapmak istemiyor, bu yüzden onları satmaya çalıştığınız şey onlara fazladan iş gibi bakıyorsa, onları Üstün Tartışmanın Tekrarlanan Çağrısına göre ikna edemezsiniz. Onlara iş yükünü azaltmanın bir yolunu gösterdiğinizi bilmeleri gerekiyor, arttırmıyorlar.

DI genellikle , daha sonra potansiyel iş yükünü azaltmaya çalışan biri için değeri olan, ancak değeri düşük olan potansiyel azaltılmış karmaşıklık vaadi ile şimdi ekstra bir karmaşıklık olarak görülür . Ve birçok durumda DI, YAGNI'nin başka bir katmanıdır . Ve bu karmaşıklığın bedeli sıfır değil, aslında bu tür bir kalıp için kullanılmayan bir takım için oldukça yüksek. Ve bu gerçek dolarların, asla fayda sağlayamayacakları bir kovaya sürtülmesidir.

Yerine koyun
En iyisi, yaygın olduğu yerde değil, göz kamaştırıcı derecede yararlı olduğu DI'yi kullanmak. Örneğin, birçok uygulama veritabanlarını seçmek ve yapılandırmak için DI kullanır. Uygulamanız bir veritabanı katmanı ile birlikte geliyorsa, bu koymak için cazip bir yer. Ancak, uygulamanız koda sıkıca tümleşik olan, kullanıcı tarafından görünmeyen bir veritabanıyla birlikte gelirse, çalışma zamanında DB'nin değiştirilmesi gerekme olasılığı sıfıra yaklaşır. Ve DI'yi satıp, "bak, asla, asla, asla istemeyeceğimiz bu şeyi kolayca yapabiliriz" diyerek patronunuzla "bu adamın kötü fikirleri var" listesine girme ihtimaliniz var.

Ancak, bunun yerine normalde IFDEF'i bırakan bir hata ayıklama çıktısı bulunduğunu söyleyin. Bir kullanıcının bir sorunu olduğunda ve destek ekibiniz, günlük çıktısı alabilmesi için hata ayıklama derlemesi göndermelidir. Müşterilerin günlük sürücüleri arasında geçiş yapmasını sağlamak için DI'yi kullanabilirsiniz - LogConsolegeliştiriciler LogNulliçin, LogNetworkmüşteriler için ve sorunlu müşteriler için. Bir birleşik yapı, çalışma zamanı yapılandırılabilir.

Öyleyse ona DI demek zorunda değilsiniz, bunun yerine sadece "Mel'in gerçekten iyi bir fikri" deniyor ve şimdi kötü olanın yerine iyi fikirler listesinde. İnsanlar kalıbın ne kadar iyi çalıştığını görecek ve kodlarında mantıklı olan yerlerde kullanmaya başlayacaktır.

Bir fikri doğru bir şekilde sattığınızda, insanlar onları herhangi bir şeye ikna ettiğinizi bilemez.

Tabii ki, Kontrolün Tersine çevrilmesi (IoC) çok sayıda avantaja sahiptir: kodu basitleştirir , tipik görevleri yapan bir sihir ekler vb.

Ancak:

1. Çok fazla bağımlılık ekler. Spring ile yazılmış basit bir merhaba dünya uygulaması bir düzine MB ağırlığa sahip olabilir ve Spring'in yalnızca birkaç satır ve kurucu satırından kaçınmak için eklendiğini gördüm.

2. Dışarıdakiler için anlaşılması zor olan yukarıda belirtilen sihirleri ekler (örneğin, iş katmanında bazı değişiklikler yapması gereken GUI geliştiricileri). Yenilikçi Düşünceler Benzer Düşünme - New York Times , bu etkinin uzmanlar tarafından nasıl hafife alındığını anlatan harika makaleye bakın .

3. Sınıfların kullanımını takip etmek zorlaşıyor. IDE gibi Eclipse verilen sınıfları veya metot çağrımı kullanımlarını izlemek için harika bir yeteneğe sahiptir. Ancak, bağımlılık enjeksiyonu ve yansıma çağrısında bulunduğunda bu iz kaybolur.

4. IoC kullanımı normalde enjekte bağımlılıklarıyla bitmez, sayısız vekil ile sona erer ve% 90'ı vekil olan ve yansıtma yoluyla çağrılan yüzlerce satırı sayan yığın izine sahip olursunuz. Yığın iz analizini karmaşıklaştırır.

Bu yüzden, Spring ve IoC'nin büyük bir hayranı olarak kendim oldum, geçenlerde yukarıdaki soruları yeniden düşünmek zorunda kaldım. Benim Meslektaşlarımız bazıları Python ve PHP ve yönettiği Web dünyadan Java dünyasının içine alınan web geliştiricileri olan bariz onlar için bariz daha şey javaist şeyler içindir. Benim diğer Meslektaşlarımız bazıları yapıyoruz hileler bulmak çok zor hatayı yapar (tabi belgesiz). Tabii IoC yanlış kullanım, işleri hafifletiyor;)

Tavsiyem, işinizde IoC kullanımını zorlarsanız, başkasının yapacağı her türlü suiistimalden siz sorumlu olacaksınız;)

Ben ChrisF'in doğru bir şey olduğunu düşünüyorum. DI'yi kendi içinde satma. Ancak kodu test eden birim hakkındaki fikrinizi satınız.

Mimariye bir DI konteyneri sokmak için bir yaklaşım, testlerin uygulamayı bu mimari ile iyi uyum sağlayacak bir şeye sürüklemesine izin vermek olabilir. Örneğin, bir ASP.NET MVC uygulamasında bir denetleyici üzerinde çalıştığınızı varsayalım. Sınıfı şöyle yazdığınızı söyleyin:

public class UserController {
    public UserController() : this (new UserRepository()) {}

    public UserController(IUserRepository userRepository) {
        ...
    }

    ...
}

Bu, kullanıcı havuzunun gerçek uygulamasından ayrılan birim testleri yazmanıza izin verir. Ancak, sınıf hala sizin için oluşturmak için DI konteyneri olmadan çalışır. Parametresiz yapıcı bunu varsayılan depo ile oluşturacaktır.

İş arkadaşlarınız bunun daha temiz testlere neden olduğunu görebilirler, belki bunun daha iyi bir yol olduğunun farkındalar. Belki bu şekilde kodlamaya başlamalarını sağlayabilirsiniz.

Bunun, belirli bir UserRepository uygulaması hakkında bilgi sahibi olan UserController'dan daha iyi bir tasarım olduğunu anladıktan sonra, bir sonraki hamleyi alabilir ve onlara ihtiyacınız olan örnekleri otomatik olarak sağlayabilen bir bileşen, DI konteynerine sahip olabileceğinizi gösterebilirsiniz.

Belki de yapılacak en iyi şey geri adım atmak ve DI kaplarını neden tanıtmak istediğinizi kendinize sormak mı? Test edilebilirliği artırmak istiyorsanız, ilk göreviniz ekibin birim testine girmesini sağlamaktır. Şahsen, bir DI testinin olmamasından ziyade, birim testlerinin eksikliği konusunda endişeliyim.

Kapsamlı bir süit veya birim test süitleriyle donanmış olarak, tasarımınızı zaman içinde geliştirmek için güvenle ayarlayabilirsiniz. Onlar olmadan, tasarımınızı gelişen gereksinimlerle adım adım ilerletmek için giderek artan bir mücadeleyle karşı karşıya kalıyorsunuz, sonunda birçok takımın kaybettiği bir mücadele.

Bu yüzden benim tavsiyem, önce DI ve sonra DI konteynerlerini tanıtmak için önce birim test ve yeniden yapılanma şampiyonu olacaktı.

Buradaki ekibinden bazı büyük noolar duyuyorum:

• "Üçüncü taraf kütüphaneleri yok" - AKA "Burada İcat Edilmedi" veya "NIH". Korku, bir üçüncü taraf kütüphanesi uygulayarak ve dolayısıyla kod tabanını buna bağımlı hale getirerek, kütüphanenin bir böcek veya güvenlik boşluğu olması, hatta üstesinden gelmeniz gereken bir sınırlama olması durumunda, bu üçüncüye bağımlı olmanızdır. Kodunuzun çalışması için kütüphanelerini düzeltmeye taraf olun. Bu arada, muhteşem bir şekilde başarısız olan ya da saldırıya uğramış ya da istediklerini yapmayan "sizin" programınız hala sorumluluğu taşıyor (ve üçüncü taraf devler araçlarının "olduğu gibi" ", kendi sorumluluğunuzdadır kullanın).

  Karşı argüman, sorunu çözen kodun üçüncü taraf kütüphanesinde zaten mevcut olduğudur. Bilgisayarlarını sıfırdan mı kuruyorsun? Visual Studio'yu yazdın mı? .NET'te yerleşik kitaplıkları kullanmaktan kaçınıyor musunuz? Hayır. Intel / AMD ve Microsoft'a güven düzeyiniz var ve her zaman hata buluyorlar (ve bunları her zaman hızlı bir şekilde düzeltmeyin). Üçüncü taraf bir kütüphane eklemek, tekerleği yeniden icat etmek zorunda kalmadan hızlı bir şekilde bakımı kolay bir kod temeli oluşturmanıza olanak sağlar. Ve Microsoft'un avukatlar ordusu, .NET şifreleme kitaplıklarındaki bir hatanın, .NET programını kullanırken müşterinizin zarar görmesi ihtimalinden kaynaklandığını söylerken yüzünüze güler. Microsoft kesinlikle ürünlerinden birinde "sıfır saat" güvenlik açığı düzeltmek için atlayacaktır,

• “Biz her şeyi bir düzene yerleştirmek istiyoruz” - aslında, yapmazsınız. En azından .NET'te, bir kod satırında değişiklik yaparsanız, bu kod satırını içeren tüm derlemenin yeniden oluşturulması gerekir. İyi kod tasarımı, olabildiğince bağımsız olarak yeniden oluşturabileceğiniz (veya en azından bağımlılıkları değil, yalnızca bağımlılıkları yeniden oluşturmak zorunda kalabileceğiniz) birden fazla düzeneğe dayanır. GERÇEKTEN, yalnızca EXE olan bir EXE (belirli durumlarda değeri olan) serbest bırakmak istiyorsa, bunun için bir uygulama var; ILMerge.

• "DI tabudur" - WTF? DI, "arabirim" kod yapısına sahip herhangi bir O / O dilinde kabul edilmiş en iyi uygulamadır. Ekibiniz nesneler arasındaki bağımlılığı gevşek bir şekilde birleştirmiyorsa GRASP veya SOLID tasarım metodolojilerine nasıl bağlı kalır? Rahatsız etmezlerse, ürünü karmaşık bir taciz yapan spagetti fabrikasını sürdürüyorlar. Şimdi, DI nesne sayısını artırarak karmaşıklığı arttırıyor ve farklı bir uygulamayı değiştirmeyi kolaylaştırırken, arayüzü değiştirmeyi zorlaştırıyor (değişmesi gereken ekstra bir kod nesnesi katmanı ekleyerek).

• "Bu karmaşıklık katmanını zaten karmaşık bir projeye eklemek zorunda değiliz" - Bir nokta olabilir. Herhangi bir kod geliştirmede dikkate alınması gereken önemli bir şey YAGNI'dir; "İhtiyacın olmayacak". SOLIDly'den başlayarak tasarlanan bir tasarım, SOLID'i "inanca bağlı" yapan bir tasarımdır; SOLID tasarımlarının sağladığı değişiklik kolaylığına ihtiyacınız olup olmadığını bilmiyorsunuz, ancak bir ipucunuz var. Haklı olsan da, çok yanlış da olabilirsin; çok SOLID bir tasarım, "lazanya kodu" veya "mantı kodu" olarak görülebilir, çok fazla katman veya ısırık büyüklüğü olan görünüşte önemsiz değişiklikler yapmanın zorlaştığı görünebilir. böyle kıvrımlı bir çağrı yığını.

  Üç vuruşlu kuralı destekliyorum: Çalışmasını sağla, temizle, SOLID yap. İlk önce bir kod satırı yazmanız yeterlidir ve fildişi kule tasarımları için puan almazsınız. Bir defalık olduğunu farz et ve yapman gerekeni yap. Bu koda ikinci kez baktığınızda, muhtemelen onu genişletmeyi veya yeniden kullanmayı düşünüyorsunuz ve bu olacağını düşündüğünüz tek seferlik değil. Bu noktada, yeniden düzenleyerek daha şık ve anlaşılır kılın; karmaşık mantığı basitleştirin, tekrarlanan kodu döngülere ve / veya yöntem çağrıları içine çıkarın, burada ve orada bırakmanız gereken herhangi bir çamur için birkaç yorum ekleyin, vb. Bu koda üçüncü kez baktığınızda muhtemelen çok büyük bir sorun. Şimdi SOLID kurallarına uymalısınız; bunları oluşturmak yerine bağımlılıkları enjekte etmek, kodun "et" ile daha az uyumlu yöntemleri tutmak için sınıfları çıkarmak,

• “Farklı uygulamalara bağlanacağız gibi değil” - Siz bayım, elinizdeki ünite testlerine inanmayan bir ekibiniz var. İzolasyonla çalışan ve hiçbir yan etkisi olmayan bir birim testi yazmanın, bu yan etkileri olan nesneleri "alay etmeden" imkansız olduğunu düşünüyorum. Önemsiz olmayan herhangi bir programın yan etkileri vardır; Programınız bir DB okur veya yazarsa, dosyaları açar veya kaydeder, bir ağ veya çevre soketi üzerinden iletişim kurar, başka bir program başlatır, pencereler çizer, konsola çıktı verir veya başka bir işlemin "sanal alanı" dışındaki bellek veya kaynakları kullanırsa, yan etki. Bunların hiçbirini yapmazsa, ne yapar ve neden almalıyım?

  Adil olmak gerekirse, birimin çalıştığını kanıtlamanın tek yolu ünite testi değildir; entegrasyon testleri yazabilir, matematiksel olarak kanıtlanmış algoritmalara kod yazabilirsiniz. Ancak, birim testleri çok hızlı bir şekilde A, B ve C girişleri verildiğini, bu kod parçasının beklenen X çıktısını aldığını (ya da olmadığını) gösterir. Kod belirli bir durumda düzgün çalışıyor (veya çalışmıyor). Ünite testleri süitleri, kodun her durumda beklendiği gibi çalıştığını ve ayrıca matematiksel bir kanıtın sağlayamayacağı bir şey sağladığını yüksek bir güven ile gösterebilir; STILL programının amaçlandığı şekilde çalıştığını gösteren bir gösteri. Algoritmanın matematiksel bir kanıtı doğru uygulandığını ispatlamaz, yapılan değişikliklerin doğru uygulandığını ve kırılmadığını kanıtlamaz.

Kısacası, eğer bu ekip DI'nin yapacağı şeyde herhangi bir değer görmezse, o zaman bunu desteklemeyeceklerdir ve herkes (en azından tüm yaşlı erkekler) gerçek değişim için bir şey satın almak zorundadır. gerçekleşmesi için. YAGNI'ye çok önem veriyorlar. SOLID ve otomatik testlere çok fazla önem veriyorsunuz. Ortada bir yerde gerçek yatıyor.

Onaylanmadığında bir projeye ekstra özellikler (DI gibi) eklerken dikkatli olun. Zaman sınırları olan bir proje planınız varsa, onaylanan özellikleri bitirmek için yeterli zamana sahip olmama tuzağına düşebilirsiniz.

Şimdi DI kullanmasanız bile, teste katılın, şirketinizde test için beklentilerin tam olarak ne olduğunu öğrenin. Başka bir proje olacak ve mevcut projenin DI ile test edilmesiyle ilgili sorunları zıtlaştırabilirsiniz.

DI kullanmıyorsanız, yaratıcı olabilir ve kodunuzu DI-"hazır" hale getirebilirsiniz. Diğer yapıcıları çağırmak için parametresiz bir yapıcı kullanın:

MyClassConstructor()
{
    MyClassConstructor(new Dependency)
    Property = New Dependent Property
}

MyClassConstructor(Dependency)
{
    _Dependency = Dependency
}

En büyük endişelerinden birinin aslında tam tersi olduğunu düşünüyorum: DI projeyi karmaşık hale getirmiyor. Çoğu durumda, çok fazla karmaşıklığı azaltır.

Sadece DI olmadan düşünün, ihtiyacınız olan bağımlı nesne / bileşeni ne elde edeceksiniz? Normalde bir depodan bakmak veya bir singleton almak ya da kendinizi somutlaştırmaktır.

Eski 2, bağımlı bileşeni bulmak için fazladan kod içeriyor, DI dünyasında, arama yapmak için hiçbir şey yapmadınız. Bileşenlerin karmaşıklığı aslında azalır.

Kendinizi uygun olmayan bazı durumlarda somutlaştırıyorsanız, daha da karmaşıklık yaratıyor. Nesnenin nasıl doğru bir şekilde oluşturulduğunu bilmeniz, nesneyi uygulanabilir bir durumda başlatmak için hangi değerleri bilmeniz gerekir, bunların tümü kodunuzda ekstra bir karmaşıklık yaratır.

Dolayısıyla, DI projeyi karmaşıklaştırmıyor, bileşenleri daha basit hale getirerek daha basit hale getiriyor.

Başka bir büyük argüman, farklı bir uygulama yapmayacaksınız. Evet, üretim kodunda, gerçek üretim kodunda birçok farklı uygulamaya sahip olmanın yaygın olmadığı doğrudur. Bununla birlikte, farklı bir uygulamaya ihtiyaç duyan önemli bir yer var: Birim Testlerinde Mock / Stub / Test Çiftler. DI çalışmasını sağlamak için, çoğu durumda arabirim odaklı geliştirme modeline dayanır ve sırayla birim testlerinde alay / saplama yapmayı mümkün kılar. Uygulamanın yerini almasının yanı sıra, "arayüz odaklı tasarım" aynı zamanda daha temiz ve daha iyi tasarım yapar. Tabii ki DI olmadan arayüz ile tasarlayabilirsiniz. Ancak, Unit testleri ve DI sizi bu tür uygulamaları benimsemeye zorluyor.

Şirketteki “tanrılarınız”, “basit kod”, “birim testler”, “modülerleştirme”, “tek sorumluluk” vb. Şeylerin karşı oldukları bir şey olduğunu düşünmüyorlarsa, DI kullanarak reddetmeleri için hiçbir neden olmamalıdır.

"Basit tutmak istiyoruz, eğer mümkünse her şeyi tek bir düzene sokun. DI faydasız, istenmeyen bir karmaşıklıktır".

Faydası, arayüzlere tasarım yapmayı teşvik etmesi ve kolay alay etmesine izin vermesidir. Sonuç olarak birim testini kolaylaştırır. Birim testi, güvenilir, modüler ve kolayca bakım yapılabilir bir kod sağlar. Patronunuz hala kötü bir fikre sahipse, yapabileceğiniz hiçbir şey yok - kabul görmüş endüstriye karşı savundukları en iyi uygulama.

DI çerçeveli bir ünite testi ve alaycı kütüphane ile denemelerini sağlayın, yakında sevmeyi öğrenecekler.

Bu insanlarla daha küçük projelerde mi yoksa sadece büyük bir projede mi çalışıyorsunuz? İkincil / üçüncü bir projede insanları yeni bir şeyler denemeye ikna etmek, ekibin / şirketlerin ekmek ve tereyağından daha kolaydır. Başlıca nedenleri, çıkarma / değiştirme maliyetini düşürmediği takdirde daha küçük olması ve küçük bir projede her yere ulaştırması çok daha az çalışmasıdır. Var olan büyük bir tanesinde, her yerde bir kerede değişiklik yapmak için büyük bir maliyet ya da sürtünme katan kodun eski / yeni yaklaşımın bir karışımı olduğu uzatılmış bir süreye sahip olursunuz, çünkü her bir sınıfın hangi şekilde tasarlandığını hatırlamak zorundasınız. çalışmak.

DI'yi destekleyen şeylerden biri birim testi olmasına rağmen, bazı durumlarda karmaşıklık katmanı eklediğine inanıyorum.

• Daha İyi Bir aracı test etmek zor, ancak tamiratı yapmak, araba kullanmaktan daha kolay, testi zor, onarımı da zor.

• Ayrıca, DI için zorlayan grubun sadece bazı mevcut tasarım yaklaşımlarının kötü olduğunu etkileyerek fikirlerini sunduğunu düşünüyorum.

• 5 farklı işlev yapan bir yöntemimiz varsa

  DI-İnsanlar Diyor:

  • kaygıların ayrılması yok. [bunun sorunu ne? Kötü görünmeye çalışıyorlar; mantık ve programlamada birbirleriyle ne yaptığını bilmek, çatışmalardan ve yanlış beklentilerden daha iyi kaçınmak ve kod değişikliğinin etkisini kolayca görmekten daha iyidir, çünkü hepsini yapamayız. birbirleriyle ilgili olmayan nesneler% 100 veya en azından bunu garanti edemeyiz {regresyon testi neden önemli değilse?]]
  • Karmaşık [Her biri, bir işlevi işlemek için her biri için ek beş sınıf daha ekleyerek ve şimdi bir felsefeye ek olarak "ayarlara (" varsayılan "olmak üzere) ayarlara (XML veya Sözlük) dayalı gerekli işlev için bir sınıf oluşturmak üzere ek sınıf (Konteyner) yaparak karmaşıklığı azaltmak istiyorlar. ya da "tartışmalar ...] sonra da karmaşıklığı kaba ve yapıya taşıdılar, [bana göre karmaşıklığı bir işyerinden iki yere, tüm bu dil özelliklerini karmaşıklığı ile ele almak gibi görünüyor. ]

DI'den etkilenmekten çok iş ihtiyaçlarına uygun kendi tasarım modelimizi oluşturmanın daha iyi olduğuna inanıyorum.

DI lehine, bazı durumlarda yardımcı olabilir, örneğin, aynı Arayüz için yüzlerce uygulamanız varsa bir seçiciye bağlıysa ve bu uygulamalar mantıkta çok farklıysa, bu durumda DI veya DI benzeri tekniklerle giderim. fakat aynı arayüz için birkaç uygulamamız varsa, DI'ye ihtiyacımız yoktur.