Bir mimari açıklama belgesi KURU Prensibinin ihlali midir?

KURU Prensibi (Kendinizi Tekrarlamayın) “her bilgi parçasının bir sistem içinde tek, açık, yetkili bir temsile sahip olması gerektiğini” belirtir. Çoğu zaman bu kod anlamına gelir, ancak genellikle belgelere de genişletilir.

Her yazılım sisteminin seçmiş olsanız da olmasanız da bir mimariye sahip olduğu söylenir. Diğer bir deyişle, oluşturduğunuz yazılım bir yapıya sahiptir ve bu "yapılı" yapı yazılımın mimarisidir. Yerleşik bir yazılım sistemi bir mimariyle birlikte geldiğinden, bu sistemin mimari bir tanımını oluşturmak KURU Prensibinin ihlali midir? Sonuçta, mimariyi bilmeniz gerekiyorsa, o zaman her zaman koda bakabilirsiniz ...

Düşüncelerinizi koda kopyalamak KURU ilkesini ihlal ediyor mu?

Tanrım, mimariyi koda bakarak tanıyabilirseniz, ilk etapta "mimari açıklama belgeleri" diye bir şey olmazdı. Bu bir tekrar değil, koddan önemsiz bir şekilde çıkarılamayan başka bir sistem açıklaması seviyesi . Bu yüzden, KURU kucaklasanız bile var olma hakkı vardır.

DRY'yi zor ve hızlı bir kural olarak almayın. Bu iyi bir şey, ama sadece pratikte yaklaşık olarak tahmin edebilirsiniz.

Ayrıca iyi yazılmış olmadığını düşünüyorum. "Kendinizi tekrarlamayın", anlamsal veya işlevsel bir değişiklik yapmak için kaynak metni birden fazla yerde, farklı ama koordineli şeyler söyleyerek düzenlemek zorunda kalacağınız kadar önemli bir durumu kapsamıyor gibi görünmüyor.

İhlal edilmeyecek bir emir olarak almak yerine, bunun neden iyi bir fikir olduğunu anlamak ve bu konuda mantıklı seçimler yapmak daha iyidir. Birden fazla yerde koordineli düzenlemeler yapmanın kötü olmasının nedeni, editör olarak hata yapmanızdır. Değişiklikleri hatasız yapmak için% 100 güvenilir değilsiniz. 10 farklı kaynak metin değişikliği yapmanız gerekiyorsa ve bunlardan sadece 9 tanesini doğru alıyorsanız, bir hata yaparsınız . Bu nedenle, koordine edilen değişikliklerin sayısını en aza indirgemek için kaynak metni düzenlemek iyi bir şeydir. Hataları en aza indirir.

DRY'nin emirlerden biri olduğu bir dine ait değiliz. Biraz yanıltıcı olsa da, bazı sağduyu kapsüllemek için kullanışlı bir yoldur.

Mimari Açıklama veya Yazılım Tasarım Açıklaması DRY'yi ihlal ediyor. Bununla birlikte, projelerin geçen yıl, geliştiricilerin gelip gittiği ve sistemin herhangi bir kişinin tüm detayları kafasında tutamayacağı kadar büyük olduğu büyük bir organizasyonda, kritik bir belgedir. Senkronize olmasını sağlamak için gereken "tekrar" miktarı, bir sonraki güncelleme veya bakım sırasında kaydettiği çaba için tamamen buna değer.

Bir mimari açıklama KURU ilkesini ihlal etmez.

Yazılım sisteminiz elbette bir mimari ile geliyor. Ve birçok sınıfta, birçok sınıfta, bir bakış için gereksiz olan birçok yabancı ve ayrıntı ile yayılır.

Mimari belgeniz bir haber raporunun ilk paragrafı gibi olmalıdır: bu bir taslak, özet, projenin yol haritasıdır.

Belgeyi tarihlendirirseniz, yazı yazıldığı sırada mimariyi tanımlar.

Oysa kod şu anda mimariyi temsil ediyor.

İki ayrı şey - aynı bilgi değil.

Belgenin yazma sırasında mimariyi temsil ettiğini belirttiğiniz sürece, bilgi IMO'sunu çoğaltmıyorsunuz çünkü farklı bilgileri, sistemle ilgili başka bir noktada ise.