Utilizza un processo di revisione formale

Funziona, se questo è davvero parte di un processo che tutti i membri devono seguire.

Significa che quando viene avviata una revisione del codice, ci si aspetta che ci siano commenti e che questi commenti DEVONO essere interpretati, discutendoli e scartandoli o implementando un cambiamento.

Collega al tuo Issue Tracker per le azioni successive

Se vuoi essere extra formale (che potrebbe essere richiesto a seconda dell'ambiente e della procedura di controllo), potresti persino aprire nuovi ticket nel tracker per ogni azione richiesta, che può quindi essere chiusa come fissa o respinta con commenti necessari per chiarimenti. Se sono necessarie ulteriori revisioni, apri una richiesta di revisione (supponendo che tu abbia uno strumento per farlo). Le modifiche al codice devono essere verificate, preferibilmente dal revisore originale.

Fai attenzione a paralizzare il tuo Codebase

Se ciò non fa parte del processo, è probabile che tali commenti diventino simili a codice morto o marcatura del codice e probabilmente lasceranno più interrogazioni che risposte dietro. Quindi, se non si dispone di un processo di revisione formale, si potrebbe voler evitare quelli, tranne se è per il tracciamento personale e si mantiene una scheda stretta su di essi. Questi dovrebbero preferibilmente avere una vita breve e agire rapidamente. Oppure non dovrebbero essere TODO ed essere commenti di codice effettivi su ciò che è sbagliato e devono essere modificati se si tratta di un cambiamento importante, per servire come avvertimento ad altri sviluppatori.

Fornisco ulteriori motivi contrari (nel caso generale) tag di azione in linea e commenti in linea inutili in questa risposta a proposito di uso di commenti incorporati non documentabili .

In effetti, se puoi e hai lo strumento giusto per farlo, ti suggerisco di evitarli per le revisioni del codice e di utilizzare una recensione del codice e uno strumento di annotazione del codice che permetta di separarlo dal codice.

Fai affidamento sugli strumenti di revisione del codice e di annotazione del codice

È una decisione difficile da prendere, come a volte preferiresti avere tutto con il codice nel tuo SCM (in effetti c'è anche uno strumento di revisione del codice per Eclipse che memorizza i commenti di revisione nei file di testo insieme ai file sorgente, per esempio). Ma per i team e i progetti più grandi funziona abbastanza bene con strumenti dedicati per annotare il codice e avere discussioni estese registrate da qualche parte, nel contesto del tuo codice. Puoi anche collegarli alle revisioni di codice correnti, alle attività o direttamente ai commenti su un file o su un changetset.

^{Nelloscreenshotquisopra,adesempio,puoivedereunadiscussionethreadeddirettamenteinlineaconilcodiceperevidenziareunproblema,equestovienefattocomepartediunelementodirevisionecoreformale(conl'IDCR-ANERDS-8)relativoaunticketaperto(conIDANERDS-7).}

^{Ecco un esempio di un caso d'uso in cui crei un nuovo ticket per essere in grado di tracciare le azioni di follow-up future sulla recensione. Il revisore può facilmente creare attività mentre esegue il setacciamento del codice e nota le zone ombreggiate.}

Ci sono numerosi strumenti per questo, ma personalmente tendo a trovare FishEye e Crucible sopra la pari (e ovviamente lavorando magnificamente con JIRA, o anche con Confluence per collegare a documenti ancora più dettagliati se necessario).

Nella mia esperienza questo non funziona perché nessuno prende sul serio questi commenti. Niente è più divertente che vedere "TODO: sbarazzarsi di questo al più presto" e quindi fare svn biasimare e notare che il commento è lì da quasi un decennio.

Quello che devi veramente fare è assicurarti che il tempo effettivo per lo sviluppatore sia dedicato al refactoring e che le attività di refactoring siano ben definite (non a tempo indeterminato). Devi presentare questo al manager e delineare i problemi e il vantaggio economico di farlo.

Ad esempio: "Le funzionalità di implementazione X e Y diventeranno molto più semplici e impiegheranno molto meno tempo se rifattiamo per la prima volta Z. Dedichiamo un po 'di tempo al refactor Z!"

Questo mi sembra un problema culturale, quindi suggerirei di lavorare sulla cultura. Come risposta indiretta alla tua domanda, ho avuto successo introducendo questo argomento di proprietà collettiva del codice e il processo di refactoring avviando un club di libri tecnici.

Pulisci codice di Bob Martin e Lavorare efficacemente con il codice legacy di Michael Feathers fa un buon lavoro nell'esplorare questi argomenti.

Ho sperimentato, che i commenti da soli non cambieranno nulla. Se i programmatori non parlano affatto - tranne che attraverso il commento del codice - qualcosa non va. L'aggiunta di un // Todo ora e poi non risolverà il tuo problema, potrebbe addirittura peggiorarli. Ad esempio se qualcuno si sente offeso.

Se trovi qualcosa che valga la pena di refactoring (e sei sicuro di aver capito perfettamente il pezzo di codice E l'impatto sul programma esistente, fallo e basta. Se non pensi di avere una comprensione assoluta del codice (questa potrebbe essere la ragione per cui vuoi refactoring in primo luogo), prova a contattare lo sviluppatore iniziale. Coinvolgilo nel processo, discuti di ciò che puoi fare e sono sicuro che sarà un valido partner attraverso l'intero processo di refactoring.