Quindi ero impertinente nel mio commento, ma, dovrebbe essere il caso e non solo che dovrebbe esserci un processo definito per quello che succede e per quanto tempo la build può rimanere rotta prima che il codice venga appena tirato indietro ancora una volta.
- Se uno sviluppatore non può creare il prodotto prima di verificarne il codice, allora il progetto è troppo grande o non abbastanza modulare.
- Se lo sviluppatore A ha cambiato l'API e questo ha rotto i test, lo sviluppatore A avrebbe dovuto vederlo e dovrebbe essere stato contrassegnato prima di apportare le modifiche.
- Se la suite completa di test è enorme e può essere eseguita solo durante la notte, dovrebbero essere suddivisi in suite più piccole. Di solito questi si riferiscono ai moduli del tuo progetto e quindi ai test di unità e integrazione.
- Hai CI che è fantastico, è impostato per interrogare il tuo SCM per le modifiche ed eseguire alcuni test sugli aggiornamenti?
- Con quale frequenza viene eseguito il check in del codice, è possibile che i check in siano troppo grandi e trarrai vantaggio da check-in più frequenti.
- Forking / Branching può essere utile per gestire diversi flussi di sviluppo se i tuoi sviluppatori stanno controllando modifiche non correlate che potrebbero violare il codice degli altri in modi che non avrebbero potuto prevedere.
- Qualunque sia il processo, dovrebbe essere raro che B stia risolvendo il codice di A.
- Sii sempre pragmatico.
Non credo che la diffusione delle correzioni (in questo caso) sia utile, in primo luogo trarrai vantaggio dalla programmazione delle coppie intorno alle aree problematiche. In sostanza, essere proattivo non è reattivo. Puoi dare tutti i bug di bassa priorità ai tuoi nuovi sviluppatori e familiarizzare con l'intero codebase:)
Riguardo a
and if no tests ever broke, the utility would be lost
È sciocco. Se quello che stai dicendo è che ti manca una copertura di codice sufficiente per dire se una funzione fondamentale del codice è stata sovvertita e questo è il motivo per cui non si verificano interruzioni di test allora sì, mancano di utilità. Ovviamente i test dovrebbero interrompersi (e se stai praticando il TDD dovrebbero anche iniziare a rompersi), ma il punto è che dovrebbero essere interrotti (e risolti, con o senza cooperazione tra A e B) sulla macchina degli sviluppatori.
Anni fa alcuni esponenti di Eastenders hanno scritto alcune cose a riguardo, ma probabilmente ci sono un milione di nuove risorse da citare .. Martin Fowler dice .