Le 5 risposte
- Che cosa vuole dire veramente programmazione agile
- Come si governa al meglio un team di programmatori
- Come comportarsi con i requisiti di progetto
- Cose da evitare durante lo sviluppo
- Firmare o non firmare il codice scritto in azienda
Che cosa vuole dire veramente programmazione agile
Continui a usare quella parola. Non credo che significhi ciò che credi.
– Inigo Montoya, La storia fantastica
Agile è un aggettivo: è il modo in cui si fa qualcosa. Si può essere uno sviluppatore agile. Si può essere in un team che adotta pratiche agili, un team che risponde al cambiamento e ai contrattempi con agilità. Agile è il tuo stile, non sei tu.
Quasi vent’anni dopo la prima comparsa del Manifesto for Agile Software Development, vediamo molti sviluppatori che ne applicano con successo i valori.
Vediamo però anche un altro lato dell’agilità. Team e aziende che cercano soluzioni preconfezionate: Agile-in-a-Box. Vediamo anche molti consulenti e molte aziende più che felici di vendere loro ciò che vogliono. Vediamo aziende che adottano ulteriori livelli di management, ulteriori report formali, sviluppatori più specializzati e titoli fantasiosi che significano solo qualcuno con un blocco per appunti e un cronometro. (Per maggiori informazioni su quanto possa essere terribile questo approccio, procurati The Tyranny of Metrics).
Abbiamo la sensazione che molti abbiano perso di vista il vero significato dell’agilità e vorremmo vedere tutti tornare ai fondamentali. Ricordiamo i valori del manifesto:
Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti:
Gli individui e le interazioni più che i processi e gli strumenti.
Il software funzionante più che la documentazione esaustiva.
La collaborazione col cliente più che la negoziazione dei contratti.
Rispondere al cambiamento più che seguire un piano.
Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.
Chiunque ti venda qualcosa che aumenta l’importanza delle voci a destra rispetto a quelle a sinistra, chiaramente non considera importanti le stesse cose che noi e altri autori del manifesto consideravano tali.
E chiunque ti venda una soluzione preconfezionata non ha letto la dichiarazione introduttiva. I valori sono motivati e informati dall’atto continuo di scoprire modi migliori di produrre software. Questo non è un documento statico, sono suggerimenti per un processo generativo.
Non può esserci mai un processo agile
In effetti, se qualcuno dice fai questo e sarai agile, sbaglia. Per definizione.
L’agilità, sia nel mondo fisico che nello sviluppo del software, ha a che vedere con il rispondere al cambiamento, rispondere alle incognite dopo essersi avviati. Una gazzella che corre non procede in linea retta. Una ginnasta opera centinaia di correzioni ogni secondo rispondendo ai cambiamenti nell’ambiente circostante e a errori minimi nella posizione dei suoi piedi. Lo stesso accade per i team e i singoli sviluppatori. Non esiste un piano unico da seguire quando si sviluppa software. Lo dicono tre valori su quattro: riguardano proprio la raccolta e la risposta ai feedback.
I valori non dicono che cosa fare. Dicono a che cosa prestare attenzione quando decidi autonomamente che cosa fare. Nessuno può dirti che cosa fare, ma pensiamo di poter dire qualcosa sullo spirito con cui va fatto. Tutto si riduce a come si gestisce l’incertezza. Questa è la nostra ricetta per lavorare in modo agile:
- Stabilisci dove sei.
- Fai il minimo passo dotato di significato verso dove vuoi essere.
- Valuta dove sei finito e sistema tutto quello che hai rovinato.
Ripeti questi passi finché non sei arrivato. E usali ricorsivamente, a ogni livello di tutto quello che fai.
A volte anche le decisioni apparentemente più banali diventano importanti quando si raccolgono feedback.
Ora il mio codice deve prendere il titolare dell’account.
let user = accountOwner(accountID);
Hmmm… user è un nome inutile. Lo cambierò in owner.
let owner = accountOwner(accountID);
Ma ora sembra un po’ ridondante. Che cosa sto realmente tentando di fare qui? La storia dice che invio una email a questa persona, perciò devo trovare il suo indirizzo di posta elettronica. Forse non ho bisogno affatto di tutto il titolare dell’account.
let email = emailOfAccountOwner(accountID);
Applicando il ciclo di feedback a livello realmente basso (la denominazione di una variabile) abbiamo effettivamente migliorato il progetto del sistema complessivo.
Il ciclo di feedback si applica anche al livello più elevato di un progetto. Almeno in parte, i nostri lavori di maggior successo sono stati quelli in cui abbiamo iniziato a lavorare sulla base dei requisiti di un cliente, abbiamo compiuto un singolo passo e ci siamo resi conto che quello che stavamo per fare non era necessario, che la soluzione migliore nemmeno coinvolgeva il software.
Questo ciclo vale anche all’esterno dell’ambito di un singolo progetto. I team devono applicarlo alla revisione del loro processo e per valutare quanto bene abbia funzionato. Un team che non sperimenta continuamente con il proprio processo non è un team agile.
E questo guida la progettazione.
Come si governa al meglio un team di programmatori
Al Group L, Stoffel controlla sei programmatori di altissimo livello, un’impresa di gestione all’incirca paragonabile a fare il guardiano di gatti.
– The Washington Post Magazine, 9 giugno 1985
Già nel 1985 la battuta sul guardiano di gatti sapeva di vecchio. Ai tempi della prima edizione di questo libro, alla vigilia del cambio di secolo, era decisamente anticaglia. Eppure resiste, perché ha un certo alone di verità. I programmatori sono un po’ come i gatti: intelligenti, determinati, presuntuosi, indipendenti e spesso adorati dalla rete.
Le tecniche pragmatiche che aiutano il singolo a essere un programmatore migliore possono funzionare anche per i team? La risposta è un sonoro sì!.
Un team, secondo noi, è un’entità autonoma piccola e prevalentemente stabile. Cinquanta persone non sono un team, sono un’orda. Neanche i team i cui membri vengono continuamente spostati ad altri compiti e in cui nessuno conosce gli altri sono veri team: sono solo un gruppo di estranei che condividono temporaneamente una fermata d’autobus sotto la pioggia.
Un team pragmatico è piccolo, con dieci-dodici membri circa. Raramente i membri vanno e vengono. Tutti si conoscono bene, si fidano l’uno dell’altro e dipendono l’uno dall’altro.
Ecco come le tecniche pragmatiche si possano applicare ai team nel loro complesso. Queste note sono solo un punto d’inizio. Una volta che avremo un gruppo di sviluppatori pragmatici al lavoro in un ambiente abilitante, svilupperanno e perfezioneranno rapidamente le dinamiche di gruppo che per loro funzionano meglio.
Niente finestre rotte
La qualità è un problema di squadra. Lo sviluppatore più diligente in un team a cui non importa di nulla troverà difficile mantenere l’entusiasmo necessario per sistemare le difficoltà. Il problema è ulteriormente aggravato se il team scoraggia attivamente lo sviluppatore dal dedicare tempo a risolvere quegli elementi.
I team nel loro complesso non devono tollerare le finestre rotte; quelle piccole imperfezioni che nessuno sistema. Il team deve assumersi la responsabilità della qualità del prodotto.
Alcune metodologie di gruppo hanno un rappresentante della qualità, qualcuno a cui il gruppo delega la responsabilità per la qualità di ciò che deve essere prodotto. Questo è chiaramente ridicolo: la qualità può venire solo dai contribuiti individuali di tutti i membri del team. La qualità è intrinseca, non appiccicata dal di fuori.
Rane bollite
Ricordi la rana nella pentola piena d’acqua, che non nota il cambiamento graduale nel suo ambiente e finisce cotta? Lo stesso può succedere alle persone che non sono vigili. Può essere difficile tenere sott’occhio l’ambiente complessivo, nel calore dello sviluppo del progetto.
È ancora più facile per i gruppi nel loro insieme finire bolliti. Ciascuno dà per scontato che un problema sia gestito da qualcun altro, o che il leader del team abbia dato il benestare a un cambiamento che l’utente richiede. Anche le squadre meglio intenzionate possono non prestare attenzione a cambiamenti significativi nei loro progetti.
Questo va combattuto. Assicuriamoci che tutti controllino attivamente l’ambiente per identificare i cambiamenti. Rimaniamo vigili e attenti ad ampliamenti del raggio d’azione, riduzioni delle scale temporali, caratteristiche aggiuntive, nuovi ambienti. Adottiamo metriche per i nuovi requisiti. Il team non deve rifiutare i cambiamenti, ma essere consapevole del loro verificarsi. Altrimenti, saremo noi nell’acqua bollente.
Pianificare il proprio portafoglio di conoscenze
Se il team è seriamente interessato al miglioramento e all’innovazione, deve pianificarli. Cercare di fare le cose quando c’è un momento libero significa che non succederà mai. Ecco alcuni esempi di attività che devono trovare spazio in qualsiasi pianificazione.
- Manutenzione di vecchi sistemi. Amiamo molto lavorare su sistemi nuovi e brillanti, ma è probabile che ci sia lavoro di manutenzione da svolgere sul vecchio sistema.
- Riflessione e affinamento dei processi. Troppi team sono così impegnati a tenere la testa fuori dall’acqua da non avere il tempo per turare le falle. Pianifichiamo e tappiamole.
- Esperimenti in nuove tecnologie. Adottiamo nuove tecnologie non perché lo stanno facendo tutti o sulla base di qualcosa visto a un convegno o letto online; invece lasciamo spazio nei nostri programmi alla prova di nuove cose e all’analisi dei risultati.
- Studio e miglioramento delle competenze. Lo studio personale è un ottimo punto di partenza, ma molte competenze sono più efficaci quando sono diffuse a livello di tutto il team. Pianifichiamo anche questo, sotto forma di incontri informali a pranzo o di sessioni di addestramento più formali.
Comunicare la presenza del team
È facile dimenticare che il team ha una presenza dentro l’organizzazione: come entità, deve comunicare chiaramente con il resto del mondo.
I grandi team di progetto hanno una personalità ben definita. La gente non vede l’ora di riunirsi con loro, perché sa che assisterà a una performance ben preparata che fa sentir bene tutti. La documentazione che producono è elegante, accurata e coerente. Il gruppo parla con una sola voce, può addirittura avere un senso dello humor. (Verso l’esterno: internamente, consigliamo fortemente un dibattito vivace e robusto).
Esiste un semplice trucco di marketing che aiuta i team a comunicare come una cosa sola: generare un brand. All’inizio di un progetto, troviamogli un nome, idealmente qualcosa di un po’ matto, e un logo bizzarro da usare nei memo e nelle relazioni. Suona stupido, ma dà al team un’identità da sfruttare, e al mondo qualcosa di memorabile da associare al nostro lavoro.
Automazione
Un ottimo modo per garantire coerenza e precisione è automatizzare tutto ciò che il team fa. Perché formattare manualmente il codice quando l’editor può farlo per noi automaticamente mentre scriviamo? Perché completare moduli di test quando la build notturna può eseguire i test in automatico? L’automazione è una componente essenziale di ogni team di sviluppo.
Come comportarsi con i requisiti di progetto
La perfezione si ottiene non quando non resta più nulla da aggiungere, ma quando non resta più niente da eliminare.
– Antoine de St. Exupery, Vento, sabbia e stelle, 1939
Molti libri e molti tutorial indicano nella raccolta dei requisiti (requirements gathering) una delle prime fasi del progetto. Il termine raccolta suscita l’immagine di una tribù di analisti felici, che bottinano frammenti di saggezza sparsi sul terreno tutto attorno, mentre in sottofondo l’orchestra esegue la Pastorale di Beethoven. Raccolta sembra implicare che i requisiti siano già lì e che si tratti soltanto di vederli, metterli in un cestino e andare avanti allegramente per la propria strada. Ma non funziona così. Nessuno sa esattamente quello che vuole.
Il mito dei requisiti
Quando il software era ancora nella sua infanzia, i computer erano più preziosi (in termini di costi ammortizzati per ora) delle persone che ci lavoravano. Si risparmiava denaro cercando di fare le cose giuste al primo colpo. Dato che le prime macchine erano piuttosto limitate, lo era anche l’ambito dei problemi che risolvevano: era effettivamente possibile comprendere il problema nel suo complesso prima di iniziare.
Questo però non è il mondo reale. Il mondo reale è pieno di confusione, di conflitti e di incognite. In quel mondo le specifiche esatte di qualsiasi cosa sono merce rara, se non decisamente impossibile.
Il nostro compito di programmatori è aiutare le persone a capire che cosa vogliono.
Programmazione come terapia
Il cliente tipico arriva con un bisogno. Può essere un’esigenza strategica, ma è altrettanto probabile che sia una questione tattica: una risposta a un problema corrente.
L’errore che commettono spesso i nuovi sviluppatori è prendere la formulazione di quel bisogno e implementare una soluzione. In base alla nostra esperienza, però, questa formulazione iniziale non è un requisito assoluto. Il cliente forse non se ne rende nemmeno conto, ma si tratta in realtà di un invito a esplorare.
Facciamo un esempio semplice. Lavoriamo per un editore, che pubblica libri cartacei e libri elettronici. Ci viene dato un nuovo requisito: le spedizioni devono essere gratuite per tutti gli ordini superiori ai 50 euro.
Qual è la prima cosa che ci viene in mente? Probabilmente alcune domande.
- I 50 euro comprendono le tasse?
- I 50 euro comprendono anche il costo di spedizione?
- I 50 euro devono riguardare solo i libri cartacei, o l’ordine può includere anche ebook?
- Che tipo di spedizione viene offerta? Normale? Veloce?
- Che cosa succede per gli ordini internazionali?
- Quanto spesso cambierà in futuro quella soglia di 50 euro?
È questo che facciamo noi. Quando ci viene dato qualcosa che sembra semplice, infastidiamo le persone cercando i casi limite e chiediamo che cosa succede in quei casi.
È probabile che il cliente ci abbia già pensato e abbia semplicemente dato per scontato che l’implementazione sarebbe andata in quella direzione. Porre la domanda semplicemente fa venire a galla le informazioni.
I requisiti sono un processo
I requisiti si apprendono in un ciclo di feedback. Il nostro compito è aiutare il cliente a comprendere le conseguenze dei requisiti che ha formulato. Lo facciamo fornendogli un feedback e lasciando che usi quel feedback per mettere a punto le sue idee.
Nell’esempio precedente, era facile esprimere il feedback in parole, ma a volte non è così. In questi casi, i programmatori pragmatici si affidano alla scuola del feedback è questo quello che intendeva?. Produciamo mockup e prototipi e lasciamo che il cliente ci giochi.
A volte questi prototipi possono essere allestiti nel giro di un’ora o poco più. Sono ovviamente solo accrocchi per mettere alla prova un’idea.
La realtà però è che tutto il lavoro che facciamo è in effetti una qualche forma di mockup. Il programmatore pragmatico guarda tutto il progetto come un esercizio di raccolta dei requisiti. Per questo preferiamo le brevi iterazioni, che si concludono tutte con un feedback diretto del cliente. Questo ci mantiene sulla strada giusta e ci dà la certezza che quando sbagliamo perderemo poco tempo.
Mettersi nei panni del cliente
Esiste una tecnica semplice, per entrare nella testa dei clienti, ma non viene usata molto spesso: diventare un cliente. Scriviamo un sistema per l’help desk? Seguiamo le telefonate con una persona esperta dell’assistenza, per un paio di giorni. Dobbiamo automatizzare un sistema manuale di controllo delle giacenze? Lavoriamo in magazzino per una settimana.
È un tempo molto meno lungo di quello che sembra e, oltre ad avere un’idea di come il sistema viene realmente usato, resteremo stupiti da come la richiesta Posso sedermi vicino a lei mentre svolge il suo lavoro? contribuisca a generare fiducia e stabilisca una base di comunicazione con i clienti.
Requisiti contro norme aziendali
Immaginiamo che, discutendo di un sistema per le risorse umane, un cliente dica: Solo i supervisori di un dipendente e l’ufficio del personale possono vedere i record di quel dipendente. Questa affermazione è un vero requisito? Forse oggi, ma incorpora in un enunciato assoluto un elemento di norma aziendale.
Norma aziendale? Requisito? È una distinzione abbastanza sottile, ma per gli sviluppatori avrà implicazioni profonde. Se il requisito è formulato come Solo i supervisori e l’ufficio del personale possono vedere il record di un dipendente, lo sviluppatore può finire per scrivere un test esplicito ogni volta che l’applicazione accede a questi file. Se l’enunciato invece è Solo gli utenti autorizzati possono accedere al record di un dipendente, lo sviluppatore probabilmente progetterà e realizzerà qualche tipo di sistema di controllo degli accessi.
Solo una cosina ancora…
Molti fallimenti di progetti sono attribuiti a un allargamento del raggio d’azione, al progressivo aumento delle caratteristiche da inserire. È un aspetto della sindrome della rana bollita.
La risposta (ancora una volta) sta nel feedback. Se lavoriamo con il cliente in iterazioni con feedback costante, il cliente sperimenterà con i suoi occhi l’impatto di ancora una cosina soltanto. Vedrà un’altra schedina con una storia appiccicata sulla bacheca e dovrà aiutarci a scegliere un’altra schedina da spostare all’iterazione successiva per fare spazio. I feedback funzionano in entrambe le direzioni.
Mantenere un glossario
Creiamo e teniamo sempre aggiornato un glossario di progetto, un luogo unico in cui sono definiti tutti i termini specifici utilizzati nel progetto. Tutti i partecipanti al progetto, dagli utenti finali al personale dell’assistenza, devono usare il glossario per garantire la coerenza. È molto difficile portare a buon fine un progetto in cui utenti e sviluppatori si riferiscono alla stessa cosa con nomi diversi o, ancora peggio, usano lo stesso nome per parlare di cose diverse.
Cose da evitare durante lo sviluppo
Dare a un computer due pezzi di informazione contraddittori era il modo preferito dal Capitano James T. Kirk per rendere inoffensiva un’intelligenza artificiale finita fuori strada. Purtroppo, lo stesso principio può essere efficace per mettere al tappeto il nostro codice.
Da programmatori raccogliamo, organizziamo, manuteniamo e imbrigliamo conoscenza. Purtroppo, però, la conoscenza non è stabile. Cambia, e spesso anche rapidamente. La comprensione di un requisito può mutare dopo una riunione con il cliente. Il governo modifica una norma e una certa logica aziendale diventa obsoleta. I test possono dire che l’algoritmo scelto non funziona.
Secondo noi l’unico modo per sviluppare software in modo affidabile e per rendere ciò che sviluppiamo più facile da comprendere e da manutenere è seguire quello che chiamiamo il principio DRY, Don’t Repeat Yourself: non ripeterti. Ogni elemento di conoscenza in un sistema – non solo il codice – deve avere un’unica rappresentazione, priva di ambiguità e autorevole.
Esaminiamo alcuni esempi di duplicazione e qualche strategia generale per affrontarli.
Duplicazione nel codice
Può sembrare banale, ma la duplicazione del codice è estremamente comune. Ecco un esempio:
def print_balance(account
printf "A debito: %10.2f\n", account.debits
printf "A credito: %10.2f\n", account.credits
if account.fees < 0
printf "Commissioni: %10.2f-\n", -account.fees
else
printf "Commissioni: %10.2f\n", account.fees
end
printf " ———-\n"
if account.balance < 0
printf "Saldo: %10.2f-\n", -account.balance
else
printf "Saldo: %10.2f\n", account.balance
end
end
Per ora facciamo finta di non vedere l’errore da principianti di conservare valori monetari in numeri a virgola mobile. Vediamo invece se riesci a individuare le duplicazioni in queste cose. (Almeno tre).
In primo luogo, c’è chiaramente una duplicazione del tipo copia e incolla nella gestione dei numeri negativi. Possiamo sistemare aggiungendo un’altra funzione:
def format_amount(value)
result = sprintf("%10.2f", value.abs)
if value < 0
result + "-"
else
result + " "
end
end
def print_balance(account)
printf "A debito: %10.2f\n", account.debits
printf "A credito: %10.2f\n", account.credits
printf "Commissioni: %s\n", format_amount(account.fees)
printf " ———-\n"
printf "Saldo: %s\n", format_amount(account.balance)
end
Un’altra duplicazione è la ripetizione del campo larghezza in tutte le chiamate a printf. Potremmo sistemarla introducendo una costante e passandola a ogni chiamata, ma perché non usare semplicemente la funzione esistente?
def format_amount(value)
result = sprintf("%10.2f", value.abs)
if value < 0
result + "-"
else
result + " "
end
end
def print_balance(account)
printf "A debito: %s\n", format_amount(account.debits)
printf "A credito: %s\n", format_amount(account.credits)
printf "Commissioni: %s\n", format_amount(account.fees)
printf " ———-\n"
printf "Saldo: %s\n", format_amount(account.balance)
end
C’è altro? Beh, che cosa succederebbe se il cliente chiedesse uno spazio in più fra etichette e numeri? Dovremmo modificare cinque righe. Eliminiamo questa duplicazione:
def format_amount(value)
result = sprintf("%10.2f", value.abs)
if value < 0
result + "-"
else
result + " "
end
end
def print_line(label, value)
printf "%-9s%s\n", label, value
end
def report_line(label, amount)
print_line(label + ":", format_amount(amount))
end
def print_balance(account)
report_line("A debito", account.debits)
report_line("A credito", account.credits)
report_line("Commissioni", account.fees)
print_line("", "———-")
report_line("Balance", account.balance)
end
Se dobbiamo cambiare la formattazione delle cifre, cambiamo format_amount. Se vogliamo modificare il formato delle etichette, cambiamo report_line.
Si possono cercare altre violazioni implicite del principio DRY.
Non tutta la duplicazione è duplicazione di conoscenza
All’interno di un’applicazione per ordini di vino online, catturiamo e validiamo l’età dell’utente, insieme con la quantità di vino che ordina. In base alle richieste del proprietario del sito, deve trattarsi in entrambi i casi di numeri maggiori di zero. Scriviamo le nostre convalide:
def validate_age(value):
validate_type(value, :integer)
validate_min_integer(value, 0)
def validate_quantity(value):
validate_type(value, :integer)
validate_min_integer(value, 0)
Durante la revisione del codice, il saputello di turno spedisce indietro il codice, sostenendo che viola il principio DRY: il corpo delle due funzioni è identico.
Ha torto. Il codice è lo stesso, ma la conoscenza rappresentata è diversa. Le due funzioni validano due cose diverse che semplicemente hanno le stesse regole. Questa è una coincidenza, non una duplicazione.
Duplicazione nella documentazione
In qualche modo è nato il mito che si debbano commentare tutte le funzioni. Chi è convinto di questa follia produce cose come questa:
# Calcola le commissioni per questo conto.
#
# * Ogni assegno respinto costa $20
# * Se il conto è in rosso per più di 3 giorni,
# addebita $10 per ogni giorno
# * Se il saldo medio del conto è maggiore di $2000
# riduci le commissioni del 50%
def fees(a)
f = 0
if a.returned_check_count > 0
f += 20 * a.returned_check_count
end
if a.overdraft_days > 3
f += 10*a.overdraft_days
end
if a.average_balance > 2_000
f /= 2
end
f
end
La finalità di questa funzione è presentata due volte: una nel commento e una nel codice. Cambiano le commissioni per un cliente e dobbiamo aggiornare in entrambi i punti. Con il tempo, possiamo essere sicuri che commento e codice finiranno per non essere più in sincronia.
Che cosa aggiunge, quel commento, al codice? Dal nostro punto di vista, semplicemente cerca di compensare una scelta discutibile dei nomi e del layout. Prendiamo invece questa versione:
def calculate_account_fees(account)
fees = 20 * account.returned_check_count
fees += 10 * account.overdraft_days
if account.overdraft_days > 3
fees /= 2
if account.average_balance > 2_000
fees
end
Il nome è indicativo della funzione svolta e, se qualcuno ha bisogno dei particolari, li trova esplicitati nel codice sorgente. Questo è DRY!
Violazioni del principio DRY nei dati
Le strutture di dati rappresentano conoscenza e possono infrangere il principio DRY. Ecco una classe che rappresenta un segmento di retta:
class Line {
Point start;
Point end;
double length;
};
A prima vista, questa classe può sembrare sensata. Un segmento chiaramente ha un estremo iniziale e un estremo finale e avrà sempre una lunghezza (al limite uguale a zero). Qui però abbiamo duplicazione: la lunghezza è definita dai punti di inizio e di fine e, se si cambia uno dei due punti, cambia anche la lunghezza. Meglio che questa sia un campo calcolato:
class Line {
Point start;
Point end;
double length() { return start.distanceTo(end); }
};
Firmare o non firmare il codice scritto in azienda
Ci hai deliziato abbastanza a lungo.
– Jane Austen, Orgoglio e pregiudizio
I programmatori pragmatici non sfuggono alle responsabilità: anzi, sono felici di accettare le sfide e di rendere ben nota la loro competenza. Se siamo responsabili di un progetto, o di un pezzo di codice, facciamo un lavoro di cui possiamo essere orgogliosi.
Gli artigiani di un tempo erano orgogliosi di firmare il loro lavoro, e anche voi dovremmo esserlo.
I team di progetto sono ancora fatti di persone, però, e questa regola può essere fonte di guai. In qualche progetto, l’idea di proprietà del codice può causare problemi di cooperazione: le persone diventano territoriali o non disponibili a lavorare sugli elementi delle fondamenta comuni.
Non è quello che vogliamo. Non dobbiamo difendere gelosamente il vostro codice contro gli intrusi; al tempo stesso, dobbiamo trattare con rispetto il codice degli altri.
L’anonimato, in particolare nei grandi progetti, può favorire un terreno di coltura per i germi della trascuratezza, gli errori, la pigrizia e il codice scritto male. Diventa troppo facile vedersi come una semplice rotella in un grande meccanismo e avanzare scuse patetiche in infiniti report di stato, anziché contribuire con buon codice.
Il codice deve essere di proprietà di qualcuno, ma non necessariamente di un individuo. In effetti, l’eXtreme Programming di Kent Beck consiglia la proprietà condivisa del codice (ma questo richiede anche altre pratiche, come la programmazione in coppia, per proteggersi contro i pericoli dell’anonimato).
Vogliamo vedere l’orgoglio della proprietà: L’ho scritto io e mi prendo la paternità del mio lavoro. La nostra firma deve essere riconosciuta come un indicatore di qualità. Le persone devono vedere il nostro nome su un pezzo di codice e immaginare subito che sia solido, ben scritto, collaudato e documentato. Un vero lavoro da professionisti, scritto da un vero professionista.
Un Pragmatic Programmer.
Questo articolo richiama contenuti da Pragmatic Programmer – Edizione del 20° anniversario.
L'autore
Iscriviti alla newsletter
Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo
Corsi che potrebbero interessarti
Agile, sviluppo e management: iniziare bene
Big Data Analytics - Iniziare Bene
Content Design - Fare una Strategia
Libri che potrebbero interessarti
Pragmatic Programmer - Edizione del 20° anniversario
Guida per artigiani del software che vogliono diventare maestri
Clean Architecture
Guida per diventare abili progettisti di architetture software