qual è il modo migliore per garantire la responsabilità nei controlli del codice?

Due semplici misure:

1. Recensioni del codice (già menzionate da altri) prima di ogni controllo. Non è necessario spiegare ogni dettaglio di ciò che si registra, ma il revisore deve farsi un'idea delle modifiche che si stanno verificando. È possibile programmare il proprio RCS rifiuta i check-in il cui testo del check-in non contiene un tag "RIVEDUTA DA: ...".
2. Accordati con il resto della squadra che se un check-in rompe i test unitari, lo sviluppatore che ha eseguito il check-in deve correggere il codice fino a quando quei test unitari sono di nuovo verdi (misura possibile: scrivi un bug e assegna a lui / lei). In alternativa: se un membro della squadra rileva un check-in che interrompe i test unitari, lui o lei può annullare le modifiche. L'autore del check-in errato non è autorizzato a effettuare il check-in fintanto che il problema non viene risolto localmente (i test unitari sono verdi localmente).

Nota

Il punto 2 è stato modificato tenendo conto del commento di gnat.

Se usi git per il controllo della versione, controlla gerrit. Certo, può essere un rompicapo, ma richiede che le revisioni del codice avvengano prima che un commit venga unito al repository.

Penso che la tua squadra abbia bisogno di frequentare un corso di mischia agile e fare un patto per seguire la metodologia.

Quando gli sviluppatori eseguono il check-in di piccole modifiche al codice assegnate a piccole attività, riduce la possibilità che gli sviluppatori abbandonino le rotaie e eseguano il check-in del codice in conflitto. Ciò aumenta l'integrazione continua.

"I've seen some junior developers check in code that breaks use cases, which is usually identified by another developer a few days after the check-in."

Anche in un mondo perfetto ciò accade ancora. Se trovi che succede spesso e / o dopo diversi giorni di sviluppo, hai un problema.

Penso che troverai che il team lavorerà insieme in modo più efficace con una iterazione pianificata. Ti suggerisco di provare uno sprint di 2 settimane. Inizia lo sprint con un incontro scrum approfondito. Passa attraverso il backlog di Bugs and Work Items, accettando le priorità principali e scrivendole su post-it notes con unità / stime temporali utilizzando le carte da poker di pianificazione .

Allinea una plancia di mischia o una lavagna bianca e assicurati che le persone lavorino solo su una cosa alla volta. Una volta terminato il compito, devono scrivere un test unitario per questo. Una volta scritto un test dell'unità di lavoro, dovranno ottenere una revisione del codice. Revisioni di codici costruttivi sono una delle migliori tecniche per impedire agli sviluppatori di verificare accidentalmente conflitti di codice.

Dopo che Code Reviewer è stato disconnesso, lo sviluppatore esegue il Check-In Dance:

• Lascia che il resto della squadra sappia che sta arrivando un cambiamento se si tratta di un aggiornamento significativo.
• Ottieni l'ultimo codice dal controllo del codice sorgente.
• Fai un'unione con qualsiasi conflitto.
• Esegui la build localmente e correggi i problemi riscontrati.
• Esegui i test delle unità localmente e correggi i problemi riscontrati.
• Conferma le modifiche al controllo del codice sorgente.
• Interrompe la codifica fino al termine della generazione.

Se la build si rompe, elimina tutto e aggiusta la build.

Team Foundation Server (TFS) facilita tutta questa roba immediatamente.

Dovresti correggere i test prima di andare avanti. Ma solo perché l'80% del codice è stato testato unitamente, ciò non significa che sia a prova di bug. Gli sviluppatori devono essere attivi nel test della loro socialità di codice. Questa integrazione del codice è molto più facile da ottenere usando metodologie non-waterfall.

I second reviews di codice. Alcuni strumenti ti consentono di effettuare revisioni prima che il codice venga eseguito come richieste di pull Github. Altri ti consentono di vedere chi ha toccato ogni riga come SVN dà la colpa.

Personalmente, preferirei che i membri del mio team impegnassero spesso il codice nel bagagliaio anche se non è perfetto. Aumenta le possibilità che qualcun altro noterà un problema e consente i vantaggi dell'integrazione continua.

Facciamo revisioni formali del codice alla fine di un'attività. Eseguo anche revisioni "casuali" del codice mentre le persone lavorano e si impegnano. Il random è tra virgolette, perché all'inizio rivedo più pesantemente per addestrare bene le persone a testare. Offrirò anche l'accoppiamento per testare in modo che gli sviluppatori acquisiscano le competenze. Il random è anche tra virgolette perché le persone che scrivono codice / test peggiori vengono scelti più spesso per le recensioni casuali. Mantengo anonime le recensioni casuali - la direzione non ne parla mai - sono una pratica puramente di squadra.

Ciascuno dei seguenti dovrebbe ridurre drasticamente il rischio che un giovane codice commetta male:

• Associa programmazione , preferibilmente con uno sviluppatore senior come navigatore

• Pre-commit recensioni del codice di uno sviluppatore senior

Una cosa bella di questi è che sono orientati alla collaborazione, non alla biasimazione, che IMO è sicuramente qualcosa che dovresti favorire quando si integrano i programmatori junior.