Yazılımın yüksek oranda eşleşip eşleşmediğini nasıl anlayabilirim?

Terim "son derece birleştiğinde" aşina ama kodun çok bağlı olduğunu gösteren işaretler (kod kokuları) olup olmadığını merak ediyorum. Şu anda Java EE ile çalışıyorum ancak bu herhangi bir dile uygulanabilir.

Düzenle:

Kimse ilgilenirse, bu makale faydalı görünüyor: Kod kalitesi peşinde: Sıkı çift dikkat edin! (IBM)

Bence kötü bağlanmış modüllerin bir numaralı göstergesi bilateral bağımlılıklardır. Örneğin, Modül1, Modül2'deki bazı işlevleri çağırır ve Modül2, Modül1'deki bazı işlevleri çağırır.

Çoğu arabirim tek yönlü olmalıdır. Çağrılan modülün çağrının bir parçası olarak döndürülmeyen çağrı modülüne bazı bilgiler iletmesi gerekiyorsa, mesaj kuyruğu gibi bir tür mesaj iletme veya olay tetikleme mekanizması kullanmalıdır. İdeal olarak, mesaj başlatma arayüzü tanıtıcı bir başlatma veya kayıt işlemi sırasında geçirilmelidir. Bu, arayüzü tamamen modülün olayın kim için olduğunu umursamayacak şekilde soyutlar ... dolayısıyla ayrıştırılır.

Diğer bir gösterge, bir modülün belirli bir veri seti için sürekli olarak başka bir modül çağırmasıdır. Bu, veri kümesinin gerçekte kime sahip olması gerektiğini sorgulamanız gerekir. Söz konusu modülün neden her zaman başka bir modüle ait verileri görmesi gerekiyor?

Üçüncü bir araç, kendinize şu soruyu sormaktır: "Bu modülü dışarı çekip diğer modüllerde değişiklik yapmadan değiştirebilir miyim?

Bu hiçbir şekilde kapsamlı bir liste değildir, ancak yazılım tasarlarken kendime sorduğum ilk üç şeydir.

Eski tasarım der ki, "Arkadaşlarına dokunabilirsin ve senin ayrıcalıklarına dokunabilirsin. Ama arkadaşlarının ayrıcalıklarına dokunamazsın." Bu kısaca birleşiyor.

Oldukça birleştirilmiş kod işaretleri, uygulamanın özel ayrıntıları hakkında bilgi veren çok büyük arayüzler ve "birbirleri hakkında çok şey biliyor" gibi görünen nesneleri içerir. Otomatik analiz için, sıkı sıkıya bağlı görünen kodu işaretleyecek araçlar vardır. Rastgele biri için http://www.scitools.com/features/metricsintro.php adresine bakın . (Ne kadar iyi çalıştığı hakkında hiçbir fikrim yok. Bir Google aramasında oldukça yükseldi.)

Sınıflar için bazı birim testleri yazmayı deneyin. Destek sınıfları veya db / ui yükleri oluşturmaya / takılmaya gerek kalmadan sınıfları kolayca test edemezseniz, kötü bağlantı / bağımlılıkların kesin bir işaretidir.

Aynı zamanda en iyi tedavilerden biridir, ancak kodlama sırasında (TDD gibi) sizi dürüst tutmak için yapmanız gerekir.

Bana açık olan işaret her şeyin halka açık olması.

Diğer işaret Demeter Yasası ihlalleri - bu aşırı. Akıcı olmayan arayüzlerde bazıObj.SomeProp.SomeProp referansları.

Bir keresinde, o andan itibaren bir veri giriş formu oluşturan bir "puppetmaster sınıfı" olarak adlandırdığımı gördüm. Birkaç başka yazılım tasarım ihlali vardı, bu nedenle aşırı eşleşme endişelerinin en azıydı.

Oluşturduğu denetimlerden veri alırken şöyle oldu:

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

Dalga Etkisi .

Her değişikliğin sıkıca bağlanmış tüm modüllerde dalgalanma etkisi vardır.

"Açık-Kapalı" ilkesi, düzgün bir şekilde kapatılmamış olması ve değişiklik sızması nedeniyle ihlal edilmiştir.

Sınıflar / paketler / dll / kavanozlar / whatnots arasında # include / import vb. Sayısını kontrol edin. Zihinsel, elle veya bir tür araç kullanarak bunun bir grafiğini çizmeye çalışın.

• Bu grafik yoğunsa (yani her yerde birçok bağlantı), sisteminiz monolitiktir ve yüksek derecede bağlanmıştır.
• Katmanlar arasında hiçbir bağlantı olmadan açıkça katmanlara bölünmüşse ve bağlantılar azsa, modüler ve ayrıştırılmış bir sisteminiz vardır.

Belirli bir sorumluluğun nereye gittiğine dair bir fikriniz olmadığı için bir özelliği uygulamayı imkansız bulursanız, sisteminiz çok sıkı bir şekilde bağlanır.

Çok temel işaretler için, arabirimlerin sayısını ve bunların farklı paket sınıfları arasındaki kullanımlarını (genellikle gevşek bağlanmış kod arabirimleri içerir ve farklı paketlerdeki tek tek sınıflar arasında sınırlı doğrudan etkileşim vardır), sınıf adlarının sayısını düşünebilirsiniz. diğer sınıfları gruplamak için kullanılır (farklı işlere sahip sınıflar arasındaki gevşek bağlanmış koddaki gerçek etkileşim, arabirim işlevleri veya daha yaygın / gruplandırma sınıflarının işlevleri tarafından yapılır) veya sınıf içindeki ortak değişkenleri numaralandırır (daha gevşek çok daha az / hatta hiçbiri ortak değişkenler) ).

Hemen hemen tüm kod kokuları bir şekilde gereksiz bağlantıyı gösterir. Sanırım en çok eşleşmeyi gösterecek koku "Uygunsuz Samimiyet" (benim en sevdiğim koku) olabilir.

Ölçmek için başka bir makul yöntemin UML diyagramınızdaki satırları saymak olduğunu varsayalım. N nesneniz ve aralarında N ^ N (veya daha fazla) satır varsa, kodunuz hemen hemen en fazla şekilde eşleştirilir. N hatları muhtemelen alabildiğiniz kadar az olacaktır.