KURU Prensibinin İhlali

Bir yerde bu anti-desen için bir isim olduğundan eminim; bununla birlikte, bunu tanımak için anti-model literatüre yeterince aşina değilim.

Aşağıdaki senaryoyu düşünün:

or0bir sınıftaki üye işlevidir. Daha iyisi ya da daha kötüsü, büyük ölçüde sınıf üyesi değişkenlerine bağlıdır. Programmer A gelir ve or0çağırmak yerine or0programlamaya ihtiyaç duyar , Programcı A tüm sınıfı kopyalar ve yeniden adlandırır. Dediğim or0gibi, işlevselliği için üye değişkenlere büyük ölçüde bağımlı olduğu için aramadığını tahmin ediyorum. Ya da belki genç bir programcıdır ve onu diğer kodlardan nasıl arayacağını bilmiyordur. Şimdi or0ve c0(kopya için c) var. Programcı A'yı bu yaklaşım için tamamen hatalandıramıyorum - hepimiz sıkı son tarihlere sahibiz ve işi yapmak için kodu hackliyoruz.

Birkaç programcı or0bu yüzden şimdi sürümü korumak orN. c0şimdi sürüm cN. Ne yazık ki, sınıfları içeren programcıların çoğu , DRY ilkesinin bilgeliği için aklıma gelen en güçlü argümanlardan biri olan or0tamamen habersiz görünüyordu c0. Ayrıca, içindeki kodun bağımsız bir şekilde muhafaza edilmiş olması da mümkündür c. Her iki şekilde de görünür or0ve c0birbirinden bağımsız olarak muhafaza edilir. Ve neşe ve mutluluk, içinde meydana gelmeyen bir hata meydana cNgelir orN.

Birkaç sorum var:

1.) Bu anti-patern için bir isim var mı? Bunun çok sık olduğunu gördüm, bunun adlandırılmış bir anti-desen olmadığına inanmak zor.

2.) Birkaç alternatif görebiliyorum:

a.) İhtiyaç orNduyduğu tüm üye değişkenlerin değerlerini belirten bir parametre almak için düzeltme . Ardından , iletilen tüm gerekli parametrelerle cNçağrı orNyapmak için değiştirin .

b.) elle liman düzeltmeleri için deneyin orNiçin cN. (Bunu yapmak istemiyorum ama gerçekçi bir olasılık.)

c.) yeniden kopyalamak orNiçin cN, yuck --again ama bütünlüğü sağlamak için liste.

d.) Nerede cNkırık olduğunu anlamaya çalışın ve sonra bağımsız olarak onarın orN.

Alternatif a , uzun vadede en iyi düzeltme gibi görünüyor, ancak müşterinin bunu uygulamama izin vereceğinden şüpheliyim. Asla işleri düzeltmek için zaman ya da para değil, aynı sorunu 40 ya da 50 kez onarmak için zaman ve para, değil mi?

Düşünmediğim başka yaklaşımlar öneren var mı?

1. sadece yinelenen kod denir - bunun için daha süslü isimler bilmiyorum. Uzun vadeli sonuçlar sizin tanımladığınız ve daha da kötüsü.

2. Tabii ki, çoğaltmayı ortadan kaldırmak sadece mümkünse idealdir. Çok zaman alabilir (eski projemizde son zamanlarda, bir sınıf hiyerarşisinde 20'den fazla alt sınıfta çoğaltılan birkaç yöntemim vardı, bunların çoğu yıllar içinde evrimsel olarak kendi küçük farklılıklarını / uzantılarını büyüttü. tüm kopyalardan kurtulmak için birbirini takip eden birim test yazma ve yeniden düzenleme sayesinde yaklaşık 1,5 yıl. Azim buna değdi).

   Böyle bir durumda, yinelemeyi ortadan kaldırmak için harekete geçmeye karar verseniz bile, geçici çözüm olarak bir veya daha fazla seçeneğe ihtiyacınız olabilir. Ancak bunlardan hangisinin daha iyi olduğu pek çok faktöre bağlıdır ve daha fazla bağlam olmadan sadece tahmin ediyoruz.

   Birçok küçük iyileştirme uzun vadede büyük bir fark yaratabilir. Bunlar için müşterinin açık onayına ihtiyacınız yoktur - bir hatayı düzeltmek veya bir özelliği uygulamak için adı geçen sınıfa her dokunduğunuzda biraz yeniden düzenleme yapmak zaman içinde uzun bir yol kat edebilir. Görev tahminlerinize yeniden düzenleme için biraz zaman ayırmanız yeterli. Yazılımı uzun vadede sağlıklı tutmak standart bakım gibidir.

ISLAK (Biz Yazma Keyfini) desen bir referans var ama standart bir isim olup olmadığını bilmiyorum.

... Yazılım lisanslama, DRY (Kendinizi Tekrarlama) uygulaması için dikkate değer bir istisnadır - yazılım lisanslama kodu mümkün olduğunca WET (Yazmayı Keyfini Çıkarırız - DRY'nin tam tersi) olmalıdır.

Lisans mantığınızı diğer endişelerden ayrı olarak tek bir yerde izole ederseniz, lisanslamayı tamamen devre dışı bırakmak için yazılımınızı değiştirmeyi çok daha kolay hale getirirsiniz. Lisanslama mantığını uygulama boyunca birçok kez tekrarlamak daha iyidir, tercihen yazılımın tek bir yürütülmesi sırasında birçok kez yürütülür.

Örneğin, yükleme sırasında, uygulama başlatılırken ve önemli özelliklere erişildiğinde bir lisans denetimi gerçekleştirmenizi öneririz. Başlatma sırasında lisansı bir kez kontrol etmeyin ve bu değeri aktarmayın; bunun yerine, aslında her alandaki lisans kontrolünü çoğaltın. Bu elverişsiz, ancak kırılması kolay bir ürün piyasaya sürmekten çok daha iyi ...

Seni doğru anlarsam, sınıfta çok fazla şey oluyor. Bu, tek sorumluluk ilkesine uymayan yöntemler yaratır . Taşınması gereken koda götürür, diğerleri dışarıdayken parçalar alınır. Bu da çok sayıda üye yaratabilir.

Ayrıca erişilebilirlik değiştiricileri de gözden geçirmelisiniz. Halka açık olan şeylerin aslında halka açık olmasını sağlayın. Tüketicinin her küçük üye hakkında bilgi sahibi olması gerekmez ... kapsülleme kullanın.

Bu bir refactor gerektirir. Ayrıca kod, ön tasarım olmadan yazılıyor gibi görünüyor. Test Odaklı geliştirmeye bakın. Kodu, çağrılmak yerine kodu çağırmak yerine nasıl çağırılması gerektiğini yazın. Görevin nasıl gerçekleştirileceğine dair bazı ipuçları için TDD'ye bakın .

Kodu kopyalıyorsanız, çifte bakım veya daha spesifik olarak teknik bir borç getireceksiniz : kod çoğaltma .

Genellikle bu yeniden düzenleme ile sabitlenir. Daha spesifik olarak, tüm çağrıları ortak koda sahip yeni bir işleve (veya yeni bir sınıfta yeni bir yöntem) yönlendirirsiniz. Başlamanın en kolay yolu, kopyalanan tüm kodları kaldırmak ve aramaları ortak koda yönlendirerek düzelttiğiniz hangi kopmaları görmektir.

Teknik olmayan bir kişiyi teknik borcu düzeltmeye ikna etmek zor olduğundan, müşterinizin refactor kodunu kabul etmesini sağlamak zor olabilir. Bir dahaki sefere zaman tahmini verdiğinizde, tahminlerinize yeniden bakmak için gereken süreyi ekleyin . Çoğu zaman müşteriler, düzeltmeyi yaptığınız süre boyunca kodu temizlediğinizi varsayar.

Bana spagetti kodu gibi geliyor. En iyi düzeltme bir refactor / yeniden yazmadır.

karmaşık ve karışık bir kontrol yapısına sahip, özellikle de birçok GOTO, istisna, iş parçacığı veya diğer "yapılandırılmamış" dallanma yapılarını kullanan kaynak kodu için aşağılayıcı bir terim. Bu şekilde adlandırılır, çünkü program akışı kavramsal olarak bir spagetti kasesi gibidir, yani bükülmüş ve karışık ...

A'yı tamamen suçlayamayacağınızı söylüyorsunuz - ancak bir sınıfı bu şekilde kopyalamak gerçekten affedilemez. Kod inceleme işleminizde büyük bir başarısızlık. Muhtemelen en büyük başarısızlık, kod gözden geçirmesi yok.

Eğer bir son teslim tarihine uymak için korkunç kodlar üretmeniz gerektiğini düşünüyorsanız, bundan sonraki sürüm için mutlak en yüksek öncelikli istek ŞİMDİ korkunç kodu düzeltmek olmalıdır. Yani probleminiz gitti.

KURU ilkesi, mükemmel olmayan ve iyileştirilebilecek durumlar içindir. Bir sınıfı çoğaltmak tamamen yeni bir kalibredir. İlk olarak "çoğaltılmış kod" olarak adlandırırdım ve zamanla tüm zaman atıklarının en kötüsüne, "farklı çoğaltılmış kod" a değişecektir: neredeyse aynı, ancak tamamen aynı olmayan birden fazla kopya ve kimse bilmiyorsa farklılıklar amaçlanır, tesadüf veya hatalardır.

Bu partiye neredeyse on yıl geç kaldı, ancak bu anti-paternin adı, birden fazla sınıfın aynı davranışın kopyalarını içerdiği, ancak zaman ve bakım ilerlemesi ve bazı sınıfların unutulduğu, Iraksak Değişim .

Paylaşılan davranışın ne olduğuna ve nasıl paylaşıldığına bağlı olarak, bunun yerine Av Tüfeği Cerrahisi olarak adlandırılabilir , fark burada tek bir mantıksal özelliğin tek bir sınıf yerine birçok sınıf tarafından sağlanmış olmasıdır.