Quanti bug di regressione dal refactoring sono troppi.

Hai ragione che il codice di refactoring è importante. Previene la decomposizione del codice e migliora il codice. Rende il codice più pulito.

Ma il buon codice non è solo un codice pulito, è un codice corretto, e quindi per definizione contiene il minor numero possibile di bug (idealmente nessuno). Il primo obiettivo del tuo codice è produrre il risultato atteso. Quindi se il tuo refactoring sta introducendo bug, potresti prendere in considerazione l'effetto netto di questi refactoring.

Dovresti refactoring il codice che è testato. In caso contrario, aggiungere test e quindi refactoring. In questo modo sai che non hai infranto nulla. Questo aiuterà a mitigare i rischi che una situazione simile possa accadere in futuro.

Per quanto riguarda il refactoring dell'introduzione di bug, il refactoring non dovrebbe alterare il comportamento di un programma. Citerò da Wikipedia :

disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior

Purtroppo oggigiorno, il refactoring ha finito per significare qualsiasi cosa, da questa definizione a riscritture totali.

Modificherei ciò che ha detto il tuo team:

refactor but don't break too many things

A:

refactor and don't break anything

Per quanto riguarda il fatto che i bug sono il lavoro del QA, la qualità non è un problema di qualcun altro. L'obiettivo dovrebbe essere che il QA non trova nulla. Trovare realisticamente il meno possibile.

My stance is it's QA's job to find bugs that we can't find,

Trovare bug è una responsabilità condivisa.

Il lavoro di QA è trovare i bug che non trovare. Non dovrebbe esserci una cosa come bug che non puoi trovare. (E se c'è, allora forse dovresti chiedere l'accesso agli strumenti / test che stanno utilizzando in modo che tu possa trovarli per te.

refactoring usually introduces breaking changes.

Questo non è vero. Il refactoring eseguito correttamente non rompe le cose. E potresti obiettare che sistemare le cose che si rompono dovrebbero far parte del refactoring.

I problemi sorgono nella realtà quando:

• il refactoring attiva i bug latenti in altre parti del codebase che i test che puoi eseguire non rivelano, o

• non puoi eseguire il refact completo perché qualcun altro "possiede" alcune parti del codice che sono interessate dal refactore.

Non dovresti incolpare la colpa dei bug latenti (a meno che non fossero tuoi in primo luogo). D'altra parte, se il tuo refactoring sta modificando intenzionalmente API e / o comportamenti, devi discuterne con tutte le parti prima che hai refactoring e avere un piano per gestire gli effetti. Nella terza mano ¹ , se il cambiamento di rottura è inaspettato o accidentale ... allora dovresti averlo pensato in modo più dettagliato.

E infine, se le regressioni fossero colpa tua (o in parte colpa tua), allora "man up" e prendi la colpa. E mirare a fare meglio la prossima volta.

If he agrees that refactoring is necessary (which he does), then why does he have a problem when stuff breaks? Especially when it hasn't affected our schedule so far.

È facile rispondere se ti metti nei suoi panni. Pensa che hai fatto la cosa sbagliata nel modo in cui hai rifattorizzato il codice. Questa volta non ha avuto alcun impatto sul programma. Ma la prossima volta potrebbe. Sta cercando di impedire questa eventualità.

^{1 - Allusione a Larry Niven.}