Ci sono odori di architettura?

Ci sono tonnellate di risorse sul web che fanno riferimento e elencano gli odori del codice. Tuttavia, non ho mai visto informazioni sugli odori dell'architettura . È definito da qualche parte ed è disponibile un elenco? Sono state fatte ricerche formali sui difetti dell'architettura e sul loro impatto sulla velocità del progetto, i difetti e simili?

Modifica: non stavo davvero cercando un elenco nelle risposte, ma la documentazione (sul web o in un libro) sugli odori dell'architettura.

• Architettura a più livelli Quando hai livelli su livelli su livelli su livelli ... vedi il mio punto qui, nella tua applicazione. Lo chiamo Over Layered Architecture
• Oltre l'astrazione in modo tale che ti perdi nel codice.
• Architettura futuristica Questo accade quando la soluzione è troppo futuristica. In realtà nessuno può prevedere nuovi requisiti. Pertanto, la maggior parte dell'implementazione futuristica è solo una perdita di tempo e risorse.
• Tecnologia Entusiasta Architettura L'architetto ha apprezzato la nuova tecnologia e ha messo in produzione. Senza sapere se è stato dimostrato prima.
• Over Kill Architecture Un semplice problema è stato risolto dal fattore esponenziale delle capacità e della tecnologia dell'architettura.
• Architettura cloud La chiamo architettura cloud poiché l'architettura non ha alcun legame con il reale. Sono solo dei bei diagrammi di Visio.

Anche la totale mancanza del contrario è vera.

Ecco il link dei primi dieci errori dell'architettura software .

Tutto è configurabile . Quando un architetto ti dice che il suo sistema è a prova di cambiamento o altamente personalizzabile a causa dell'ampia configurabilità, questo è un odore di architettura.

Il problema è che puoi davvero fornire solo meccanismi di configurazione per ciò che pensi che in questo momento dovrà essere configurato, ma una volta che la tua applicazione è in libertà, non sarà sufficiente. Quindi, i meccanismi di configurazione si espandono e si espandono e alla fine si ottiene l'effetto della piattaforma interna.

E poi sei all'inferno del software.

Un database progettato da un ORM! O un back-end di database non relazionale che dovrebbe essere relazionale. O un database in cui si progetta di utilizzare viste che richiamano viste che richiamano viste, non solo sono troppo lente (i database devono essere progettati per le prestazioni dall'inizio non più tardi) ma quando è necessario apportare una modifica, sono orribili da tracciare attraverso (Oltre l'astrazione, come diceva @AmirResaei, è facile perdersi nel codice quando è necessario correggere qualcosa che è in fondo a tutti quei livelli.)

Odori di codice e odori architettonici sono la stessa cosa. Il codice inizia a "annusare" a causa dell'architettura non ottimale.

Nel libro fondamentale di Martin Fowler sull'argomento, Refactoring , presenta una serie di odori di codice e identifica il modo in cui rimuoverli dal sistema. Refactoring to Patterns di Joshua Kerievsky sottolinea ulteriormente questa idea dando schemi architettonici specifici per correggere vari odori di codice (e come fare il refactoring su di essi passo dopo passo).

La maggior parte del refactoring viene eseguita per alleviare il codice non ottimale tramite un'architettura migliorata. Si potrebbe sostenere che l'unico "odore architettonico" nato naturalmente (diverso da Big Ball of Mud), sarebbe l'architettura BDUF (Big Design Up Front) Architecture. Dove si tenta di accogliere tutto ciò che serve prima che venga scritta la prima riga di codice. Un agile progetto software in cui il design viene eseguito in base alle esigenze (anche io oso dire dove il codice viene trattato come design ), farà crescere organicamente la sua architettura.

(Molti) L'accoppiamento, in qualsiasi forma, è ciò che rende le architetture odorose. Più è accoppiato, più odora.

Detto questo: nessun accoppiamento causa spesso problemi di prestazioni.

Ecco un odore concreto di architettura / design che incontro continuamente: analisi e reportistica direttamente da un database transazionale.

Questo è certamente OK in alcune situazioni (es. Report leggeri), ma in molti casi i requisiti di reportistica ed elaborazione transazionale sono in conflitto. Tuttavia, poiché è la cosa semplice / economica da fare, i report vengono eseguiti direttamente dal DB transazionale. Ciò provoca ogni sorta di mal di testa su entrambi i lati dell'equazione.

Questo è generalmente presente nelle app LOB aziendali, tra l'altro. Capisco che molte PMI non hanno le risorse o il know-how per creare magazzini e datamart (dimentica i cubi o le impostazioni di riduzione delle mappe), ma molte organizzazioni più grandi con cui ho lavorato hanno gli stessi problemi.

Durante la progettazione di un sistema, l'architetto dovrebbe davvero essere consapevole del fatto che i report, in particolare i report di analisi, e i requisiti transazionali sono trattati al meglio come problemi separati e non solo raggruppati a livello di database.

Non sono sicuro che ciò si adatti a livello di architettura, ma se vedo un gruppo di classi / moduli manager in quello che dovrebbe essere un progetto OO, questa è una garanzia che l'unica persona che capirà l'architettura / design è l'architetto / designer stesso senza molte spiegazioni / apprendimenti da parte di altri.

Ci sono molti odori di architettura documentati dalla comunità. Un set che si verifica comunemente è il seguente.

• Dipendenza ciclica: questo odore si presenta quando due o più componenti dell'architettura dipendono l'una dall'altra direttamente o indirettamente.
• Dipendenza instabile: questo odore si presenta quando un componente dipende da altri componenti che sono meno stabili di se stesso.
• Componente divino: questo odore si verifica quando un componente è eccessivamente grande in termini di LOC o numero di classi.
• Concentrazione delle caratteristiche: questo odore si verifica quando un componente realizza più di una preoccupazione / caratteristica architettonica.
• Funzionalità sparse: questo odore si presenta quando più componenti sono responsabili della realizzazione della stessa preoccupazione di alto livello.
• Struttura densa: questo odore si presenta quando i componenti hanno dipendenze eccessive e dense senza una particolare struttura.

Di recente ho preparato una tassonomia degli odori . Attualmente, documenta 38 odori di architettura e oltre 260 odori di codice totali.