DOMANDA Nelle code review iniziate dai file di test o quelli di produzione?

[Alberto Bacchelli]

Ciao a tutti,

Mi chiamo Alberto e sono un programmatore Java e Python (e Smalltalk) e ricercatore nel campo della programmazione.

Parlando con altri programmatori, alcuni mi hanno detto che loro iniziano a fare le code review dai file di test (invece che di produzione) ed effettivamente ho trovato anche dei blog post a riguardo.
Voi come iniziate le review? Dai file di test o di produzione? Avete qualche consiglio da darmi a riguardo?

Grazie per il vostro parere!
Alberto

 

[Andretti60]

Ciao Alberto, scusa ma non capisco, penso sia un problema di traduzione e nomenclature, non capisco cosa tu intenda con "file di test o di produzione". Tieni conto che la mia lingua principale è l'inglese.

 

[Giacomo Furlan]

Ciao Alberto,

avendo a monte la conoscenza dello scopo della patch, ritengo sia abbastanza indifferente cominciare dall'implementazione, piuttosto che dai test.

Solitamente comincio a scrivere i test, almeno le linee guida, e poi sviluppo, oppure li scrivo alla fine della prima stesura dell'implementazione (veramente, non sono un fanatico del TDD), ma, secondo me, per quanto riguarda la peer review bisogna considerare una serie di aspetti (in ordine non ordinato, poi ovviamente la lista può restringersi o allungarsi dipendentemente dalla severità della stessa):

• Code style (se c'è l'enforcing, meglio se automatizzato in un ambiente di CI)
• Test verdi (meglio se automatizzato in CI)
• Separazione tra logica ed implementazione (vedi regola di "una funzione per schermata", o altri ultra-nazi come "un file per schermata")
• Chiarezza della logica (se non si capisce, il commento è d'obbligo)
• Omogenizzazione del nuovo codice a quello pre-esistente (vedi: non reinventare la ruota per la centesima volta)
• Typo o nomi poco chiari (anche una variabile dal nome ambiguo può confondere il programmatore)
• Correttezza dei test
• Completezza dei test (code coverage + asserzioni, con dati edge, ossia i casi limite utili a scovare il 90% dei bug)
• Se funzionali, mocking dei soli servizi che non possono essere chiamati in locale (per qualsiasi ragione)

Non so quanto sia utile onestamente cominciare in particolar modo dai test, perché spesso si riducono a (1) creazione di uno scenario e (2) esecuzione di asserzioni e non ti dicono tantissimo della funzionalità, paragonato al leggere l'implementazione stessa.