La risposta più semplice è la revisione del codice (e la revisione di codice , intendo davvero "tutto ciò che riguarda le modifiche al codice incluso il codice stesso." Ovviamente questo significa che devi avere documentazione.
Conosco luoghi in cui la gente sta hackerando da tutte le parti, l'ultimo posto in cui il mio compagno ha lavorato ogni volta che è venuto a correggere un bug che avrebbe preso l'ultimo codice e ... sarebbe cambiato. Una squadra avrebbe apportato cambiamenti in questa direzione e un'altra squadra avrebbe apportato cambiamenti in una direzione diversa. A volte i team hanno cambiato direzione da soli e si è ritrovato con un puro caos in cui nulla è stato fatto al prodotto, ma c'erano costanti e intensi cambi di codice.
Qui è dove hai bisogno di una forma di controllo delle modifiche di tipo non sviluppatore. Se si implementa un sistema in cui le modifiche vengono apportate in modo controllato, e con ciò intendo che chiunque può modificare qualcosa, è solo che hanno bisogno di un motivo per farlo e una qualche forma di autorizzazione che è una buona cosa per progredire.
Quindi puoi imporre che nessuna modifica venga applicata a meno che non sia in risposta a un ticket di modifica. (chiunque può creare un ticket che descriva un problema che deve essere modificato, ovviamente) ma questi biglietti vengono assegnati a una persona oa un team da un responsabile della direzione del prodotto - un analista di business o un'autorità di progettazione tecnica o persino un team che si riunisce. Ciò che è importante è che il cambiamento venga fatto in modo non individuale.
Una volta che ci si prende cura di qualcuno, qualcuno andrà a fare dei cambiamenti e poi li farà rivedere. Ciò significa che qualcun altro vede il codice ma anche le modifiche e la documentazione del ticket. Quindi, se vuoi cambiare il tuo sistema di accesso ai DB, bene ... ma devi descrivere di cosa si tratta, perché è stato cambiato e come funziona ora. Senza tale documentazione il cambiamento fallisce nella sua revisione. Successivamente è possibile implementare 'allenamenti' interni come borse marroni o dojo di codice per garantire che il resto del team venga informato.
Alcune persone resisteranno a questa situazione, ma tendono a essere quelle che controllano costantemente il codice, "codice di taglio" piuttosto che "lavorare sul prodotto". Questa è una distinzione importante da fare, in quanto sviluppatori possiamo essere tutti coinvolti nel concetto che il codice è ciò che è importante - non lo è. Il prodotto che stai creando è ciò che è importante e molto più del semplice codice.
La documentazione non deve essere estesa, quanto basta per dire a qualcun altro cosa hai fatto o come funziona. Può essere un wiki o anche solo delle note sui biglietti - poiché i biglietti invecchiano, svaniscono dalla vista e la documentazione con loro, ma questo è ok in quanto significa che solo i documenti rilevanti e aggiornati vengono conservati. In alternativa puoi avere una wiki di componenti, architettura e utilizzo e che viene tenuta aggiornata come parte di ogni cambiamento di codice. O (la mia preferenza) è di archiviare tutta la documentazione tecnica insieme al codice come documenti di testo in un formato di markup che è incorporato in html dal server di build e presentato su un server web - così chiunque può vedere la documentazione corrente che può essere facilmente aggiornata quando il codice è aggiornato.
Un'ultima risorsa è quella di ottenere un team di architettura che ha la responsabilità di documentare il sistema, ma avranno anche il potere di impedire che vengano apportate modifiche a meno che la documentazione non sia stata aggiornata per prima: molte squadre più sciolte potrebbero non gradire questo più restrittivo approccio, ma se non riescono a farlo funzionare usando i miei suggerimenti, questo è il sistema che dovrebbe essere implementato.