Quando interrompere la revisione del codice?

Puoi fare tutto ciò che funziona per te, ma le tue revisioni del codice non mostrano i bug reali (e non solo i "problemi di bellezza")? Raramente ho visto una situazione in cui il nuovo codice non aveva abbastanza bug da giustificare una recensione.

Inoltre, le tue recensioni non assicurano che ci sia almeno una seconda persona (a parte l'autore) che conosce il codice? E se dovessi smettere di fare revisioni periodiche del codice, non ti aspetti che i problemi che hai elencato sopra torneranno probabilmente (almeno, occasionalmente)?

Quindi rispondi a queste domande per te stesso, quindi sai se interrompere le revisioni periodiche del codice è una buona o una cattiva idea.

no proper code comments. method are too big. no null pointer checking. no proper exception handling etc.

Alcuni di questi sono solo piccoli problemi che la revisione del codice può catturare.

I grandi metodi e le eccezioni sbagliate sono effettivamente problemi, e sembra che tu non stia eseguendo il test delle unità (o almeno non correttamente).

Ciò che è più importante sono le cose grandi:

• problemi di progettazione - è importante rilevare i problemi di progettazione prima, piuttosto successivamente
• per familiarizzare con il codice degli altri - non sai mai quando qualcuno andrà via
• impara qualcosa di nuovo - qualcuno potrebbe suggerirti nuove idee

Per dirla chiaramente, la revisione del codice è non proprio per individuare i bug (anche se potrebbe farlo), cioè test. Lo scopo della revisione del codice è principalmente quello di mantenere modelli di progetto, codice pulito, evitare soluzioni locali.

Utilizzare uno strumento è utile, ma vale sempre il tempo e lo sforzo per un controllo a quattro occhi per mantenere buone pratiche nel progetto. Anche i programmatori più esperti dovrebbero lasciare che il loro codice sia sottoposto a una revisione del codice. Le pratiche a volte diventano obsolete o ripensate. In Java posso consigliare i lavori di Adam Bien sul ripensamento dei vecchi schemi. Se la squadra è eterogenea (diversi posti di lavoro passati + anni), la normale revisione del codice è di vitale importanza per evitare la codifica caotica.

Solo per menzionare un ovvio motivo per cui dedicare del tempo alla revisione del codice: se il codice viene esaminato e diventa omogeneo nelle pratiche, chiunque può andare in vacanza senza costare continuamente le proprie soluzioni. Dal momento che il codice è simile, altri possono effettivamente gestire anche i moduli non familiari del programma in caso di bugfixing. Anche se qualcuno parte dal progetto, non ci saranno moduli con soluzioni orribili che nessuno capisca.

Quindi quando fermarsi? Mai. La revisione periodica del codice ti ripaga a lungo termine. Rende il codice più facile da mantenere.