Regole non scritte di riscrittura del codice di un altro membro del team [chiuso]

Stiamo esercitando la proprietà del codice collettivo. A mio avviso, ciò significa che qualsiasi sviluppatore può modificare qualsiasi riga di codice per aggiungere funzionalità, refactoring, correzione di bug o miglioramento dei progetti.

Ma che dire di una riscrittura completa del codice da uno sviluppatore che è ancora nel team? Prima dovrei chiederglielo? Qual è la migliore pratica?

Penso che una buona comunicazione sia sempre la migliore pratica. Parla con lo sviluppatore e vedi se c'è un motivo per cui è codificato così com'è. Può darsi che abbiano avuto intenzione di tornare indietro e rifattorizzarlo per anni, potrebbe essere che lo abbiano fatto in quel modo per una ragione molto buona, oppure potrebbe essere che entrambi possiate imparare qualcosa dalla conversazione.

Entrare e riscrivere senza previa comunicazione è una ricetta per cattiva volontà.

La premessa di questa domanda solleva una serie di preoccupazioni per me che non credo che nessuna delle risposte esistenti stia adeguatamente cercando di rispondere. Vorrei fare alcune domande di follow-up qui:

1. Sei assolutamente sicuro di parlare di riscrittura e non refactoring? Per definizione, le modifiche allo stile o alla struttura del codice che comportano un'implementazione migliorata (o semplicemente diversa) senza modifiche al comportamento esterno sono un refactor, non una riscrittura. Rompere una routine monolitica di 500 righe in un set di 50 subroutine può comportare la scrittura di un bel po 'di nuovo codice, ma non è una riscrittura. Il termine riscrivere implica buttare via un intero prodotto o funzionalità e ricominciare da capo; non è qualcosa da prendere alla leggera.

2. Se il comportamento del codice originale è così sbagliato, o l'implementazione è così errata da richiedere una riscrittura a tutti gli effetti, perché non è stata colta dal processo del tuo team e affrontata nel suo giusto contesto (cioè tecnicamente piuttosto che socialmente)? Il codice errato o discutibile dovrebbe essere esposto rapidamente a un team sano tramite test, revisioni del codice, revisioni del progetto, ecc. Hai questi?

3. Il responsabile tecnico / tecnico è a conoscenza del problema e, in caso contrario, perché no? Indipendentemente dal tipo di processo svolto, la qualità del codice è normalmente responsabilità del responsabile dello sviluppo. Lui o lei è la prima persona che dovresti chiedere - ovviamente non nel contesto di "così e così ha scritto codice di merda" ma semplicemente "Penso di vedere un grosso problema qui, possiamo parlare di una riscrittura?" Se non garantisce questo tipo di discussione, allora forse non garantisce nemmeno una riscrittura?

4. Se la dimensione e la portata del codice incriminato sono abbastanza grandi da giustificare una discussione seria di una riscrittura, perché è di proprietà esclusiva di uno sviluppatore? La maggior parte se non tutte le volte in cui ho visto il codice e ho pensato di "riscrivere", è stato calpestato da una dozzina di persone diverse e la cattiveria è il risultato diretto dell'accumulo di incoerenze di stile, ipotesi errate o alterate e buon vecchio hacks alla moda. Il codice cresce spine nel tempo proprio a causa della sua proprietà condivisa.

   Il mio punto qui è, è strano che una persona possieda una tale ampiezza di codice in un ambiente che presumibilmente pratica la proprietà collettiva. Altre persone hanno paura di toccare il codice di questo sviluppatore? Hanno paura di sollevare l'argomento? Forse c'è un problema di fondo con la dinamica del tuo gruppo, o con questo sviluppatore in particolare; se c'è, non ignorarlo. O, in alternativa, forse è la prima volta che lavori a questo progetto, e se è così, perché stai pensando a una riscrittura così presto nel gioco? Qualcosa sulla situazione non sembra sommarsi per me.

5. La questione si afferma, al primo comma, any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs. Una riscrittura non farà queste cose? O farà qualcosa in più - e se sì, cosa? Fondamentalmente, quali sono le tue ragioni per voler riscrivere e quanto sei sicuro che trarranno vantaggio dal prodotto o dal team? Non hai bisogno di rispondere per me, ma è meglio avere alcuni punti obiettivi da chiarire se e quando scegli di discuterne con il team.

Sento davvero che questa domanda comporta un'enorme quantità di contesto e non dovrebbe essere risolta senza una comprensione molto chiara di tale contesto. La risposta "corretta" dipende completamente dal team, dal prodotto, dall'organizzazione, dalla personalità, dal processo, dall'ambito del codice originale, dall'ambito delle modifiche e così via e così via. Questo è, IMO, un problema che devi assolutamente affrontare con il tuo team , non in un sito di domande e risposte online.

Perché stai modificando il codice?

Ci sono bug o è un difetto di progettazione più fondamentale?

Nel primo caso, mi preoccuperei di una riscrittura per correggere quelli che potrebbero essere solo piccoli bug nel codice.

In quest'ultimo caso, mentre mi aspetto un avvertimento che il "mio" codice è stato potenzialmente riscritto, sarei perfettamente felice che ciò accada.

Questo è il punto della proprietà del codice collettivo: il codice che scrivi è lì per essere modificato o addirittura sostituito se dovesse succedere qualcosa di meglio.

In generale, se siete tutti d'accordo sul fatto che siete tutti responsabili del codice, allora va bene riscrivere qualsiasi codice se si tratta di un miglioramento. Discutilo prima con l'altro sviluppatore per cortesia. Potrebbero esserci validi motivi per cui è scritto in un certo modo. A livello personale molti sviluppatori vengono investiti emotivamente in ciò che producono e, come altri hanno già detto, non si vuole cattiva volontà.

In particolare, dipende in qualche modo dalle dinamiche del team. Uno sviluppatore senior che sta per riscrivere il codice di uno sviluppatore junior dovrebbe probabilmente eseguire una revisione del codice (il mio sito) con loro prima di riscriverlo. In questo modo lo sviluppatore junior può imparare dalla situazione.

Non importa se lo sviluppatore originale fa parte del team o meno, o anche se sei lo sviluppatore originale. Il tuo team dovrebbe eseguire la riscrittura completa di qualsiasi codice condiviso, per i seguenti motivi:

• Ci vuole molto tempo. Se qualcun altro sta lavorando a una modifica correlata, non vuoi perdere tempo.
• Altre persone hanno una prospettiva diversa. Anche se hai programmato 20 anni, qualcun altro potrebbe sapere cose sulle interazioni con il codice che tocchi raramente.
• Altri sviluppatori sono il "cliente" del codice sorgente. Il codice sorgente è scritto per essere letto da altri sviluppatori. Possono avere requisiti di architettura, input sullo stile o richieste di funzionalità che desideravano in quel codice, ma non hanno avuto tempo. Non vuoi finire un refattore solo per scoprire che un altro sviluppatore ha bisogno che venga refactorizzato in un modo diverso.

Come ha detto Matthew Flynn, è necessario prima parlare con lo sviluppatore. Lo sviluppatore iniziale potrebbe dire cose importanti sulla funzionalità e spiegare perché questa o quella soluzione sono state fornite.

Ma prima di eseguire il refactoring o riscrivere il codice, eseguire un backup o un ramo contenente quel codice. Se il vecchio codice funziona correttamente, ci sarà la possibilità che possa essere recuperato.

Se hai un sistema di controllo del codice sorgente (che presumo tu abbia), quindi, se possibile, refactoring l'intero codice e solo dopo, quando sei sicuro che funzioni bene, controlla.

Non eliminare il vecchio codice, almeno prima di essere sicuro che il nuovo codice funzioni correttamente. Ma lasciare il vecchio codice lì per sempre non è neanche una buona cosa. Ti suggerisco di eliminare il codice qualche tempo dopo, come tra un mese dopo aver superato il test.

Qual è lo scopo?

• Se stai rielaborando alcune righe per essere più efficiente, fallo e basta. Forse chiedi se c'è il pericolo che tu cancelli un comportamento sottile. Segnala la modifica durante la mischia o via e-mail una volta eseguita, a meno che non sia davvero banale (correggere un errore di battitura).

• Se stai rielaborando una classe di dimensioni decenti, probabilmente dovresti chiedere di assicurarti di capire il design / comportamento. Informa le persone in anticipo in modo che chiunque possa lavorare nella stessa area possa essere consapevole e coordinarsi con te.

• Se stai rielaborando un sistema più grande, dovresti assolutamente collaborare con il tuo team per renderli consapevoli delle modifiche e pianificare il progetto.

Se ci sono i tuoi scrittori originali, comunica con loro. Non SOLO per ettiquette, ma per ulteriori informazioni, nel caso in cui vi siano casi o circostanze di cui non siete a conoscenza. A volte, ti diranno qualcosa di prezioso.

Abbiamo un controllo abissale del codice. Al momento ho un sacco di cose che necessitano di revisione e manutenzione e non ho nemmeno nessuno con cui fare la revisione del codice. Gli autori precedenti (a parte moi) non si sono preoccupati di commentare alcun codice. E sono andati dalla compagnia. Non c'è nessuno a cui chiedere del codice.

Quando riscrivo, commento, con i commenti che ho commentato, così come la data e il nome / le iniziali, e perché è stato commentato. Commento un nuovo codice, con nome o iniziali, data, motivo aggiunto, ecc.

Ulteriori commenti vengono fatti in testa al pacchetto (er, di solito), indicando quali funzioni / procs / SQL / etc. sono stati cambiati, con data. Semplifica la consultazione delle sezioni che sono state modificate e tali sezioni dispongono di una documentazione completa.

I commenti sono economici. Le date saranno un indicatore di ciò che è cambiato, e dopo il numero x di (giorni / revisioni / nuovi assunti / ritirati) il codice può essere ripulito dai vecchi commenti e il rimanente è la nuova baseline.

Dalla mia osservazione la pratica generale è: non cancellare mai il codice. Commentalo e tienilo.

La mia pratica è di commentarlo mentre lo sostituisco. (Principalmente come riferimento.) Quindi eliminalo nel commit finale della modifica funzionante. (Ciò richiede il controllo della versione e la comprensione di come ripristinare le modifiche.)

Quando trovo il vecchio codice commentato, provo a eliminarlo in un commit separato con commenti appropriati. Ciò semplifica il ripristino o l'ispezione della modifica qualora fosse necessaria.

Per tutte le modifiche dovresti essere in grado di utilizzare la cronologia delle revisioni per determinare gli sviluppatori che hanno creato il codice. (La cronologia delle revisioni annotata aiuta qui.) Contattateli se possibile per capire perché il codice è così com'è. Su molti progetti, il tempo di pulizia non si verifica e le cose rimangono indietro. Controlla il bug tracker per vedere se esiste una registrazione della pulizia richiesta. A volte le modifiche devono essere ripulite una o due versioni successive.

Se stai modificando il codice, dovrebbe esserci un motivo per cui stai lavorando con quel codice. Verificare con lo sviluppatore originale per scoprire perché il codice è come è. Se esiste un motivo legittimo per non risolverlo, aggiungere un commento che spieghi perché non è stato risolto o perché non dovrebbe essere modificato. Ciò farà risparmiare tempo al prossimo sviluppatore.

Tag come FixMe, ToDo, Bug e Hack possono essere utilizzati per indicare il codice che potrebbe essere modificato in seguito. (È accettabile contrassegnare le limitazioni come Bug e non correggerle se non verranno attivate nelle condizioni richieste.) Potrebbe essere un bug se un programma di contabilità domestica trabocca a 20 milioni di dollari, ma non perderei molto tempo a sistemare esso.

Le modifiche alla revisione del codice devono essere eseguite dallo sviluppatore originale se è opportuno modificare il codice.

Probabilmente dipende dal motivo per cui la riscrittura è necessaria. Se è perché ci sono problemi con ciò che è scritto, e ci sono sempre stati problemi con ciò, è necessario parlarne, se non altro per minimizzare la frequenza con cui il codice deve essere riparato in futuro.

Il mio suggerimento in questo caso è di accoppiare quando si corregge il codice. In questo modo, fornisce un buon esempio degli stati intermedi e (si spera), un po 'di contesto sul perché il codice riscritto è migliore. Inoltre (anche solo come esercizio personale), prova a rifattorizzare il codice per essere migliore senza una riscrittura totale. Sarà più difficile, ma fa bene a te.

D'altra parte, ci sono altre volte in cui è richiesta una riscrittura:

• Il team ha imparato molto da quando il codice è stato scritto e gli sviluppatori che lo hanno scritto lo scriverebbero diversamente ora, anche senza il tuo contributo.

• Un nuovo requisito di funzionalità modifica la situazione in modo che sia appropriata una mini riscrittura mirata.

In questi casi, probabilmente non mi preoccuperei di una conversazione.

Pensandoci, mi sembra che più a lungo il codice è stato lì, meno è probabile che sia necessaria una conversazione.

Penso che @aaronaught abbia formulato alcuni punti positivi, il che porta davvero alla risposta che volevo dare, ovvero che dipende davvero da chi sta apportando la modifica (e perché) e da chi ha scritto il codice.

Nella mia esperienza personale il codice viene normalmente modificato perché o non funziona come previsto, oppure devi semplicemente estendere ciò che effettivamente fa.

In un ambiente di sviluppo Team, non dovresti (e potresti non essere in grado di) parlare con il programmatore originale, tutto dovrebbe essere chiaro dal codice.

Ciò porta quindi alla domanda che consuma la maggior parte del mio tempo, che è ciò che intendeva il programmatore originale, ed è quella domanda che spesso porta alla cancellazione del codice, ed è il motivo per cui dovremmo commentare tutto e dove i programmatori junior inesperti più spesso cadono fallo.

Qualsiasi programmatore che sta cambiando il codice di qualcun altro (refactoring) dovrebbe davvero, per gentile concessione e pratica, copiare lo stesso stile di codifica del codice già in atto, e prima di tutto adottare delle misure per capire come funzionava il codice originale e cosa stava provando e, in realtà, raggiungere. Spesso questo di per sé identifica i bug, ma certamente costringe le persone a sopportare il dolore che la prossima persona avrà guardando il tuo codice.

Nella mia squadra chiunque può cancellare, refactificare o riscrivere qualsiasi cosa e io vedo la "proprietà" come una pratica che genera pigrizia, come se una persona fosse certa di essere informata di eventuali cambiamenti, perché dovrebbe rendere il codice leggibile.

Quindi, in breve, no, non dovresti chiedere all'autore originale del codice, e se guardi il codice che fai, allora è un segno che il suo codice non è abbastanza leggibile o che devi migliorare le tue capacità. Tuttavia, trovo che sia una buona forma lasciare il codice originale in posizione, commentato, fino a quando non sei assolutamente sicuro che nella riscrittura, non hai rimosso accidentalmente la funzionalità richiesta. Nessuno è perfetto.

Spesso il codice è scritto in un certo modo per un motivo. Comunicare la modifica all'autore funziona sempre al meglio.