Stiamo esercitando la proprietà collettiva del codice. A mio parere questo significa che qualsiasi sviluppatore può modificare qualsiasi linea di codice per aggiungere funzionalità, refactoring, correggere bug o migliorare i progetti.
Ma per quanto riguarda una completa riscrittura del codice da uno sviluppatore che è ancora nel team? Dovrei chiederlo prima? Qual è la migliore pratica?
Penso che una buona comunicazione sia sempre la migliore pratica. Parla con lo sviluppatore e vedi se c'è una ragione per cui è codificata così com'è. Può essere che abbiano significato tornare indietro e rifattorizzarlo per anni, potrebbe essere che lo abbiano fatto per una buona ragione, o potrebbe essere che entrambi possano imparare qualcosa dalla conversazione.
Entrare e riscrivere senza comunicazione preventiva è una ricetta per malevolenza.
La stessa premessa di questa domanda solleva una serie di preoccupazioni per me che non penso che nessuna delle risposte esistenti stia cercando di affrontare adeguatamente. Lasciami fare alcune domande di follow-up qui:
Sei assolutamente sicuro di parlare di riscrittura e non di refactoring? Per definizione, le modifiche allo stile o alla struttura del codice che risultano in un'implementazione migliorata (o semplicemente diversa) senza modifiche al comportamento esterno sono un refactoring, not una riscrittura. Rompere una routine monolitica di 500 righe in un insieme di 50 subroutine può comportare la scrittura di un bel po 'di nuovo codice, ma non è una riscrittura. Il termine riscrivi implica l'eliminazione di un intero prodotto o funzionalità e la ripartenza da zero; non è qualcosa da prendere alla leggera.
Se il comportamento del codice originale è così sbagliato, o l'implementazione è così bacata da richiedere una riscrittura completa, perché non è stata catturata dal processo del team e indirizzata nel suo contesto corretto (cioè tecnicamente piuttosto che socialmente)? Il codice cattivo o discutibile dovrebbe essere esposto rapidamente a una squadra in buona salute tramite test, recensioni di codici, revisioni di progetti, ecc. Avete questi?
Il responsabile / responsabile tecnico è a conoscenza del problema e, in caso negativo, perché no? Indipendentemente dal tipo di processo che hai, 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ì ho scritto crap code" ma semplicemente "Penso di vedere un grosso problema qui, possiamo parli di una riscrittura? " Se non garantisce questo tipo di discussione, allora forse non garantisce una riscrittura?
Se le dimensioni e la portata del codice incriminato sono abbastanza grandi da giustificare una seria discussione su una riscrittura, perché è di proprietà esclusiva dello sviluppatore one ? La maggior parte se non tutte le volte in cui ho visto il codice e ho pensato "riscrittura", è stato calpestato da una dozzina di persone diverse e la cattiveria è il risultato diretto dell'accumulo di incoerenze stilistiche, ipotesi errate o alterate e buon vecchio hack di moda. Il codice aumenta le spine nel tempo proprio perché della sua proprietà condivisa.
Il mio punto qui è che è strano che una persona possieda una tale quantità di codice in un ambiente che presumibilmente esercita la proprietà collettiva. Le altre persone hanno paura di toccare il codice di questo sviluppatore? Hanno paura di sollevare l'argomento? Forse c'è un problema di fondo con il tuo gruppo dinamico, o con questo sviluppatore in particolare; se c'è, non ignorarlo. Oppure, in alternativa, forse è la tua prima volta che lavori a questo progetto, e in tal caso, perché tu stai pensando a una riscrittura così presto nel gioco? Sembra che qualcosa riguardo alla situazione non mi renda conto.
La domanda afferma, nel primo paragrafo, 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 extra - e se sì, cosa? Fondamentalmente, quali sono le tue ragioni per voler fare una riscrittura e in che misura sei sicuro che potranno beneficiare del prodotto o del team? Non devi rispondere per me, ma è meglio avere alcuni punti obiettivi da fare se e quando decidi di discuterne con il team.
Sento veramente che questa domanda implica una grande quantità di contesto e che non dovrebbe essere risolta senza una chiara comprensione di quel contesto. La risposta "corretta" dipende completamente dal team, dal prodotto, dall'organizzazione, dalla personalità, dal processo, dallo scopo del codice originale, dall'ambito delle modifiche e così via. Questo è, IMO, un problema che devi assolutamente utilizzare con il tuo team , non su un Q & Un sito 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 bug minori nel codice.
In quest'ultimo caso, mentre mi aspetto che un "heads-up" sia potenzialmente riscritto, sarei perfettamente felice che ciò accada.
Questo è il punto di proprietà del codice collettivo: il codice che scrivi è lì da modificare o addirittura sostituire se qualcosa di meglio arriva.
Generalmente, se siete tutti d'accordo sul fatto che siete tutti responsabili per il codice, allora è ok riscrivete qualsiasi codice se è un miglioramento. Discutilo con l'altro sviluppatore prima come cortesia. Ci possono essere validi motivi per cui è stato scritto in un certo modo. A livello personale molti sviluppatori ottengono emotivamente investito in ciò che producono e, come altri hanno già detto, non volete cattive intenzioni.
In particolare dipende in qualche modo dalla dinamica del team. Uno sviluppatore anziano che sta per riscrivere il codice di uno sviluppatore junior dovrebbe probabilmente eseguire una revisione del codice (il mio sito) con loro prima semplicemente riscrivendolo. In questo modo lo sviluppatore junior può imparare dalla situazione.
Non importa se lo sviluppatore originale è nel team o no, o anche se sei lo sviluppatore originale. La completa riscrittura di qualsiasi codice condiviso deve essere eseguita dal tuo team, per i seguenti motivi:
Come diceva Matthew Flynn, è necessario parlare prima con lo sviluppatore. Lo sviluppatore iniziale potrebbe dire cose importanti sulla funzionalità e spiegare perché è stata fornita questa o quella soluzione.
Ma prima di refactoring o riscrittura del codice, o fare un backup o ramo contenente quel codice. Se il vecchio codice funziona correttamente, resterà la possibilità che possa essere ripristinato.
Se hai un sistema di controllo del codice sorgente (che presumo tu abbia), quindi, se possibile, rifatta l'intero codice e solo dopo, quando sei sicuro che funzioni bene, controllalo.
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 è una buona cosa. Ti suggerisco di eliminare il codice qualche tempo dopo, come in un mese dopo aver superato il test.
Qual è lo scopo di esso?
Se stai rielaborando alcune righe per essere più efficienti, fallo e basta. Forse chiedi se c'è il pericolo che tu cancelli un comportamento sottile. Segnala la modifica durante scrum o via email una volta terminata, a meno che non sia davvero banale (correggendo un refuso).
Se stai rielaborando una classe di dimensioni decenti, dovresti probabilmente chiedere di capire il design / comportamento. Fai sapere alle persone in anticipo in modo che chiunque possa lavorare nella stessa area possa essere consapevole e coordinato con te.
Se stai rielaborando un sistema più grande, dovresti sicuramente collaborare con il tuo team per renderli consapevoli delle modifiche e pianificare il progetto.
Se i tuoi scrittori originali sono lì, comunica con loro. Non solo per l'ettiquette, ma per ulteriori informazioni, nel caso in cui ci siano casi o circostanze di cui non si è a conoscenza. A volte, ti diranno qualcosa di prezioso.
Abbiamo un controllo del codice abissale. Attualmente ho un sacco di cose che necessitano di revisione e manutenzione, e non ho nemmeno nessuno con cui fare revisione del codice. Gli scrittori precedenti (a parte moi) non si sono preoccupati di commentare alcun codice. E sono andati via dalla compagnia. Non c'è nessuno da chiedere sul codice.
Quando riscrivo, commento, con commenti che ho commentato, oltre a data e nome / iniziali e perché è stato commentato. Commento un nuovo codice, con nome o iniziali, data, motivo è stato aggiunto, ecc.
I commenti aggiuntivi vengono fatti al capo del pacchetto (ehm, di solito), indicando quali funzioni / procs / SQL / etc. sono stati cambiati, con data. Semplifica la ricerca delle sezioni che sono state modificate e quelle sezioni hanno una documentazione completa.
I commenti sono economici. Le date saranno un indicatore di ciò che è cambiato e dopo il numero x di (giorni / revisioni / nuove assunzioni / ritiri), il codice può essere pulito di vecchi commenti e il rimanente è la nuova linea di base.
Dalla mia osservazione la pratica generale è: non cancellare mai il codice. Basta commentare e tenerlo.
La mia pratica è di commentarlo mentre lo sostituisco. (Principalmente per riferimento.) Quindi cancellarlo sul commit finale della modifica di lavoro. (Ciò richiede il controllo della versione e una comprensione di come ripristinare le modifiche.)
Quando trovo il vecchio codice commentato, cerco di cancellarlo in un commit separato con i 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.) Se possibile, contattali per capire perché il codice è così com'è. In molti progetti, il tempo di pulizia non si verifica e le cose vengono lasciate indietro. Controlla il bug tracker per vedere se c'è un record della pulizia richiesta. A volte i cambiamenti devono essere ripuliti prima o dopo.
Se stai modificando il codice, dovrebbe esserci un motivo per cui stai lavorando con quel codice. Verifica con lo sviluppatore originale per scoprire perché il codice è come è. Se esiste un motivo legittimo per non risolverlo, aggiungi un commento che spieghi perché non è stato corretto o perché non dovrebbe essere modificato. Questo salverà il prossimo sviluppatore qualche volta.
Tag come FixMe, ToDo, Bug e Hack possono essere utilizzati per indicare il codice che potrebbe essere modificato in seguito. (È accettabile etichettare le limitazioni come Bug e non correggerle se non verranno attivate nelle condizioni richieste.) Potrebbe essere un errore se un programma di contabilità domestica supera i 20 milioni di dollari, ma non perderei molto tempo per sistemare esso.
Le modifiche alla revisione del codice dovrebbero essere fatte 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 , allora è necessario parlarne, se non altro per ridurre la frequenza con cui il codice deve essere corretto in futuro. / p>
Il mio suggerimento in questo caso è di pair quando correggi il codice. In questo modo, fornisce un buon esempio degli stati intermedi e (si spera) un contesto su perché il codice riscritto è migliore. Inoltre (se solo come esercizio personale), prova a rifactoring 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 viene richiesta una riscrittura:
Il team ha imparato molto dal momento in cui è stato scritto il codice e gli sviluppatori che lo hanno scritto lo avrebbero scritto diversamente ora, anche senza il tuo input.
Un nuovo requisito per le funzionalità cambia la situazione in modo tale che una mini-riscrittura mirata sia appropriata.
In questi casi, probabilmente non mi preoccuperei di una conversazione.
Pensandoci, mi sembra che più lungo è stato il codice, meno è probabile che una conversazione sia necessaria.
Penso che @aaronaught abbia fatto alcuni buoni punti, il che porta davvero alla risposta che volevo dare, che dipende in realtà da chi sta apportando il cambiamento (e perché) e da chi ha scritto il codice.
Nella mia esperienza personale il codice viene normalmente modificato perché non funziona come previsto, o semplicemente è necessario estendere ciò che effettivamente fa.
In un ambiente di team dev, non dovresti (e potresti non essere in grado) parlare con il codificatore originale, tutto dovrebbe essere chiaro dal codice.
Questo porta alla domanda che consuma la maggior parte del mio tempo, che è ciò che intendeva il programmatore originale, ed è quella domanda che più spesso porta alla cancellazione del codice, ed è il motivo per cui dovremmo commentare tutto, e dove inesperti i programmatori più giovani cadono spesso in fallo.
Qualunque programmatore che sta cambiando il codice di qualcun altro (refactoring) dovrebbe davvero, per cortesia e pratica, copiare lo stesso stile di codifica del codice già in atto, e prima prendere provvedimenti per capire come funzionava il codice originale, e cosa stava provando a, e realmente andando, a raggiungere. Spesso questo in sé identifica 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, refactare o riscrivere qualsiasi cosa, e io considero la proprietà come una pratica che genera pigrizia, come se una persona fosse sicura di essere informata di eventuali modifiche, perché avrebbero bisogno di rendere leggibile il codice .
Quindi, in breve, no, non dovresti chiedere all'autore originale del codice, e se guardando il codice che fai, allora è un segno che il suo codice non è sufficientemente leggibile, oppure tu bisogno di migliorare le tue abilità Tuttavia, trovo che sia buona norma lasciare il codice originale in posizione, commentato, fino a quando non sei assolutamente sicuro che, riscrivendo, non hai rimosso accidentalmente la funzionalità richiesta. Nessuno è perfetto.
Spesso il codice è scritto in un certo modo per una ragione. Comunicare il cambiamento all'autore funziona sempre per il meglio.
Leggi altre domande sui tag programming-practices code-ownership