Embed Size (px)
Citation preview
©2011 Google -- [email protected]
Le "Code Review",queste sconosciute
http://www.aleax.it/itbs11_crev.pdf
Il pubblico di questo talk
2
Shu
Ha
Ri
("Impara")
("Distacca")
("Trascendi")
I temi del talk
3
code review: perché mai abbastanza...?"Fagan inspections" vs CR “leggere”CR "troppo leggere" & loro anti-patterngli aspetti “sociali” delle CRil focus delle CR: leggibilitá e aspetti “non testabili” (AUTOMAZIONE é meglio!-)strumenti e processi per CR
Code Review
4
note da tempo (generazioni!) come strumento eccellente x la qualitá del codice
costano molto meno che far trovare i bug dai clienti (o anche da un reparto di QA)scoprono anche problemi inaccessibili ai test e analisi statiche (chiarezza, nomi)
lo sappiamo tutti: sono "best practice"e allora perché le trattiamo cosí male?!
CR fatte occasionalmente o magari maiCR fatte solo formalmente, no sostanza
"Fagan inspection"parte MOLTO pesante di processi pesanti e “ad alta cerimonia”specifiche, piani di test, architettura, &c, vanno pure “ispezionati”, non solo il codicefasi: pianificazione, meeting preliminare,
{preparazione, meeting d’ispezione, rework, verifica/follow-up} 1+ volte"moderator" che decide; ~6 persone/mtg
alta cerimonia -> alto costo, quindi inadatte salvo in processi rigidi & molto formalizzati (...che poi hanno i problemi loro...)
5
Occhio al ROIsmartbearsoftware.comé x vendere i loro prodotti ("Code Collaborator" &c) e servizi, MA con chiarezza e trasparenza, e ottimi materiali gratis in supportocase studies, analisi, biblio, ...riassunto: Fagan é buono, ma leggero é meglio (naturalmente “specie con i loro strumenti”;-)
6
Non troppo leggeri (1)"nessun processo"? le CR NON sono allora il tuo peggiore problema...:
#1: nessun VCS / RCS#2: niente test automatizzatipoi: mancano "team style", controlli di stile automatici, bug/feature tracker, ...
PRIMA guarisci queste ferite sanguinanti,POI passa a occuparti di Code Review!-)
7
Non troppo leggeri (2)se hai processi & tool "quanto basta", ma nessun ruolo in essi per le CR
per cui le CR avvengono raramente o maie/o sono spesso "solo formali"...
forse "non per Quelli Importanti"...?"pair programming" INVECE di CR...?
allora QUESTO é il punto giusto da cui iniziare a migliorare il tuo processo!-)
8
PP o CRil Pair Programming é fantastico, MAnon svolge lo stesso ruolo delle CR!
la coppia facilmente si "sincronizza"varie cose sono chiare a entrambi quelli "che c’erano sin dall’inizio", ma...
forse non chiare ad altri che non c’erano (magari mancano commenti, &c)magari nascondono sottili problemi ("dati abbastanza occhi, tutti i bug sono evidenti": ma 4 spesso non bastano!-)
l’idea migliore: fare *sia* PP, *sia* CR!9
"Non Quelli Importanti"? (1)il "rispetto" x l’autoritá, la fama o l’anzianitá puó “inibire” i reviewer “junior”
non spesso nella cultura “geek” tipo USAma attenzione, culture & persone varianospesso causa anche "CR solo formali"
antidoto: "non criticare, CHIEDI"no: "questo é rotto quando arg == 0"si: "che succede quando arg == 0?"
inquadra come: chiedendo s’imparapuó produrre un fix, un commento, ...
10
"Non Quelli Importanti"? (2)a volte QI hanno ego fragili...!
vedono la perfezione come uno stato,non come uno scopo + un processo che aiuta a muovere in quella direzione!-)effetto negativo sul morale di squadra
magari + dei contributi di QI..."non criticare, CHIEDI" aiuta anche qui
non é un attacco → no riflesso difensivoé un ottimo stile di interazione professionale, utile in tanti altri contesti
11
"CR solo formale" (1)puó essere "eccessivo rispetto"
"se LUI ha scritto il codice in questo modo, non sono degno di criticarLo!"facile da contrastare: spiega che le CR sono un modo di imparare tecniche &c
e lo SONO, spesso e volentieri!
12
"CR solo formale" (2)puó essere "mancanza di buy-in"
il reviewer accetta controvoglia di fare le CR "perché deve", non crede che valgano il tempo e l'energia che gli costanocaso peggiore: "scambio" di CR solo formali fra due programmatori demotivati
come ogni altro aspetto non puó venir solo imposto, va "venduto" efficacemente
ci vuole "evangelismo" (programmatore senior entusiasta, magari consulente)e ci vogliono DATI in supporto alla tesi!
13
Aspetti sociali delle CR (1)unico modello che ho visto funzionare: tutti ricevono continuamente CR, ogni volta
tutti imparano E tutti insegnanonon é che ogni mattina ti fermi a riflettere “devo lavarmi i denti stamane”? Ne fai un’ABITUDINE!-)
(buone abitudini, checklist &c sono una grande idea x produttivitá, time mgmt)
É lo stesso per le CR: igiene del codice!-)
14
Aspetti sociali delle CR (2)“best practice”: tutti, sempre!, invitati a commentare, ma un singolo revisore designato (1 per CR) é responsabile della CR (e follow-up x controllare che i difetti siano correttamente rimediati)... come x qualsiasi altro “action item”!-)potenziale problema: "reviewer shopping"
i problemi sociali si rimediano meglio con rimedi sociali e culturalia volte un “techie fix” puó aiutare (CR automaticamente assegnate a rotazione)
un buon workflow-system aiuta molto15
Cosa NON controllareNON usare la CR per controllare cose come problemi di formattazione del codice, &c
lo stile di squadra DEVE essere controllato automaticamente da strumenti tipo lint (o IDE); fare manualmente lavoro che é facilmente automatizzato é uno spreco!
idem per unit-test e loro coverage, &c...
non porre troppa attenzione a quel che unit-test (&c) coprono bene (...MA...)
16
A U T O M A T I Z Z A L O !
Allora COSA controllare?specialmente le cose che l’automazione non controlla "mai": leggibilitá, chiarezza, nomi significativi (importante: un Data Dictionary)piú, i punti di difficoltá per i test...:
qualitá dei testgestione corretta degli erroriproblemi di “leak” delle risorseproblemi di sicurezza e privacymulti-taskingprestazioniportabilitá
17
Leggibilitá &c: i commenticommenti (& altra documentazione)...:
allineati al codice, ma mai "sua pura ripetizione" (focus: PERCHÉ, non COME...)in italiano (o inglese) correttousano termini allineati con codice e il linguaggio (int o integer, bool o boolean...)PUNTANO a documenti completi su algoritmi complessi o documenti esterni (specifiche, manuali, &c), NON ripetendoli nel bel mezzo del codice (dev’esserci UN punto di “autoritá”, non due o piú;-).
18
Leggibilitá &c: altrocodice chiaro, leggibile, conciso (ma non TROPPO compatto)nomi significativi e coerenti
Data Dictionary e codice ben allineatiIU (se c’é) chiara e secondo lo stile di IU comune a tutto il progetto
MOLTO importante: info di errore, lognon “reinventare la ruota”: *riusare* funzionalitá giá presenti altrove nel progetto (con refactoring, se occorre)
19
Difficoltá per i test (1)coverage a parte, sono ben testati i casi limite e d’errore (con mock, DI, &c)?casi d’errore: se il linguaggio ha eccezioni, sono gestite bene? se no, sono tutti i risultati controllati x possibili errori?leak di memoria (o equivalenti in linguaggi GC)? altri leak di risorse?
é tutto finalizzato correttamente in ogni caso? compresi gli errori? é testato?
20
Difficoltá per i test (2)multi-tasking (ahimé...): race condition? possibili deadlock? é importante essere MOLTO difensivi su questi punto!prestazioni: ottimizzazioni premature? Ma: attenzione anche a evitare gli sprechi (overhead facile da evitare quando il modo veloce é altrettanto semplice), e tenere d’occhio la scalabilitá (se applicabile!)portabilitá? su che piattaforme é stato pienamente testato il codice?
21
Strumenti & Processile CR leggere dovrebbero essere fattibili “in remoto” e in momenti comodi per chi le fa
“di persona”/”a voce” presenta vantaggi, ma richiede coordinazione + pesante
e non lascia la utile “audit trail”utile in casi di sprint / spike
remoto-ma-sincrono (IM, IRC, chat...) é un compromesso (di rado soddisfacente)
un thread di mail (o UX equivalente) puó essere il modello principale...
22
CR via emailcerto non uno strumento nuovo...;-)ma ha molti evidenti vantaggi
disponibilitá universaleuser agent molto personalizzabilifacile automatizzare programmi/script x:
spedire email automatiche se eventiricevere email e agire di consequenze
→ qualunque “strumento nuovo” x le CR DEVE essere progettato per interoperare senza problemi con le CR via email!
23
CR via email: workflow (1)il VCS inizia una CR spedendo un’email al revisore (CC il team) con testo e puntatori/id del change-set ("patch", diff, &c)
puntatori/id molto utili (a seconda del VCS), facilitano l’esame di diff, contesto, interi fileil testo delle diff é spesso ideale per il revisore x positionare commenti/domandemeglio quindi averli entrambi, se possibile
24
CR via email: workflow (2)se possibile, le mail di CR devono essere PRIMA del commit/push del change-set al codebase -- ↑ qualitá di trunk/headse non fattibile (limiti del VCS), usare uno "staging repository" o branch per ogni changeset "committed but unreviewed" eseguire commit/push a trunk/head solo quando la CR é completa e soddisfacentela flessibilitá dei VCS distribuiti permette e facilita molti workflow alternativi
25
CR via email: workflow (3)il revisore commenta su regioni della diff
chiedendo chiarimenti,suggerendo possibili modifiche,indicando probabili problemi (implicite richieste di cambiamenti;-)
altri possono offrire feedback similil’autore DEVE risolvere ciascun caso con piena soddisfazione del revisore: é il revisore che decide!...da cui il probl. del "reviewer shopping";-)
26
dimensione dei changesetmirare a circa 200 righe (a seconda di quanto conciso é il linguaggio;-), COMPRESI i commenti (che sono cruciali per la CR!)ovviamente puó essere necessario averne di meno (piccolo bug-fix, minuscola addizione di feature) perché un singolo changeset non dovrebbe MAI fare "+ di una cosa"changeset troppo grandi portano a CR troppo ardue -- MAI + di 400 right, PER FAVORE...;-)
27
Durata di una sessione CRmai passare + di 60-90 minuti consecutivi in CR: l'efficacia "crolla" circa a quel punto
ci si "abitua" in modo veramente intensoper le CR non c'é, ahimé!, un effetto "getting in the zone" che aiuti (come x programmazione e debugging: é + tipo un meeting...!)
analogamente: non + di una sessione di CR x 1/2 giornata (1 la mattina, 1 il pomeriggio)ovviamente a volte ci sono deadline e altre pressioni, ma... (TBR: un "coding debt"?)
28
"nuovi giocattoli" (solo O.S.)Rietveld (see http://code.google.com/p/rietveld/ e codereview.appspot.com)
é su GAE, quindi non occorre neppure dedicarci un server...;-)ancora abbastanza nuovo, ma maturo
Review Board (http://review-board.org/)Codestriker (http://codestriker.sourceforge.net/) -- in perl!Java Code Reviewer alias JCR (http://jcodereview.sourceforge.net/ -- é in Python e usabile anche per CR non-Java;-)
29
