“Bağımlılık Döngüsü Yok” kuralını (NDepend) ne kadar sıkı takip ediyorsunuz?

Biraz arka plan: Bir takım lideri olarak NDepend'i haftada bir kez kodumuzun kalitesini kontrol etmek için kullanıyorum. Özellikle test kapsamı, kod satırları ve siklomatik karmaşıklık metrikleri benim için çok değerlidir. Ancak, dengeleme ve bağımlılık döngüleri söz konusu olduğunda, biraz endişeliyim. Patrick Smacchia, seviyelendirme amacını açıklayan güzel bir blog yayınına sahiptir.

Açık olmak gerekirse: "Bağımlılık döngüsü" altında iki ad alanı arasındaki dairesel referansları anlıyorum.

Şu anda gömülü enstrümanlar için Windows CE tabanlı bir GUI çerçevesi üzerinde çalışıyorum - sadece Android grafik platformunu düşünün, ancak çok düşük uçlu enstrümanlar için. Çerçeve, yaklaşık 50.000 satır kod içeren tek bir derlemedir (testler hariç). Çerçeve aşağıdaki ad alanlarına ayrılmıştır:

• Çekirdek Gezinme ve Menü Alt Sistemi
• Ekran Alt Sistemi (Sunucular / Görünümler / ...)
• Kontroller / Widget Katmanı

Bugün yarım günü, kodu genel seviyelere getirmeye çalışmak için geçirdim [Resharper sayesinde genel olarak sorun yok], ancak her durumda bazı bağımlılık döngüleri var.

Benim sorum: "Bağımlılık Döngüsü Yok" kuralını ne kadar sıkı takip ediyorsunuz? Seviyelendirme gerçekten bu kadar önemli mi?

Son zamanlarda Simple-Talk'ta yayınlanan .NET kodlama konusu hakkında 2 beyaz kitap yazdım.

Kod Tabanınızı .NET Assemblies ve Visual Studio Projects ile Bölümleme

Ad Bileşenleriyle .NET Bileşenlerini Tanımlama

Seviyelendirme gerçekten bu kadar önemli mi?

Evet öyle!

2. beyaz kitaptan alıntı:

Bileşenler arasındaki bağımlılık grafiği bir döngü içeriyorsa, döngüde yer alan bileşenler bağımsız olarak geliştirilemez ve test edilemez. Bu nedenle, bileşenlerin döngüsü, içerdiği bileşenlerin entropilerinin toplamından daha yüksek entropiye sahip bir süper bileşeni temsil eder.

(...)

Asiklik bileşenler kısıtlamasına sürekli olarak uyulduğu sürece, kod tabanı oldukça öğrenilebilir ve bakım yapılabilir kalır.

• Geleneksel bina mimarisinde, yerçekimi gücü düşük seviyeli artefaktlar üzerinde baskı yaratmaktadır. Bu onları daha kararlı hale getirir: hareket etmeleri zor olduğu için 'kararlı'.
• Yazılım mimarisinde, asiklik bileşen fikrine uymak, düşük seviyeli bileşenler üzerinde baskı oluşturmaktadır. Bu, onları yeniden düzenlemenin acı verici olması açısından onları daha kararlı hale getirir. Ampirik soyutlamalar, uygulamalardan daha az yeniden düzenlemeye tabidir. bu nedenle, düşük seviyeli bileşenlerin ağrılı yeniden düzenlemeyi önlemek için çoğunlukla soyutlamalar (arayüzler ve numaralandırmalar) içermesi iyi bir fikirdir.

Sınıflar veya ad alanları arasında dairesel bağımlılıklara asla izin vermem. C #, Java ve C ++ 'da her zaman bir arabirim tanıtarak dairesel sınıf bağımlılığını kırabilirsiniz.

Önce test kodlaması, dairesel bağımlılıkların girilmesini zorlaştırır.

Bu her zaman bir gelenek: bağımlılıklardan neden kaçınılması gerektiğini anlamak için bağımlılıkların maliyetini anlamalısınız. Aynı şekilde, bir bağımlılığın maliyetini anlarsanız, özel durumunuza değip değmeyeceğine daha iyi karar verebilirsiniz.

Örneğin, konsol video oyunlarında, çoğunlukla performans nedenleriyle, bilgi yakın ilişkilerine ihtiyaç duyulan bağımlılıklara güveniriz. Örneğin bir baskı aracı kadar esnek olmamız gerekmediği sürece bu iyi.

Cadıdaki kısıtlamaları anlamanız gerekiyorsa, yazılımınızın çalışması (donanım, işletim sistemi veya sadece tasarım olması ("yapabileceğimiz daha basit kullanıcı arayüzü" gibi)), bağımlılıkların yapılmaması ve hangilerinin yapılacağını anlamak kolay olmalıdır tamam.

Ancak, iyi ve açık bir nedeniniz yoksa, yapabileceğiniz herhangi bir bağımlılıktan kaçının. Bağımlı kod hata ayıklama oturumunun cehennemidir.

Bu konu ne zaman tartışılırsa, katılımcılar genellikle çalışma zamanı ve çalışma zamanı döngüleri arasındaki farkı kaybederler. Birincisi, John Lakos'un "fiziksel tasarım" olarak adlandırdığı şeydir, ikincisi tartışmayla temel olarak ilgisizdir (geri aramalarla oluşturulanlar gibi çalışma zamanı döngülerine asılmayın).

Bu, John Lakos'un tüm (inşa süresi) döngülerini ortadan kaldırmak konusunda çok katı olduğunu söyledi. Ancak Bob Martin, yalnızca ikili dosyalar (örneğin DLL'ler, yürütülebilir dosyalar) arasındaki döngülerin önemli olduğu ve bundan kaçınılması gerektiği tutumunu benimsemiştir; bir ikili içindeki sınıflar arasındaki döngülerin çok önemli olmadığına inanıyordu .

Şahsen Bob Martin'in bu konudaki görüşüne sahibim. Bununla birlikte, yine de sınıflar arasındaki döngülere biraz dikkat ediyorum, çünkü bu tür döngülerin olmaması kodu başkalarının okumasını ve öğrenmesini kolaylaştırır.

Bununla birlikte, Visual Studio ile oluşturduğunuz herhangi bir kodun, ikili dosyalar (yerel veya yönetilen kod) arasında dairesel bağımlılıklara sahip olamayacağı belirtilmelidir. Böylece döngülerle ilgili en büyük sorun sizin için çözüldü. :)

Neredeyse tamamen, yapı tipi bağımlılık döngüleri Haskell'de elverişsiz, Agda ve Coq'ta imkansızdır ve bunlar tipik olarak kullandığım dillerdir.