Le "Code Review", queste sconosciute http://www.aleax.it/itbs11_crev.pdf 2011 Google -- aleax@google.com
Il pubblico di questo talk Shu ("Impara") Ha ("Distacca") Ri ("Trascendi") 2
I temi del talk code review: perché mai abbastanza...? "Fagan inspections" vs CR leggere CR "troppo leggere" & loro anti-pattern gli aspetti sociali delle CR il focus delle CR: leggibilitá e aspetti non testabili (AUTOMAZIONE é meglio!-) strumenti e processi per CR 3
Code Review 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 mai CR fatte solo formalmente, no sostanza 4
"Fagan inspection" parte MOLTO pesante di processi pesanti e ad alta cerimonia specifiche, piani di test, architettura, &c, vanno pure ispezionati, non solo il codice fasi: 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 ROI smartbearsoftware.com é x vendere i loro prodotti ("Code Collaborator" &c) e servizi, MA con chiarezza e trasparenza, e ottimi materiali gratis in supporto case 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 automatizzati poi: 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 mai e/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 CR il Pair Programming é fantastico, MA non 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 USA ma attenzione, culture & persone variano spesso 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 impara puó 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 costano caso 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 insegnano non é 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 culturali a volte un techie fix puó aiutare (CR automaticamente assegnate a rotazione) un buon workflow-system aiuta molto 15
Cosa NON controllare NON 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! A U T O M A T I Z Z A L O! idem per unit-test e loro coverage, &c... non porre troppa attenzione a quel che unit-test (&c) coprono bene (...MA...) 16
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 test gestione corretta degli errori problemi di leak delle risorse problemi di sicurezza e privacy multi-tasking prestazioni portabilitá 17
Leggibilitá &c: i commenti commenti (& altra documentazione)...: allineati al codice, ma mai "sua pura ripetizione" (focus: PERCHÉ, non COME...) in italiano (o inglese) corretto usano 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: altro codice chiaro, leggibile, conciso (ma non TROPPO compatto) nomi significativi e coerenti Data Dictionary e codice ben allineati IU (se c é) chiara e secondo lo stile di IU comune a tutto il progetto MOLTO importante: info di errore, log non 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 & Processi le 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 email certo non uno strumento nuovo...;-) ma ha molti evidenti vantaggi disponibilitá universale user agent molto personalizzabili facile automatizzare programmi/script x: spedire email automatiche se eventi ricevere 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 file il testo delle diff é spesso ideale per il revisore x positionare commenti/domande meglio 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/head se 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 soddisfacente la 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 simili l autore DEVE risolvere ciascun caso con piena soddisfazione del revisore: é il revisore che decide!...da cui il probl. del "reviewer shopping";-) 26
dimensione dei changeset mirare 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 CR mai passare + di 60-90 minuti consecutivi in CR: l'efficacia "crolla" circa a quel punto ci si "abitua" in modo veramente intenso per 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
D & R http://www.aleax.it/itbs11_crev.pdf?! aleax@google.com 30