Come scegliere l'approccio migliore quando si aggiungono funzioni / codice di refactoring

Per me, la risposta è conoscere il tuo codice base. Quando salti nel mezzo di un progetto, ci sono molte cose già in atto e non saprai come tutto va a pezzi. Più lavori, più conosci il sistema e più facile sarà prevedere alcuni degli effetti che una modifica potrebbe avere sul tuo sistema nel suo insieme.

Le altre grandi cose sono chiedere ad altre persone. Parla ai tuoi colleghi di ciò che vuoi cambiare e di come pensi che dovrebbero essere cambiati. Probabilmente hanno una migliore comprensione delle sezioni di codice in cui non trascorri molto tempo. Potranno aiutarti a capire se le tue potenziali modifiche potrebbero influire sulla loro sezione del codice.

Modifica
Se sei la persona più anziana del progetto, parla ancora con le persone. Anche se sei l'unico sul progetto, parlare di un problema aiuta. Non hai nemmeno bisogno di una persona reale con cui parlare .

Oltre a ciò, prendi molte note. Un brain su un pezzo di carta di ieri può essere molto utile per ricordare a te stesso a cosa stavi pensando l'ultima volta che stavi lavorando. Puoi anche generare un diagramma UML del tuo codice base per vedere come tutto è interconnesso. Stampa questo, datalo e mettilo sulla tua bacheca. La data è importante perché le cose cambiano continuamente e devi sapere quando è il momento di creare nuove note o diagrammi.

Il commento chiave qui è "Molto spesso non è fino al momento del test che scopro"

Quello che faccio sono i test di scrittura (soprattutto unit test) che controllano il codice prima di apportare le modifiche. I test eseguiti correttamente prima e dopo mostrano che ottengo lo stesso comportamento.

EDIT dopo i commenti di @Robert Harvey - la mia idea è di dare l'idea che l'OP possa trovare più informazioni.

Cerca Test Driven Development per una versione più completa di questo e per il quale puoi trovare molte spiegazioni più dettagliate.

Questa è, ovviamente, una situazione molto comune. La rottura inattesa è uno dei principali indicatori di design degradanti. Tale rottura è dovuta agli accoppiamenti che legano i moduli insieme che non ti aspetti di interagire l'uno con l'altro. Gestire e minimizzare questi accoppiamenti sono responsabilità che ricadono su ogni programmatore. Quindi, qualcuno non ha fatto il loro lavoro!

Ci sono alcuni principi che governano le dipendenze tra i moduli. Un lotto a cui ho un determinato allegato è chiamato "SOLID". Puoi leggere su di loro in un documento chiamato "Principles and Patterns" che troverai nella sezione "Risorse" di cleancoder.com.

Anche quando segui assiduamente questi principi, a volte ti capiterà comunque di subire una rottura inaspettata. E, naturalmente, non si trova su questa rottura fino al tempo di test unitario (se tale tempo esiste). Quindi la soluzione è fare in modo che il tempo di test dell'unità arrivi presto. Prima era il migliore, infatti.

Ecco perché molti di noi usano la disciplina dello sviluppo basato sui test (TDD) che puoi trovare descritta in un documento intitolato " The Bowling Game ". Questa disciplina sposta il tempo di test unitario molto presto. È così presto, infatti, che viene prima di scrivere qualsiasi codice di produzione! Quando il tempo di test unitario è quello in anticipo, scopri molto rapidamente la rottura improvvisa.

Questo è esattamente il motivo per cui facciamo ATDD al mio lavoro. I nostri test di accettazione sono automatizzati e vengono eseguiti con ogni commit, inoltre è previsto che tutti gli sviluppatori eseguano l'intera suite prima di ogni commit. Li usiamo come altri negozi usano i test unitari.