Scrivere un codice migliore per progetti basati su WordPress
Non ricordo esattamente quando mi sono imbattuto per la prima volta nel blog di Joel Spolsky Joel on Software, ma a un certo punto era in ritardo al liceo.
Non sapevo abbastanza dell’intero processo di sviluppo del software per capire molto di ciò di cui stava parlando, ma mi è piaciuto il suo stile di scrittura e mi è piaciuto quello che aveva da dire.
In effetti, ero un tale fan che quando mi sono laureato, ho continuato a comprare i suoi libri (che erano raccolte di articoli sul suo sito) e li ho letti da copertina a copertina. Ne tenevo copie sulla scrivania al lavoro e usavo uno dei suoi libri – Smart and Gets Things Done – quando ero a capo del team.
Gli articoli che mi hanno colpito di più, tuttavia, sono stati quelli sulla scrittura di un codice migliore. Ecco la cosa, però: quegli articoli non includevano nulla sulla scrittura del codice.
Scrivere un codice migliore
Invece, si trattava solo di processi attorno a un codice migliore. E mi sono imbattuto in un articolo – 16 anni, comunque – e lo trovo ancora rilevante oggi come quando l’ho trovato per la prima volta.
Tranne che ora, mi sto chiedendo come si applica al mio attuale lavoro di sviluppo.
Il test di Gioele
Innanzitutto, l’articolo in questione è quello che mi ritrovo a leggere almeno una volta al mese – se non almeno una volta alla settimana – e ruota tutto intorno a quello che lui chiama The Joel Test. Sono dodici domande che applichi al tuo attuale team di sviluppo.
- Usi il controllo del codice sorgente?
- Puoi creare una build in un solo passaggio?
- Realizzi build giornaliere?
- Hai un database di bug?
- Risolvi i bug prima di scrivere nuovo codice?
- Hai un programma aggiornato?
- Hai una specifica?
- I programmatori hanno condizioni di lavoro silenziose?
- Usi i migliori strumenti che i soldi possono comprare?
- Hai dei tester?
- I nuovi candidati scrivono codice durante il colloquio?
- Esegui test di usabilità in corridoio?
Dato che queste domande sono state scritte 16 anni fa e sono in gran parte basate su codice compilato, potrebbe essere necessario modificare parte della terminologia.
La cosa bella di The Joel Test è che è facile ottenere un rapido sì o un no a ogni domanda. Non è necessario calcolare righe di codice al giorno o bug medi per punto di flessione. Assegna alla tua squadra 1 punto per ogni risposta "sì".
Ad esempio, invece di chiedere se è possibile creare una build in un passaggio, forse dovremmo chiedere se possiamo realizzare un’implementazione in un passaggio. Sai cosa intendo: apportare modifiche a cose del genere.
In secondo luogo, alcune delle domande devono essere adattate ai team remoti perché non siamo più tutti nello stesso ufficio. Cioè, invece di eseguire test di usabilità in corridoio, potresti dover prendere qualcuno che conosci online, inviarlo al tuo ambiente di test e chiedere loro del progetto.
Il Joel Test per WordPress
Forse, per quelli di noi che usano WordPress come base di sviluppo, la nostra serie di domande sarebbe simile a questa:
- Usi il controllo del codice sorgente?
- Puoi effettuare una distribuzione in un passaggio?
- Effettuate distribuzioni giornaliere?
- Hai un database di bug?
- Risolvi i bug prima di scrivere nuovo codice?
- Hai un programma aggiornato?
- Hai requisiti e modelli?
- I programmatori hanno condizioni di lavoro silenziose? Oppure, se remoti, i programmatori possono entrare in modalità "Non disturbare"?
- Utilizzi i migliori strumenti sul mercato, o qualcosa di gratuito e open source o qualcosa di premium?
- Hai dei tester? (E potrei chiedere se il budget per il progetto consente anche il tempo di scrivere unit test per i test automatizzati)?
- I candidati hanno campioni di codice disponibili su GitHub, un blog o una posizione disponibile pubblicamente che possono essere esaminati?
- Hai un gruppo di persone da cui puoi attingere per testare il tuo lavoro in corso?
Ancora una volta, questo è in gran parte basato sull’idea di un piccolo team remoto piuttosto che di una grande azienda o agenzia di prodotti a livello aziendale. Ma è qualcosa a cui torno ancora ogni tanto e mi chiedo come gli altri negozi si compongano l’uno contro l’altro.
Oh, e l’intera faccenda del punteggio?
Un punteggio di 12 è perfetto, 11 è tollerabile, ma 10 o meno e hai seri problemi. La verità è che la maggior parte delle organizzazioni di software funziona con un punteggio di 2 o 3 e hanno bisogno di un aiuto serio…
Abbiamo tutti qualcosa a cui mirare, giusto?
Per il prossimo decennio?
Non è tanto che penso sia una competizione, ma so che mi piacerebbe poter rispondere sì alla maggior parte di queste domande per me e per coloro con cui lavoro.
Ma al momento di questo articolo, posso dire che non posso dire di sì a tutti questi, per non parlare forse di metà di loro. Forse entro la fine dell’anno posso, però.
E forse il resto di noi che lavora nel settore può valutare i nostri team rispetto a queste domande. Sebbene Internet e le relative tecnologie si muovano rapidamente, queste domande hanno resistito bene per oltre un decennio.