Quando è giusto modificare il codice scritto da un collega? [duplicare]

Quando è giusto

Quando la modifica migliora la funzionalità del programma o rende il codice stesso più leggibile / manutenibile.

Quando è sbagliato

Quando la modifica danneggia la funzionalità del programma o non ha alcuno scopo se non quello di fornire un lavoro intenso all'editor.

Chi è il proprietario del codice? La società o lo sviluppatore?

Se il proprietario è (come al solito) la società, non ci dovrebbe essere alcuna differenza nella modifica del codice scritto da te o da un collega (a meno che non sia previsto un codice di manutenzione specifico del codice).

L'editing del codice di un altro dovrebbe avvenire mentre il codice si evolve e dovrebbe essere incoraggiato come pratica in modo da avere una proprietà collettiva del codice.

Il codice dovrebbe essere di proprietà di tutto il team; avere un codice che è modificato solo da uno sviluppatore (e quindi solo capito da) è una cattiva idea. Se non sei nel codice che stai apportando le modifiche, probabilmente non lo capisci. Aspettare che l'altro sviluppatore lasci la compagnia o si ammali è il momento sbagliato per imparare il codice.

Avere test unitari dettagliati sul posto e utilizzare il controllo del codice sorgente dovrebbe significare che questa pratica è a basso rischio.

Incoraggiare l'intera squadra a seguire la "regola del boy scout" di zio Bob e cercare sempre di controllare il codice un po 'più pulito di quello che hai controllato è un buon modo per assicurarti che il codice rimanga pulito nel tempo e non decida in un pasticcio illeggibile e non gestibile.

L'unico svantaggio di questo è se questa pratica si trasforma in Guerre di modifica, in cui gli sviluppatori stanno costantemente ripristinando le modifiche reciproche. Questo è probabilmente un segno che non hai deciso uno standard di codifica per qualunque cosa stia causando la guerra di modifica, quindi questa sarebbe una buona opportunità per crearne uno.

Direi che è giusto quando ciò che stai lavorando richiede il cambiamento. È giusto quando ti è stato assegnato un bug e il bug è in quel codice.

Se il codice non ha nulla a che fare con ciò su cui stai lavorando, ma deve essere corretto, quindi portalo alla guida della squadra e fagli assegnare una priorità per risolverlo e assegnare una persona (potrebbe non essere tu ) per risolverlo. Se dice di non passare il tempo su di esso, allora è logico risolvere in quel punto. Vieni pagato per lavorare su ciò a cui sei stato assegnato per lavorare e non su ciò su cui vuoi lavorare. Indubbiamente fai presente che è necessario cambiarlo, ma l'impostazione prioritaria è il lavoro del manager e non il tuo.

È sbagliato modificare il codice di lavoro solo a causa di una preferenza personale.

È sbagliato quando non si capisce quale problema il codice è stato progettato per risolvere o addirittura comprendere il codice. Solo perché non funziona per i tuoi bisogni, non significa che non romperai qualcosa se ti metti a letto con esso. Se hai bisogno di cambiarlo per fare ciò che stai facendo, vai a parlare con il programmatore dell'origine del perché ha fatto quello che ha fatto e ciò che potrebbe essere influenzato se lo cambi per soddisfare le tue esigenze. Non cambiare MAI codice che non capisci a meno che non funzioni. Questo non significa che non si aggiusti mai il codice, significa solo che finché non si prende il tempo per comprenderlo a fondo, non lo si cambia, specialmente se è già in produzione.

When is it right to edit the code written by a co-worker?

Dipende dalla fase in cui si trova il prodotto. Se il prodotto è già stabile e già rilasciato, non apporterei alcuna modifica che non sia necessaria a meno che non ci sia stato un grande cambiamento necessario per un codice veramente brutto.

For which issues is it right to edit the code written by a co-worker?

Non vorrei fare il pasticcio sulla formattazione del codice. Dovresti refactor quando il codice è eccessivamente complesso e deve essere comunque modificato o causa problemi e non sembra funzionare correttamente.

Come stackexchange o wiki, dovresti essere pronto a condividere il tuo codice e consentire a chiunque di modificarlo finché le modifiche rientrano nel design e negli obiettivi globali. Ma poniti una domanda: perché qualcuno dovrebbe modificare il codice di qualcun altro se non lo fa per il debug? Hai tagliato in modo preciso il tuo progetto in parti sufficienti per consentire la parallelizzazione della codifica attraverso più programmatori contemporaneamente?

Se, allo stesso tempo, per funzionalità diverse, sei costretto a modificare lo stesso codice del tuo collega, c'è un intreccio di codice e una cattiva "separazione delle preoccupazioni". Dovresti rivedere il tuo design per consentire a ciascun programmatore di lavorare su diverse parti del codice di base del software.