L'idea è in realtà molto bella. Contrariamente ai flussi di lavoro comuni, mantieni la recensione direttamente nel codice, quindi tecnicamente non hai bisogno di altro che di editor di testo per utilizzare questo flusso di lavoro. Anche il supporto nell'IDE è bello, soprattutto la possibilità di visualizzare l'elenco di recensioni in basso.
Ci sono ancora alcuni svantaggi:
-
Funziona bene per team molto piccoli, ma i team più grandi richiederanno il monitoraggio su ciò che è stato rivisto, quando, da chi e con quale risultato. Sebbene tu abbia effettivamente questo tipo di tracciamento (il controllo della versione ti permette di sapere tutto), è estremamente difficile da usare e cercare e spesso richiede una ricerca manuale o semi-manuale attraverso le revisioni.
-
Non credo che il revisore abbia abbastanza feedback da parte del recensore per sapere come sono stati effettivamente applicati i punti recensiti .
Immagina la seguente situazione. Alice sta rivedendo per la prima volta il codice di Eric. Si accorge che Eric, un giovane sviluppatore, ha usato la sintassi che non è il più descrittivo nel linguaggio di programmazione effettivamente utilizzato.
Alice suggerisce una sintassi alternativa e invia il codice a Eric. Riscrive il codice utilizzando questa sintassi alternativa che crede di capire correttamente e rimuove il commento // BLA corrispondente.
La prossima settimana, riceverà il codice per la seconda recensione. Riuscirà a ricordare che ha fatto questa osservazione durante la sua prima recensione, per vedere come l'ha risolta Eric?
In un processo di revisione più formale, Alice ha potuto immediatamente vedere che ha fatto un'osservazione e vedere il diff del codice pertinente, per notare che Eric ha frainteso la sintassi di cui lei gli parlava.
-
Le persone sono ancora persone. Sono abbastanza sicuro che alcuni di questi commenti finiranno nel codice di produzione e alcuni rimarranno come una spazzatura mentre sono completamente obsoleti .
Naturalmente, lo stesso problema esiste con qualsiasi altro commento; per esempio ci sono molti commenti TODO in produzione (incluso il più utile: "TODO: Comment the code below."), e molti commenti che non sono stati aggiornati quando il codice corrispondente era.
Ad esempio, l'autore originale del codice o il revisore potrebbe andarsene, e il nuovo sviluppatore non capirebbe cosa dice la recensione, quindi il commento rimarrà per sempre, in attesa che qualcuno sia troppo coraggioso per cancellarlo o per in realtà capisco cosa dice.
-
Questo non sostituisce una recensione faccia a faccia (ma lo stesso problema si applica anche a qualsiasi altra recensione più formale che non viene eseguita faccia a faccia).
Specialmente, se la recensione originale richiede una spiegazione, il revisore e il recensore inizieranno una sorta di discussione . Non solo ti troverai con grandi commenti BLA, ma anche quelle discussioni inquinano il registro del controllo della versione .
-
Potresti anche riscontrare problemi minori con la sintassi (che esiste anche per i commenti di TODO). Ad esempio, cosa succede se un lungo commento "// BLA" viene generato su più righe e qualcuno decide di scriverlo in questo modo:
// BLA This is a very long comment which is way beyond 80 characters, so it actually
// fills more then one line. Since the next lines start with slashes, but not "BLA"
// keyword, the IDE may not be able to show those lines, and display only the first one.
-
E infine come una nota minore e molto personale: non scegliere "BLA" come parola chiave. Sembra brutto. ;)
