Il Test Joel: codice migliore in 12 passi

From The Joel on Software Translation Project

Revision as of 09:42, 5 March 2009 by Keper (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Il Test Joel: codice migliore in 12 passi

Di Joel Spolsky
Tradotto da Stefano J. Attardi
Redatto da Andrea Monelli
9 agosto 2000

Traduzione dell'articolo originale inglese dal titolo The Joel Test: 12 Steps to Better Code
Importato nel wiki da Marco Menardi



Hai mai sentito parlare di SEMA? È un metodo particolarmente esoterico per misurare la qualità di una squadra di sviluppatori di software. No, aspetta! Non seguire quel link! Ti ci vorrebbero circa sei anni solo per capire quella roba. Per questo mi sono inventato un test personalissimo e decisamente irresponsabile per valutare la qualità di una squadra software. La buona notizia è che ci vogliono circa 3 minuti. Con tutto il tempo che risparmi puoi laurearti in medicina.

Il Test Joel

  1. Usate un sistema per il controllo versione del codice?
  2. Potete compilare una build in un solo passo?
  3. Fate compilazioni giornaliere?
  4. Avete un database dei bug?
  5. Sistemate i bug prima di scrivere nuovo codice?
  6. Avete una tabella di marcia aggiornata?
  7. Avete delle specifiche?
  8. I programmatori lavorano in un posto tranquillo?
  9. Usate i migliori strumenti sul mercato?
 10. Avete dei tester?
 11. I candidati scrivono codice durante il colloquio?
 12. Fate test dell'usabilità "da corridoio"? 


La cosa carina del Test Joel è che è facile rispondere a ogni domanda con un veloce o no. Non c'è bisogno di calcolare righe-di-codice-al-giorno o media-di-bug-per-decisione-strategica. Dai alla tua squadra 1 punto per ogni "sì". Il piccolo problema del Test Joel è che non dovresti mai usarlo per assicurarti che il tuo software di controllo per centrali nucleari è sicuro.

Un punteggio di 12 è perfetto, 11 è accettabile, ma da 10 in giù avete problemi seri. La triste verità è che la maggior parte delle ditte di software tirano avanti con un punteggio di 2 o 3: in tal caso hanno disperato bisogno di aiuto, perché ditte come la Microsoft viaggiano a 12 a tempo pieno.

Ovviamente, questi non sono gli unici fattori che determinano successo o fallimento: in particolare, se avete una squadra fantastica che lavora su un prodotto che nessuno vuole, beh, la gente non lo vorrà. Ed è anche possibile immaginare un gruppo di "pistoleri" che non fanno nessuna di queste cose ma che riesce lo stesso a produrre software spettacolare in grado di cambiare il mondo. Ma, a parità di tutto il resto, se fai queste 12 cose nel modo giusto avrai una squadra disciplinata che farà regolarmente il suo dovere.

1. Usate un sistema per il controllo di versione del codice?

Ho usato pacchetti commerciali per la gestione del codice sorgente, e ho usato CVS, che è gratis e, lasciamelo dire, CVS va bene. Ma senza sistema di gestione dei sorgenti, diventerai matto cercando di far collaborare i programmatori. Senza, i programmatori non hanno nessun modo di sapere cosa hanno fatto gli altri e gli errori non possono essere annullati facilmente. L'altra cosa carina dei sistemi di gestione dei sorgenti è che il codice stesso è copiato sul disco di ogni programmatore – non ho mai sentito parlare di un progetto che usava un sistema di controllo di versione che abbia perso molto codice.

2. Potete compilare una build in un solo passo?

Voglio dire: quanti passi ci vogliono per fare una build pronta per la distribuzione a partire dall'ultima versione del codice? Le buone squadre hanno un solo script che si occupa di fare un checkout completo da zero, ricompila ogni riga di codice, produce gli EXE, in tutte le varie versioni, lingue e combinazioni di #ifdef, crea il pacchetto di installazione e prepara il supporto finale – CDROM, sito per il download, o altro.

Se il processo richiede più di un passo, è facile sbagliare. Quando ti avvicini alla data di pubblicazione, hai bisogno di poter eliminare rapidamente quell'"ultimo" bug e rifare gli EXE definitivi, ecc, in continuazione. Se ci vogliono 20 passi per compilare il codice, produrre l'installatore, ecc., diventerete matti e farete errori stupidi.

Proprio per questa ragione l'ultima ditta per cui ho lavorato è passata da WISE a InstallShield: era fondamentale che il processo di installazione potesse eseguire da script, automaticamente, ogni notte, usando lo scheduler di NT. WISE non poteva farlo, allora l'abbiamo cestinato (i gentili signori della WISE assicurano che la loro ultima versione consente compilazioni notturne).

3. Fate build giornaliere?

Quando usi un sistema per la gestione dei sorgenti, a volte un programmatore inserisce accidentalmente qualcosa che causa un'errore nella compilazione. Magari tutto compila bene sulla sua macchina, ma ha creato un nuovo file e si è dimenticato di aggiungerlo nel sistema di controllo di versione. Poi spegne il suo computer e se ne va a casa, ignaro e felice. Ma nessun altro può lavorare, allora anche gli altri vanno a casa, infelici.

Rovinare la compilazione è una cosa tanto dannosa (e tanto comune) che è utile fare compilazioni giornaliere, per assicurarsi che nessun errore di questo tipo passi inosservato. Per squadre grandi, un buon modo di assicurarsi che questi problemi siano risolti subito è fare quanti più checkin prima di pranzo. Quando tutti ritornano, la build è fatta. Se ha funzionato, bene! Ognuno si prende l'ultima versione del sorgente e va avanti col suo lavoro. Se la compilazione ha fallito, tu la sistemi, ma tutti gli altri possono continuare a lavorare con la versione dei sorgenti funzionante, quella precedente alla compilazione.

Nella squadra di Excel avevamo una regola che chiunque rovinasse la compilazione, per punizione era responsabile di fare da babysitter alle compilazioni fin quando non le rovinasse qualcun altro. Questo era un buon incentivo a non rovinare le build, e un buon modo di far imparare a tutti come funzionava il processo di compilazione.

Per sapere di più sulle build giornaliere leggi il mio articolo Le build giornaliere sono tue amiche.

4. Avete un database dei bug?

Non voglio sentire storie. Se scrivi codice, anche in una squadra di un solo elemento, senza un database organizzato con tutti i bug conosciuti produrrai codice di cattiva qualità. Molti programmatori credono di poter tenere la lista dei bug a mente. Col cavolo. Io non riesco a tenere a mente più di due o tre bug alla volta, e la mattina dopo, oppure nella fretta di pubblicare, mi sfuggono. Devi assolutamente tenere formalmente traccia dei bug.

I database per i bug possono essere complicati o semplici. Per essere utile un database dei bug deve come minimo contenere per ogni bug i seguenti dati:

   * lista di tutti i passi per riprodurre il bug
   * comportamento atteso
   * comportamento (scorretto) osservato
   * a chi è assegnato
   * se è stato sistemato o no 

Se la complessità del software per tenere traccia dei bug è l'unica cosa che ti trattiene dall'usarlo, allora fai una semplice tabella con una colonna per ognuna di queste 5 informazioni fondamentali e inizia a usarla.

Per maggiori informazioni sulla gestione dei bug, leggi Gestione indolore dei bug.

5. Sistemate i bug prima di scrivere nuovo codice?

La primissima versione di Microsoft Word per Windows era considerata un progetto stile "marcia funebre". Non finiva mai. Era sempre più in ritardo. Tutta la squadra lavorava in orari assurdi, il progetto veniva ritardato ancora, e ancora, e ancora, e lo stress era incredibile. Quando la dannata cosa fu finalmente rilasciata, con anni di ritardo, la Microsoft mandò l'intera squadra in vacanza a Cancun, poi sedette attorno a un tavolo alla ricerca della propria anima.

Ciò di cui si resero conto fu che i manager del progetto erano stati così insistenti che si rispettasse la tabella di marcia che i programmatori semplicemente tiravano via, scrivendo codice molto scarso, perché la fase di correzione dei bug non faceva parte della tabella di marcia ufficiale. Non ci fu nessun tentativo di tenere basso il numero dei bug. Anzi. Si narra che un programmatore che doveva scrivere il codice per calcolare l'altezza di una linea di testo, scrisse semplicemente "return 12;" e aspettò che venisse riportato il bug sul fatto che quella funzione non sempre era corretta. La tabella di marcia era quindi praticamente una lista di feature che aspettavano soltanto di essere trasformate in bug. Nel post mortem, questa fu chiamata "metodologia dei difetti infiniti".

Per correggere il problema, la Microsoft adottò universalmente una cosa chiamata "metodologia dei difetti zero". Molti dei programmatori della ditta sghignazzarono, visto che sembrava che la direzione pensava di poter ridurre il numero dei bug con regole arbitrarie. In realtà, "difetti zero" voleva dire che, in ogni momento, la priorità era eliminare i bug prima di scrivere nuovo codice. Vediamo perché.

In generale, più aspetti per risolvere un bug, più costoso (in termini di tempo e denaro) è da correggere.

Per esempio, quando fai un errore di battitura o di sintassi che il compilatore ti segnala, correggerlo è banale.

Quando nel tuo codice c'è un bug che vedi la prima volta che lo esegui, sei in grado di sistemarlo istantaneamente, perché hai ancora il codice fresco in testa.

Se trovi un bug in un pezzo di codice che hai scritto qualche giorno fa, ti ci vorrà un po' per individuarlo, ma quando rileggerai il codice che hai scritto ti tornerà tutto in mente e sarai in grado di sistemare il bug in tempo ragionevole.

Ma se trovi un bug nel codice che hai scritto alcuni mesi fa, ti sarai probabilmente scordato molte cose su quel codice e sarà molto più difficile sistemarlo. Se è passato così tanto tempo potresti anche trovarti a correggere il codice di qualcun altro che magari è in vacanza ad Aruba. In questo caso, risolvere il bug è una scienza: devi essere lento, metodico e meticoloso, e nessuno sa quanto ci vorrà per trovare una cura.

E se trovi un bug nel codice che è già stato rilasciato, dovrai affrontare incredibili spese per sistemarlo.

Questo è uno dei motivi per cui bisogna correggere subito i bug: ci vuole meno tempo. C'è un altro motivo, e ha a che fare col fatto che è più facile prevedere quanto ci vorrà per scrivere nuovo codice piuttosto che per correggere un bug. Per esempio, se ti chiedessi di prevedere quanto tempo ci vuole per scrivere il codice per fare l'ordinamento di una lista, mi potresti dare una stima abbastanza buona. Ma se ti chiedessi come prevedere quanto ci vuole per sistemare quel bug per cui il tuo codice non funziona se è installato Internet Explorer 5.5, non potresti nemmeno tirare a indovinare, perché non sai (per definizione) qual è la causa del bug. Magari ci vorrebbero 3 giorni per scoprirlo, o forse 2 minuti.

Questo vuol dire che se hai una tabella di marcia con molti bug ancora da sistemare, la tabella di marcia non è affidabile. Ma se hai sistemato tutti i bug conosciuti e tutto quello che resta da fare è nuovo codice, allora la tua tabella di marcia sarà splendidamente più accurata.

Un altro grande vantaggio di tenere la conta dei bug a zero è che puoi rispondere molto più rapidamente alla concorrenza. In altre parole, fai in modo che il prodotto sia pronto per essere rilasciato in ogni momento. Così, se il tuo concorrente introduce una nuova grande feature che ti porta via i clienti, potete implementare giusto quella feature e pubblicare sul momento, senza dover sistemare un gran numero di bug accumulati.

6. Avete una tabella di marcia aggiornata?

E così arriviamo alle tabelle di marcia. Se il tuo codice è un minimo rilevante per il business, ci sono un sacco di ragioni per le quali è importante per il business sapere quando il codice sarà pronto. I programmatori sono proverbialmente suscettibili rispetto alle tabelle di marcia. "Sarà pronto quando è pronto!" urlano a quelli che si occupano delle vendite.

Sfortunatamente, questa non è gran che come risposta. Ci sono troppe cose che l'ufficio business deve pianificare molto prima di rilasciare il codice: dimostrazioni, fiere, pubblicità, ecc. E possono farlo soltanto se hanno una tabella di marcia sempre aggiornata.

L'altra caratteristica cruciale delle tabelle di marcia è che ti obbligano è decidere quali feature realizzerai e a lasciar perdere le feature meno importanti piuttosto che scadere nella featurite.

Mantenere una tabella di marcia non deve per forza essere difficile. Leggi il mio articolo Tabelle di marcia indolori, che spiega un modo semplice per creare ottime tabelle di marcia.

7. Avete delle specifiche?

Le specifiche sono come il filo interdentale: tutti sono d'accordo che sono importanti, ma nessuno le usa.

Non so bene qual è il motivo, ma probabilmente è perché la maggior parte dei programmatori odia scrivere documenti. Di conseguenza, quando squadre di soli programmatori affrontano un problema preferiscono esprimere la loro soluzione tramite codice, piuttosto che scrivendo documenti. Per loro è meglio tuffarsi subito a programmare piuttosto che produrre prima una specifica.

Nella fase di progettazione, se scopri un problema puoi sistemarlo facilmente cambiando poche righe di testo. Una volta che il codice è stato scritto, il costo di risolvere i problemi è molto superiore, sia in termini emotivi (la gente odia buttare via del codice) che in termini di tempo, quindi alla soluzione dei problemi si oppone resistenza. I programmi che non sono costruiti a partire da una specifica spesso risultano mal progettati e la tabella di marcia va fuori controllo. Sembra sia stato questo il problema di Netscape quando le prime quattro versioni crebbero fino a diventare un tale groviglio che la direzione stupidamente decidette di buttare via tutto e ricominciare. E poi hanno rifatto lo stesso errore con Mozilla, creando un mostro che è andato fuori da ogni controllo e che ci ha messo svariati anni per arrivare allo stadio alpha.

La mia personale teoria è che questo problema può essere risolto insegnando ai programmatori a essere scrittori meno reticenti mandandoli a fare un corso intensivo di scrittura. Un'altra soluzione è assumere manager svegli che producono la specifica scritta. Comunque sia, dovresti far rispettare la semplice regola "niente codice senza specifica".

Impara tutto su come si scrivono le specifiche leggendo la mia serie di 4 articoli.

8. I programmatori lavorano in un posto tranquillo?

Gli aumenti di produttività ottenuti dando ai lavoratori intellettuali spazio, silenzio e riservatezza sono estensivamente documentati. Peopleware, il classico libro sul software management, offre un'ampia documentazione sui guadagni in produttività.

Ecco il problema. Sappiamo tutti che i lavoratori intellettuali lavorano meglio se vanno a "regime", se entrano "nella zona", cioè sono pienamente concentrati sul loro lavoro e totalmente estraniati dall'ambiente che li circonda. Perdono la cognizione del tempo e producono grandi cose grazie a una concentrazione assoluta. È in questi momenti che producono davvero. Scrittori, programmatori, scienziati e anche giocatori di basket sanno bene cosa vuol dire essere nella zona.

Il problema è che entrare "nella zona" non è facile. Se cerchi di misurarlo, sembra che ci vogliano in media 15 minuti per iniziare a lavorare al massimo della produttività. A volte, se sei stanco o hai già fatto molto lavoro creativo quel giorno, proprio non riesci a entrare nella zona e passi il resto della giornata lavorativa a cazzeggiare, leggendo il web, giocando a Tetris.

L'altro problema è che è molto facile essere scagliati fuori dalla zona. Rumore, telefonate, la pausa pranzo, dover guidare 5 minuti per andare a prendere un caffè da Starbucks, interruzioni da parte di colleghi – soprattutto interruzioni da parte dei colleghi – sono tutte cose che ti scagliano fuori dalla zona. Se un collega ti chiede qualcosa interrompendoti per 1 minuto, ma così facendo ti butta fuori dalla zona così tanto che ti ci vuole mezz'ora per ritornare produttivo, la tua produttività complessiva ha seri problemi. Se lavori in un ambiente rumoroso tipo cortile come quello che piace tanto alle dotcom caffeinate, con esperti di marketing che urlano al telefono accanto ai programmatori, la produttività crollerà perché i lavoratori intellettuali vengono interrotti in continuazione e non entrano mai nella zona.

Per i programmatori, questo aspetto è particolarmente delicato. La produttività si basa sul poter palleggiare tutti insieme nella memoria a breve termine un sacco di piccoli dettagli. Basta una qualsiasi interruzione e questi dettagli crollano rovinosamente. Quando riprendi a lavorare non te ne ricordi più neanche uno (come ad esempio i nomi delle variabili locali che stavi usando, o a che punto eri dell'implementazione di quell'algoritmo di ricerca) e devi andarti a riscoprire tutte queste cose, il che ti rallenta moltissimo prima che tu riesca a tornare a regime.

Un po' di conti. Mettiamo il caso che (come sembrano suggerire gli esperimenti) se interrompiamo un programmatore, anche solo per un minuto, stiamo in realtà bruciando 15 minuti di produttività. Mettiamo due programmatori, Jeff e Mutt, nei tipici cubicoli aperti uno accanto all'altro, stile fattoria per l'ingrasso dei vitelli. Mutt non si ricorda il nome della versione Unicode della funzione strcpy. Potrebbe andarsela a cercare (30 secondi) oppure chiedere a Jeff (15 secondi). Visto che sta seduto proprio accanto a Jeff, chiede a Jeff. Jeff viene distratto e perde 15 minuti di produttività (per risparmiare a Mutt 15 secondi).

Adesso spostiamoli in uffici separati con pareti e porte. Adesso, quando Mutt non si ricorda il nome di quella funzione potrebbe andarsela a cercare (sempre 30 secondi) o potrebbe chiedere a Jeff, il che richede adesso 45 secondi e significa doversi alzare in piedi (non un compito facile considerando la forma fisica tipica dei programmatori!). Allora se la va a cercare. Così adesso Mutt perde 30 secondi di produttività, ma risparmiamo 15 minuti a Jeff. Ahhh!

9. Usate i migliori strumenti sul mercato?

Scrivere codice in un linguaggio compilato è una delle ultime cose che ancora non si possono fare istantaneamente su un normale computer da casa. Se la compilazione ci mette più di una manciata di secondi, comprando l'ultimissimo e potentissimo computer risparmierai tempo. Se la compilazione ci mette anche solo 15 secondi, i programmatori si annoieranno mentre il computer lavora e si metteranno a leggere The Onion, che li catturerà e distruggerà ore di produttività.

Debuggare il codice di un'interfaccia grafica su un sistema con un solo monitor non impossibile, ma è doloroso. Se scrivi interfacce grafiche, un secondo monitor faciliterà di molto le cose.

La maggior parte del programmatori prima o poi deve manipolare delle bitmap per icone o toolbar, e molti non hanno un buon editor di bitmap a disposizione. Usare Microsoft Paint per manipolare le bitmap è una barzelletta, ma è quello che molti programmatori sono costretti a fare.

Al mio ultimo posto di lavoro, l'amministratore di sistema continuava a mandarmi spam automatizzato lamentandosi che stavo occupando più di... stai a sentire... 220 megabyte di spazio disco sul server. Io gli ho fatto notare che, dati i prezzi dei dischi rigidi oggigiorno, il costo di quello spazio era molto minore del costo della carta igienica che usavo. Passare anche 10 minuti a ripulire la mia cartella sarebbe stato un favoloso spreco di produttività.

Le migliori squadre di sviluppo non torturano i loro programmatori. Frustrazioni anche piccole causate da strumenti poco potenti si sommano, rendendo i programmatori irritabili e scontenti. E un programmatore scontento è un programmatore non produttivo.

Come se non bastasse... i programmatori si lasciano facilmente abbindolare dalle cose più ganze e più recenti. Questo è un sistema molto più economico per fare in modo che lavorino per te che pagare salari competitivi!

10. Avete dei tester?

Se la tua squadra non ha almeno un tester dedicato ogni due o tre programmatori, o rilasci prodotti difettosi, oppure stai sprecando soldi facendo fare a programmatori da €100 l'ora del lavoro che può essere fatto da tester da €30 l'ora. Risparmiare sui tester è una falsa economia talmente assurda che sono puramente sconvolto dal fatto che solo pochi lo riconoscono.

Leggi I cinque motivi (sbagliati) per cui non avete tester, un mio articolo su questo argomento.

11. I candidati scrivono codice durante il colloquio?

Assumeresti un prestigiatore senza chiedergli di mostrarti qualche trucco? Ovviamente no.

Assumeresti un cuoco per il tuo matrimonio senza assaggiare il suo cibo? Ne dubito. (A meno che non sia la zia Marge, che ti odierebbe per sempre se non le lascassi fare la sua "famosa" torta ai fegatini.)

Eppure, ogni giorno vengono assunti dei programmatori semplicemente sulla base di un curriculum ragguardevole o perché l'intervistatore ha avuto con loro una piacevole chiacchierata. Oppure vengono fatte loro domande quiz ("qual è la differenza tra CreateDialog() e DialogBox()?") a cui si può rispondere guardando la documentazione. Che ti importa se hanno memorizzato un sacco di domande quiz sulla programmazione, ti interessa se sono in grado di produrre codice. O, ancora peggio, si chiedono loro domande "AHA!": quelle che sembrano facili una volta che sai la risposta, ma se non la sai sono impossibili.

Vi prego, smettete di farlo e basta. Fate quello che vi pare durante i colloqui, ma fate in modo che il candidato scriva del codice. (Per maggiori consigli, leggi la mia Guida di guerriglia ai colloqui).

12. Fate test dell'usabilità "da corridoio"?

Un test dell'usabilità da corridoio consiste nell'afferrare la prima persona che passa per il corridoio e obbligarla a cercare di usare il codice che avete appena scritto. Se fai questo a cinque persone, saprai il 95% di quello che c'è da sapere sui problemi di usabilità del tuo codice.

Progettare una buona interfaccia utente non è così difficile come sembra, ma è cruciale se vuoi che i tuoi clienti apprezzino e comprino il tuo prodotto. Puoi leggere il mio libro gratuito sul design delle interfacce utente, un piccolo abbecedario per programmatori.

Ma la cosa più importante delle interfacce utente è che se fai vedere il tuo programma a una manciata di persone (cinque o sei bastano), scoprirai subito i più grossi problemi che hanno gli utenti. Leggi l'articolo di Jakob Nielsen che spiega perché. Anche se sei carente per quanto riguarda la realizzazione di interfacce utente, ammesso che tu ti costringa a fare test dell'usabilità da corridoio, che non costano nulla, le tue interfacce saranno molto, molto migliori.

Quattro modi di usare il Test Joel

  1. Dai un punteggio alla tua squadra di software e dimmi com'è andata, così posso spettegolare.
  2. Se sei il manager di una squadra di programmatori, usa questa lista per assicurarti che la tua 
     squadra stia lavorando nel miglior modo possibile. Quando inizi ad avere un punteggio di 12, puoi 
     lasciare in pace i tuoi programmatori e concentrarti a tempo pieno sul fare in modo che i responsabili
     del business non li disturbino.
  3. Se stai cercando di decidere se accettare un lavoro da programmatore, chiedi al tuo potenziale datore 
     di lavoro come se la cavano con questo test. Se il punteggio è troppo basso, assicurati che avresti il 
     potere di sistemare le cose. Altrimenti sarai frustrato e poco produttivo.
  4. Se sei un investitore che sta facendo il dovuto lavoro di giudicare il valore di una squadra di programmatori,
     o se la tua ditta di software sta pensando di unirsi a un'altra, questo test può fornire una veloce regola indicativa. 






--62.10.39.159 11:54, 27 Jan 2006 (EST)

Personal tools