Best practice

Promuovere la responsabilizzazione. Ogni membro del team di progetto dovrebbe essere incoraggiato a creare e possedere un ADR (Architectural Design Record, record di progettazione architetturale). Questo approccio consente di distribuire il lavoro di ricerca architetturale tra i membri del team, riducendo il carico del progettista di soluzioni o del responsabile del team. Inoltre, favorisce il coinvolgimento nel processo decisionale, consentendo al team di adottare rapidamente tali soluzioni invece di considerarle come decisioni imposte dai livelli superiori dell'organizzazione.

Conserva la cronologia ADR. ADRs dovrebbe avere una cronologia delle modifiche e ogni modifica dovrebbe avere un proprietario. Quando il proprietario dell'ADR lo aggiorna, deve modificare lo stato del vecchio ADR in Sostituito, annotare le modifiche nella relativa cronologia del nuovo ADR e mantenere il vecchio ADR nel log delle decisioni.

Pianificare incontri di revisione periodici. Il processo ADR può essere piuttosto intenso all'inizio, se si tratta di un nuovo progetto (greenfield). Ti consigliamo di impostare una cadenza di riunioni regolari in modo da discutere e revisionare gli ADR prima o dopo le attività giornaliere. Con questo approccio, la definizione ADRs si stabilizzerà in due o tre sprint e potrai costruire una solida base con un minor numero di riunioni.

ADRs Conserva in una posizione centrale. Ogni membro del progetto dovrebbe avere accesso alla raccolta di ADRs. Ti consigliamo di archiviarli ADRs in una posizione centrale e di consultarli nella pagina principale della documentazione del progetto. Esistono due opzioni popolari per l'archiviazione ADRs:

• Un repository Git, che semplifica la versione ADRs

• Una pagina wiki, che lo rende ADRs accessibile a tutti i membri del team

Affrontare il problema relativo alla non conformità del codice legacy. Il processo ADR non risolve il problema relativo alla non conformità del codice legacy. Se disponi di un codice legacy che non supporta quanto stabilito ADRs, puoi aggiornare gradualmente la base di codice o gli artefatti obsoleti, introducendo nuove modifiche, oppure il tuo team può decidere di rifattorizzare il codice in modo esplicito creando attività tecniche inutili.