Ci sono odori architettonici?

• Architettura multitier 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 da perdersi nel codice.
• Architettura futuristica Ciò accade quando la soluzione è troppo futuristica. In realtà nessuno può prevedere nuovi requisiti. Pertanto la maggior parte dell'attuazione futuristica è solo uno spreco di tempo e risorse.
• Architettura entusiasta della tecnologia L'architetto ha apprezzato la nuova tecnologia e ha messo in produzione. Senza sapere se è stato provato prima.
• Over Kill Architecture Un semplice problema è stato risolto dal fattore esponenziale delle competenze e della tecnologia dell'architettura.
• Architettura cloud Lo chiamo architettura cloud dal momento che l'architettura non ha alcuna connessione con il reale. Sono solo alcuni bei diagrammi di Visio.

Anche la mancanza totale del contrario è vera.

Questo è il link di Top Ten errori di architettura del software .

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

Il problema è che puoi davvero fornire solo meccanismi di configurazione per ciò che pensi che dovrà essere configurato in questo momento, ma una volta che la tua applicazione è nella natura, non sarà sufficiente. Quindi, i meccanismi di configurazione si espandono e si espandono e alla fine ottieni l'Inner Platform Effect.

E poi ti trovi nell'inferno del software.

Un database progettato da un ORM! O un backend di database che non è relazionale e che dovrebbe essere relazionale. Oppure un database in cui si progetta di utilizzare viste che chiamano viste che chiamano 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 rintracciare (Oltre all'astrazione come ha detto @AmirResaei, è facile perdersi nel codice quando è necessario correggere qualcosa che si trova in fondo a tutti questi livelli.)

Gli odori di codice e gli odori architettonici sono la stessa cosa. Il codice inizia a "annusare" a causa dell'architettura sub-ottimale.

Nel libro fondamentale di Martin Fowler sull'argomento, Refactoring , presenta una serie di Code Smells e identifica il modo di rifattorizzarli dal tuo sistema. Il Refactoring to Patterns di Joshua Kerievsky enfatizza ulteriormente questa idea dando specifici pattern architettonici per correggere vari odori di codice (e come ridirigerli passo dopo passo).

La maggior parte del refactoring viene fatto per alleviare il codice suboptimale tramite un'architettura migliorata. Si potrebbe sostenere che l'unico "Architectural Smell" naturalmente nato (oltre a Big Ball of Mud), sarebbe l'architettura BDUF (Big Design Up Front). Dove provi a sistemare tutto ciò di cui hai bisogno prima che venga scritta la prima riga di codice. Un progetto software agile in cui il design viene eseguito secondo le necessità (anche io oso dire dove codice è stato trattato come design ), la sua architettura crescerà organicamente.

(Un sacco di) Accoppiamento - in qualsiasi forma - è ciò che rende l'odore dell'architettura. Più è accoppiato, più odora.

Detto questo: nessun accoppiamento sente spesso problemi di prestazioni.

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

Ciò è certamente OK in alcune situazioni (ad es. report luminosi), ma in molti casi i requisiti di elaborazione delle transazioni e dei report sono in conflitto. Tuttavia, poiché è la cosa semplice / economica da fare, i report vengono eseguiti direttamente al di fuori del DB transazionale. Ciò causa tutti i tipi di mal di testa su entrambi i lati dell'equazione.

Questo è tipicamente visibile nelle app LOB aziendali, btw. Capisco che molti SMB non abbiano le risorse o il know-how per creare magazzini e datamarts (dimentichi i cubi o le impostazioni di riduzione delle mappe), ma molte delle organizzazioni più grandi con cui ho lavorato hanno gli stessi problemi.

Durante la progettazione di un sistema, l'architetto deve essere consapevole del fatto che il reporting, in particolare i report di analisi, e i requisiti transazionali vengono trattati come problemi separati e non solo raggruppati a livello di database.

Non sono sicuro che questo si adatti giustamente al livello di architettura, ma se vedo un gruppo di classi / moduli manager in quello che dovrebbe essere un progetto OO, allora è una garanzia che l'unica persona che capirà il architettura / design è l'architetto / designer stesso senza molte spiegazioni / apprendimento da parte degli altri.

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

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

Recentemente ho preparato una tassonomia degli odori . Attualmente, documenta 38 odori architettonici e oltre 260 odori di codice totali.