Processo di revisione del codice
Il modo più efficace con cui eseguo attualmente la revisione del codice è il seguente.
- Crea un ramo / biforcazione e etichettalo con il numero del tuo ticket
- Chiedi al tuo sviluppatore di controllare tutto il codice contro quel ramo
- Quando è il momento di eseguire la revisione del codice, uno sviluppatore o un peer senior unisce il ramo alla sua copia di lavoro corrente del trunk e quindi esegue una revisione del codice.
- Se la revisione passa e il ramo incontra la qualità e il problema del ticket, le modifiche vengono unite al tronco.
- In caso contrario, i problemi vengono contrassegnati con lo sviluppatore originale in una discussione 1 su 1 e il ticket può riposizionare l'elenco per la rilavorazione e la revisione oppure viene rilasciato dal rilascio se non c'è abbastanza tempo per la rielaborazione.
Le metriche non funzionano come credi che facciano
Catturare il tipo di metrica "linee di codice" è un Anti-Pattern comune e non dovrebbe avere un posto reale nel processo di revisione del codice.
Ci sono ottimi motivi per cui alcuni tipi di metriche semplicemente non funzionano. Joel Spolsky ha scritto alcuni fantastici articoli sulle metriche e sulle metriche anti-pattern, e in realtà si tratta di ciò che desideri ottenere dalle tue metriche.
Per quanto riguarda le metriche, un grande sviluppatore può scrivere una riga di codice che funzioni più velocemente ed è più efficiente di uno sviluppatore mediocre che scrive 20 righe di codice per fare la stessa cosa.
Le metriche che dovrebbero interessarti a parte la pianificazione basata sull'evidenza sono le metriche relative alla qualità del codice . Pacchetti come NCover eseguono la tua build giornaliera e quindi funzionano abbastanza bene con il processo di revisione del codice precedente.