Hai bisogno di aiuto nel puntare a concentrarti sugli elementi chiave nella fase di revisione del codice? [chiuso]

Uso la seguente lista di controllo. Molti di questi sono tratti dal libro "Codice pulito" e dai principi SOLID.

Logic

• Duplicazione del codice
• Il codice è nel posto sbagliato. Per es. la logica di presentazione è nel livello della logica aziendale e viceversa
• La classe ha troppe responsabilità. Per l'ordine - che gestisce il pagamento, la spedizione, ecc ... Invece quelle responsabilità dovrebbero essere spostate in altre classi.
• Esistono test unitari appropriati che forniscono una buona copertura del codice

La leggibilità

• La funzione è troppo lunga, prova a fare troppe cose
• I nomi di funzione / classe non sono chiari
• Segue gli standard e le convenzioni di denominazione del progetto

Velocità

• Il codice è sufficientemente ottimizzato
• Può influire negativamente su altre parti del sistema
• Ci sarebbero problemi sotto carico

Dato che chiedi specificamente e-book nel tuo aggiornamento, sottolineo che la mia azienda, SmartBear, offre un libro sulla revisione del codice . Sfortunatamente, sembra che tu sia in India, che non è uno dei Paesi in cui attualmente effettuiamo spedizioni. Tuttavia, sarai felice di notare che la pagina di registrazione collegata sopra, include link a diversi capitoli di esempio tratti dal libro.

La nostra raccomandazione generale su checklist di revisione del codice di costruzione , è quella di dedicare tempo ad analizzare i bug che scrivi . Devi andare più in profondità dei singoli casi e pensare alle cause o alle classi di bug sottostanti.

Oltre ai dati empirici, ci sono alcune cose che sono necessariamente bug, ma dovrebbero essere verificate nella revisione del codice per garantire la manutenibilità del software:

• Ci sono test di unità sufficienti?
• Le classi e i metodi sono sufficientemente e chiaramente documentati?
• Le classi e i metodi sono appropriatamente con scope?

Infine, se la tua organizzazione sta semplicemente adottando le revisioni del codice, inizia lentamente e sii paziente.

Sembra che la tua organizzazione possa trarre vantaggio dal tenere una lista di controllo per la revisione del codice. Scrivi uno! Rendono le recensioni più efficaci.

• Inizia con i suggerimenti delle altre risposte qui o da libri come Codice completo .
• Aggiungi altri elementi esaminando il database dei bug e individuando eventuali errori di codifica comuni che sono responsabili di molti bug.
• Incoraggiare tutti a utilizzare l'elenco di controllo nelle recensioni.
• Tieni aggiornato l'elenco di controllo. Di volta in volta, vorrai aggiungere nuovi elementi e rimuovere quelli vecchi.

(1) Il codice risolve il problema che stai cercando di risolvere? (2) Il codice comunica chiaramente la soluzione? (3) Il codice può essere ottimizzato al grado di (1) e (2)?

Ovviamente, i tuoi consigli potrebbero cambiare se stai facendo da mentore a uno sviluppatore junior / laureato. Potresti scoprire che ha una cattiva abitudine di programmazione, come usare numeri magici, codice duplicato, variabili eccessive (la lista continua ...) e vuoi fornire un feedback per aiutare a migliorare le capacità di codifica degli sviluppatori, ma io ho quanto sopra ci sono domande in mente e cerco di orientare le persone verso ciò nelle mie recensioni. Ovviamente vuoi che il feedback della tua revisione del codice sia prezioso e trasferiscilo agli altri sviluppatori.

Hai provato a guardare le ispezioni di Fagan? Non è necessario utilizzare la metodologia / lista di controllo in piena regola, ma sicuramente trarrai vantaggio dagli approfondimenti.

Durante la revisione del codice, con i nostri progetti, ho sempre iniziato notando i punti di ingresso e da lì seguendo le pipeline di dati.

Trova ogni fermata e ogni variazione di flusso o alterazione dei dati lungo la strada fino a quando non avrai una conoscenza di tutti i dati del corso che prenderà dall'inizio alla fine. Confronta il codice con la funzione che il codice sta effettivamente eseguendo.

• La pipeline potrebbe essere semplificata o è necessaria una ristrutturazione?
• In ogni fase i dati arrivano, vanno e funzionano come previsto e in modo intelligente?
• Controlla i loop, controllali ancora e ancora. Considerali spesso.

Dopo essersi accontentati di quanto sopra, di solito la concentrazione si sposta su altri fattori.

• Il codice può essere semplificato mediante astrazione / disostruzione / migliore sintassi o denominazione?
• Rivedi le strutture di dati serializzate come array e vettori, a volte le variabili devono essere promosse da queste alla propria identità e altre volte le variabili devono essere raccolte in esse.
• Il codice può essere semplificato? (Guarda più strong.)
• Seconda ristrutturazione e riavvio dalla pipeline se le modifiche sono significative.