L'antipattern Architecture by Implication (architettura per "sottintesi") è un tipico problema dell'architettura del software legato alla superficialità. Un'affermazione tipica di chi sta per incorre in questo antipattern è: «Sistemi come questi sono la nostra specialità» oppure «Certi aspetti sono impliciti nel problema».
Contesto
In ogni progetto l'esperienza gioca un ruolo fondamentale, l'aver affrontato problemi simili nel passato permette d'avere una visione più completa e realistica su ciò che si deve fare.
L'esperienza è un bagaglio essenziale per qualsiasi buon architetto, poter contare su di essa è fondamentale e permette di diventare un importante punto di riferimento per l'intero team di lavoro.
Tuttavia se essa sfocia in presunzione e superficialità nell'affrontare i nuovi problemi, diventa deleteria e può provocare il fallimento del progetto.
L'antipattern architecture by implication si verifica quando un team di lavoro (o l'architetto responsabile) ritiene superflua una pianificazione architetturale in quanto si ha già esperienza nella costruzione di progetti simili.
Cause
Le cause che portano all'introduzione di questo antipattern sono:
- Mancanza di gestione dei rischi
- Eccessiva fiducia nella propria esperienza
- Mancanza di una pianificazione architetturale
- Errata convinzione che esistano sempre problemi che ammettono la medesima soluzione
- Superficialità nella fase d' analisi
Sintomi
I dettagli cha fanno da sentinella per riconoscere questo antipattern sono:
Conseguenze
Le conseguenze di tale antipattern sono:
- Mancanza di linee guida
- Rischio di realizzare componenti di concezione obsoleta
- Prestazioni inadeguate
- Esigenze fraintese o addirittura ignorate
Eccezione
Questa tipologia di approccio è giusta quando, dopo un'attenta analisi architettonica, si riscontra una forte similitudine con un progetto precedente, in tal caso è corretto sfruttare le esperienze pregresse per il nuovo progetto.
Non solo è giusto, ma riprogettare da zero un qualcosa già esistente ci fa incorrere in un antipattern già analizzato: reinvent the wheel.
Soluzione
Per evitare d'incorrere in questo antipattern vi sono precise metodologie, una di queste (la più famosa) prende il nome di GQA ovvero goal question architecture. Tale procedimento può essere così sintetizzato:
- Definire chiaramente gli obiettivi dell'analisi architetturale
- Definire le "questions" principali per centrare gli obiettivi
- Decidere le viste (abbiamo descritto brevemente le viste nell'articolo introduttivo agli antipatterns architetturali)
- Analisi delle viste
- Verifica delle viste
- Effettuare una validazione delle viste in relazione ai requisiti
- Perfezionare le viste fino a quando ogni problema non avrà una corretta soluzione
- Rendere la pianificazione architetturale chiara e di facile comprensione per l'intero team
- Produrre un'adeguata documentazione
Seguire con accuratezza i passi sopra elencati non solo permette di ottenere un progetto architetturale chiaro e completo, ma anche di poter confrontare i risultati ottenuti con altri progetti e determinare se è possibile un loro riutilizzo.