Il mondo dello sviluppo software nasconde molti rischi e insidie; uno di questi è il cosiddetto "Bus Factor", un concetto che molti team e imprese tendono a sottovalutare.
Adam Tornhill, fondatore e CTO di CodeScene, spiega che il Bus Factor indica "il numero di sviluppatori che possono andarsene prima che la codebase diventi difficile da manutenere". Si tratta di fatto di una misura del rischio di rimanere senza persone che abbiano conoscenza di un progetto o che siano sufficientemente competenti per occuparsene.
Questo fattore può essere calcolato analizzando i contributi relativi di uno sviluppatore nel corso del tempo: in poche parole, più uno sviluppatore ha scritto linee di codice, più influirà sul Bus Factor.
L'obiettivo è avere un Bus Factor elevato, ma Tornhill riporta che in molti casi, soprattutto nei progetti open-source, questo valore si aggira su 1 o 2; numeri allarmanti, considerando che una percentuale tra il 70% e il 90% di codice delle moderne applicazioni business è open-source. Un Bus Factor basso significa esporsi al rischio di vulnerabilità di sicurezza e di codice che diventa velocemente obsoleto.
Nel caso di codice proprietario, la situazione non è molto diversa: secondo diverse stime, i progetti interni non sono in media più resilienti di quelli open-source in caso della perdita di uno sviluppatore.
È interessante sottolineare anche che il Bus Factor non aumenta in maniera proporzionale al numero di persone nel team: avere più sviluppatori non significa essere al sicuro da un Bus Factor basso, perché la conoscenza core del codice è comunque suddivisa tra un numero limitato di persone.
Come mitigare il Bus Factor
Visti i rischi a cui le aziende sono esposte, è importante mitigare proattivamente il Bus Factor. Tornhill consiglia innanzitutto di verificare il Bus Factor di una libreria o un framework open-source che si sceglie di adottare, preferendo progetti con supporto stabile e duraturo.
È importante inoltre investire sulla scrittura di codice di qualità, formando gli sviluppatori sulle best practice del caso, e organizzare attività di refactoring che semplificano il codice e riducono quindi gli impatti negativi nel caso gli sviluppatori principali se ne vadano.
Infine, durante il refactoring è consigliabile far lavorare gli sviluppatori in coppia per distribuire la conoscenza del codice tra più parti: ciò consente non solo di svolgere una pulizia del codice più accurata, ma anche di favorire una cultura aziendale basata sulla collaborazione.
