Mimari kokular var mı?

Web'de kod kokularına atıfta bulunan ve listeleyen çok sayıda kaynak var. Ancak, mimari kokular hakkında hiç bilgi görmedim . Bu bir yerde tanımlanmış mı ve mevcut bir liste var mı? Mimari hatalar ve bunların proje hızı, kusurlar ve benzeri üzerindeki etkileri hakkında herhangi bir resmi araştırma yapılmış mı?

Düzenleme: Cevaplarında gerçekten bir liste aramıyordum, fakat mimarlık kokuyor hakkında belgeler (web'de veya bir kitapta).

• Çok Katmanlı Mimari Katmanlardaki Katmanlardaki Katmanlar olduğunda, uygulamanızdaki noktayı görürsünüz. Ben buna Katmanlı Mimari denir.
• Bu şekilde soyutlamada kodda kaybolursunuz.
• Fütüristik Mimari Bu çözüm çok fütüristik olduğunda olur. Gerçekte kimse yeni gereksinimleri öngöremez. Bu nedenle fütüristik uygulamanın çoğu zaman ve kaynak kaybıdır.
• Teknoloji Hevesli Mimari Mimar yeni teknolojiyi beğendi ve üretime geçti. Daha önce kanıtlanmış olup olmadığını bilmeden.
• Öldürme Mimarisi Üzerine Basit bir problem, üstel mimarlık becerileri ve teknolojisi faktörü ile çözüldü.
• Bulut Mimarisi Bulut mimarisi olarak adlandırıyorum çünkü mimarinin gerçekte bağlantısı yok. Sadece güzel Visio diyagramları.

Bunun tam tersi de geçerlidir.

İşte En İyi On Yazılım Mimarisi Yanlışlığının linki .

Herşey Yapılandırılabilir . Bir mimar size, sistemin geniş kapsamlı yapılandırılabilirlik nedeniyle değişime dayanıklı olduğunu ya da çok özelleştirilebilir olduğunu söylediğinde, bu bir mimari kokusudur.

Sorun şu ki, şu anda yapılandırılması gerekeceğini düşündüğünüz şey için yalnızca yapılandırma mekanizmaları sağlayabileceğinizden, ancak uygulamanız vahşi olduğunda, yeterli olmayacaktır. Ardından, yapılandırma mekanizmaları genişler ve genişler ve sonunda İç Platform Etkisi'ni alırsınız.

Ve sonra yazılım cehennemdesin.

Bir ORM tarafından tasarlanan bir veritabanı! Veya ilişkisel olması gereken ilişkisel olmayan bir veritabanı arka ucu. Veya görünümleri çağıran görünümleri çağıran görünümleri kullanmak için tasarladığınız bir veritabanı, yalnızca çok yavaş değiller (veritabanları daha sonra baştan başlayarak performans için tasarlanmalıdır), ancak değişiklik yapmanız gerektiğinde, izlemek için korkunç olurlar. (@AmirResaei'nin söylediği gibi aşırı soyutlama, tüm bu katmanların altındaki bir şeyi düzeltmeniz gerektiğinde kodda kaybolmanızı kolaylaştırır.)

Kod kokuları ve mimari kokuları aynı ve aynıdır. Kod, optimal olmayan alt yapı nedeniyle "koklamaya" başlar.

Martin Fowler'in Refactoring konulu kitabında, bir dizi Kod Kokusu sunuyor ve bunları sisteminizden çıkarmanın yolunu belirliyor. Joshua Kerievsky'nin Desenlere Yeniden Düzenlenmesi, çeşitli kod kokularını düzeltmek için özel mimari desenler vererek bu fikri daha da vurguluyor (ve onlara nasıl adım adım yeniden bakacakları ).

Çoğu yeniden düzenleme, alt yapı kodunu gelişmiş mimari aracılığıyla azaltmak için yapılır. Doğal olarak doğan tek "Mimari Koku" nun (Büyük Çamur Topu hariç) BDUF (Önden Büyük Tasarım) Mimarisi olduğu söylenebilir. İlk kod satırı yazılmadan önce ihtiyacınız olan her şeyi barındırmaya çalıştığınız yer. Tasarımın gerektiği gibi yapıldığı çevik bir yazılım projesi ( kodun tasarım olarak kabul edilmesine neden olsa bile ) mimarisinin organik olarak büyümesini sağlayacak.

( Birçoğu ) Bağlanma - her ne şekilde olursa olsun - mimarileri koklayan şeydir. Ne kadar çok bağlanırsa o kadar kokar.

Bununla birlikte, hiçbir bağlantı hiçbir zaman performans sorunlarının kokusunu almaz.

İşte her zaman karşılaştığım bir somut mimari / tasarım kokusu: işlem ve veri tabanından doğrudan raporlama.

Bu, bazı durumlarda kesinlikle sorun yok (örneğin hafif raporlar), ancak çoğu durumda raporlama ve işlemsel işleme gereksinimleri çakışıyor. Ancak, yapılması kolay / ucuz bir şey olduğu için, raporlar doğrudan işlemsel DB'den çıkarılır. Bu, denklemin her iki tarafında her türlü baş ağrısına neden olur.

Bu genellikle Enterprise LOB uygulamalarında, btw'de görülür. Birçok KOBİ'nin sadece depo ve datamart'lar (küpleri unut ya da haritayı azaltan kurulumlar) yaratacak kaynaklara ya da know-how'a sahip olmadığını, ancak birlikte çalıştığım birçok büyük şirketin aynı sorunları yaşadığını biliyorum.

Bir sistemi tasarlarken, mimar gerçekten raporlamanın - özellikle de analiz raporlarının - ve işlem gereksinimlerinin ayrı ayrı olarak ele alındığını ve sadece veri tabanı düzeyinde toplanmayacağının farkında olmalıdır.

Bunun mimari düzeyde doğru bir şekilde uyup uymadığından emin değilim, ancak bir OO tasarımı olması gereken şeyde bir grup yönetici sınıfı / modülü görüyorsam, o zaman mimarlığı / tasarımı anlayacak olan tek kişinin garantisidir. başkaları tarafından çok fazla açıklama / öğrenme olmaksızın mimar / tasarımcıdır.

Topluluk tarafından belgelenen birçok mimari koku var. Yaygın olarak meydana gelen bir dizi aşağıdadır.

• Döngüsel Bağımlılık: Bu koku, iki veya daha fazla mimari bileşen doğrudan veya dolaylı olarak birbirine bağlı olduğunda ortaya çıkar.
• Kararsız Bağımlılık: Bu koku, bir bileşen kendisinden daha az kararlı olan diğer bileşenlere bağlı olduğunda ortaya çıkar.
• Tanrı Bileşeni: Bu koku, bir bileşen LOC veya sınıf sayısı bakımından aşırı büyük olduğunda ortaya çıkar.
• Özellik Konsantrasyonu: Bu koku, bir bileşen birden fazla mimari endişe / özellik gerçekleştirdiğinde ortaya çıkar.
• Dağınık İşlevsellik: Bu koku, birden fazla bileşenin aynı üst düzey kaygıyı gerçekleştirmekten sorumlu olduğu zaman ortaya çıkar.
• Yoğun Yapı: Bu koku, bileşenlerin belirli bir yapıya sahip olmayan aşırı ve yoğun bağımlılıklara sahip olması durumunda ortaya çıkar.

Geçenlerde koku taksonomisi hazırladım . Şu anda, 38 mimari koku ve 260'dan fazla toplam kod koku belgeliyor.