Passaggio di consegna: una metrica fondamentale!
Per valutare un buon codice sono state proposte un gran numero di metriche. Io ne ho trovata una che reputo saggia:
Se formare una nuova persona nel tuo progetto
richiede poco tempo,
il tuo codice è ottimo!
In teoria sarebbe sufficiente una suite di test di non regressione e una certa leggibilità.
Talvolta i passaggi di consegna sono considerate attività che richiedono mesi. A me pare assurdo, soprattutto considerando la complessità media dei progetti su cui ho lavorato. Quando lavori su un ecommerce, il passaggio di consegna o la formazione di un nuovo membro di un team dovrebbe essere rapida, dell'ordine di qualche giorno. Infatti a parte specificità anomale del progetto il campo ecommerce ha un dominio estremamente semplice. Tutt'altra cosa sarebbe formare una persona su un simulatore di volo o su codice geometrico 3d.
Perchè nella realtà, nella stra grande maggioranza dei progetti il tempo di inserimento di una nuova persona è lungo ?
Ho identificato 3 motivi principali:
- Ci sono troppe convenzioni orali. Per fare un task il team sa che deve rispettare delle regole, che però né sono scritte né sono automatizzate. Scoprirle tutte richiede tanto tempo e il rischio di infrangerle è grande.
- Non c'è una fonte di informazione chiara, o non si risce ad accedervi facilmente. Ad esempio potrebbe non aver senso documentare l'architettura di un sistema, se per sua natura cambia ogni pochi mesi. Ma senz'altro ha senso poter ridisegnarla in poco tempo. La documentazione non è importante di per sé, ma è importante definire un modo con cui un nuovo entrato può reperire le informazioni necessarie.
- Il codice è complesso. Ma il problema che risolve non lo è. Se fosse semplice la formazione sarebbe assai semplificata.
La Leggibilità: il sacro graal
Fate fare un kata di programmazione a vari sviluppatori, ognuno valuterà l'esercizio altrui meno leggibile del proprio.
Troppi refactoring inutili si sono fatti per il tema della leggibilità!
Anche questa tematica secondo me distingue uno junior da un senior:
Il codice dev'essere leggibile come il sale: quanto basta.
E' invece importante costruire un dizionario comune all'interno del team. Quindi un termine o una tecnica che può apparire ostica ad un nuovo arrivato ha completamente senso all'interno del team consolidato. Poichè il team si allinea volente o nolente su uno stesso linguaggio è importante che esso stesso cresca (con confronti, esercizi etc) al fine di aumentare la sensibilità media.
La mia opinione sui framework
Non amo i framework, perchè se li si usa cambia la natura del proprio lavoro che diventa da una attività creativa ad una attività organizzativa/burocratica.
Tuttavia sono andato più a fondo della pura motivazione del divertimento. La verità è che quando qualcuno decide di usare un framework per un progetto è perchè ha una scarsa concezione dei programmatori a sua disposizione.
Scegli un framework se:
- il tuo team discute tanto di design e poi non combina nulla
- il tuo team mette troppi bachi in produzione
- ogni virgola richiesta al team richiede un tempo esagerato per essere implementata
- ci sono numerose regressioni
Il più delle volte i problemi risolti da un framework sono molto piu grandi e complessi di quanto serve davvero implementare, e il costo di imparare il framework nella mia opinione è maggiore del tempo di riscriversi un sistema custom piccolo e adatto alle proprie esigenze.
Ho riscritto o visto riscrivere con poche righe di codice:
- un rule engine in ruby
- un router in java
- una macchina a stati di media complessità
- un sistema di alerting di eventi asincrono estremamente scalabile
Il mio consiglio non vuole essere di usare o meno framework: non avrebbe senso. Reputo invece importante che sia il team a scegliere.
Rimane un ultimo punto da chiarire:
Come scegliere tra vari framework che risolvono lo stesso problema?
Io reputo un framework valido se ha previsto un modo per essere testato o per testare. Ad esempio non sceglierei mai un framework per costruire applicazioni web che come *unico* strumento di test richiede Selenium.
Nessun commento:
Posta un commento