Lo stack delle cose da fare

Sono uno a cui piace un sacco studiare, imparare cose nuove, approfondire, sperimentare… Non a caso questo blog ha la tag-line «esperimenti di software libero». Il software libero è una delle mie maggiori passioni, a partire dai sistemi operativi per arrivare fino alle applicazioni di utilizzo quotidiano, passando per gli strumenti di sviluppo del software. Quando parlo di sviluppo software mi riferisco praticamente a tutto, ma in particolare allo sviluppo di applicazioni web e dei tool per la gestione delle reti.

Un esempio di applicazione che mi è capitato di sviluppare in passato è quello di uno strumento per convertire la configurazione dei firewall da Checkpoint a Cisco ASA; si trattava di un’applicazione Python da riga di comando, piuttosto rozza, che però faceva il suo sporco lavoro e mi ha aiutato a velocizzare delle operazioni che sarebbe stato oltremodo complicato fare a mano. Purtroppo, per come l’avevo scritta, l’applicazione non era abbastanza generica e quindi andava adattata di volta in volta alla particolare configurazione del firewall di partenza, motivo per il quale non l’ho mai rilasciata pubblicamente. Inoltre da un po’ di tempo Cisco ha aggiornato il suo tool di conversione che funziona relativamente bene, e quindi non ho più motivo di rimettere mano alla mia versione.

Ho fatto questa premessa per introdurre un po’ quello che è il mio approccio all’apprendimento.

Quando devo fare qualcosa, che sia sul lavoro o per puro hobby e divertimento, parto in quarta con l’idea di arrivare velocemente al risultato. Devo scrivere un programma che converte le regole di un firewall? Bene, faccio una bozza dell’algoritmo e poi inizio a scrivere codice (solitamente in Python, che è il linguaggio che al momento conosco meglio). Dopo un po’ di lavoro mi accorgo che il programma non funziona benissimo, e quindi realizzo che ha bisogno di essere testato. Inizio a scrivere lo script che esegue i test, ma è poco flessibile, quindi decido che devo usare un framework apposito. Mi metto alla ricerca di questo framework, lo trovo, provo ad usarlo ma mi accorgo che prima lo devo studiare ed imparare, quindi sospendo lo sviluppo del programma per imparare a realizzare i test nella maniera più corretta. Il framework fa uso di costrutti del linguaggio che non conosco molto bene, e quindi inizio a studiare meglio il linguaggio per capire meglio il funzionamento del framework. Per fare questo, sospendo la realizzazione dei test del programma… Insomma, nel giro di qualche ora ho già una “pila” di attività, ciascuna delle quali è stata interrotta per avviare un’altra attività: è uno “stack”, una struttura dati di tipo LIFO (Last In, First Out), lo stesso tipo di struttura che si usa in programmazione per gestire la chiamata e il rientro delle funzioni. Una funzione, prima di essere completata, ne invoca un’altra, che a sua volta prima di terminare ne invoca un’altra ancora, e così via… Finché parliamo di software va tutto bene, ma quando si tratta di imparare, impilare troppe attività rischia di far perdere di vista l’obiettivo primario, e per questo il mio metodo, o meglio il mio vizio, risulta non proprio ottimale.

Faccio un esempio concreto: voglio realizzare un’applicazione per la gestione degli apparati di rete, per tenere traccia del loro indirizzo IP, del cliente presso il quale sono allocati, delle credenziali di accesso, del serial number, delle licenze e delle relative scadenze, e così via. Decido che questa applicazione deve essere fatta con Django, uno dei più potenti framework per lo sviluppo web con Python. Allora inizio a studiare Django, ma per capirlo al meglio devo anche approfondire Python, ma devo anche migliorare le mie capacità di progettazione dei database. E già questo rende lo sviluppo di una semplice applicazione qualcosa di particolarmente lungo e noioso. Poi mi rendo conto che anche l’occhio vuole la sua parte, e quindi devo imparare a maneggiare anche i linguaggi usati per l’interfaccia utente, e quindi html, css, javascript, framework come Bootstrap, jQuery, ecc. Poi mi rendo anche conto dell’esigenza di utilizzare un sistema per il versioning dei sorgenti, inizio a studiare Git, come si usa, come si configura un server o come si amministra un server GitLab, e così via…

Insomma, per fare una (relativamente) semplice applicazione ho già impilato un sacco di attività, e se non completo prima quella più in cima, non riesco a dedicarmi a quelle via via più in basso. Questo modo di fare non è particolarmente sano perchè, come detto, fa perdere di vista l’obiettivo primario, ovvero lo sviluppo dell’applicazione pensata per risolvere un problema concreto. Certo, imparare tutte queste cose può essere utile di per sé, e procedendo in questo modo si potrà magari diventare “esperti” dei singoli argomenti, ma raggiungere il risultato finale sarà qualcosa di lungo e probabilmente improponibile. Infatti, nel 90% dei casi, il risultato è l’abbandono.

Ma allora qual è l’approccio giusto? Dipende. Dipende dal livello di autodisciplina di ciascuno, e dalla capacità di non lasciarsi distrarre da obiettivi secondari che di volta in volta possono apparire più interessanti e divertenti. Bisogna scendere a compromessi ed accettare il fatto che, in prima istanza, il “prodotto” finale non sarà il migliore possibile, ma potrà essere migliorato in seguito qualora ce ne fosse il bisogno.

Torniamo dunque all’esempio iniziale, il tool che convertiva le configurazioni dei firewall: era scritto male, non aveva un’interfaccia utente degna di questo nome, non era di uso generale, ma era sufficiente a raggiungere il risultato. L’ho usato diverse volte, poi non mi è più servito per un po’, e poi ne ho avuto nuovamente bisogno dopo qualche anno. In quell’occasione l’ho modificato, l’ho migliorato e ho di nuovo ottenuto il risultato cercato, stavolta di qualità leggermente migliore. Poi non mi è servito più e non ho più motivo di rimetterci mano.

Questo è quindi l’approccio migliore: fare qualcosa in funzione del risultato che si intende ottenere, lasciando i ricami e gli orpelli ad un’iterazione successiva. KISS: Keep It Simple, Stupid! Vediamo quindi se, dopo aver autoanalizzato le debolezze della mia condotta, riuscirò a realizzare l’applicazione per la gestione dei dispositivi di rete in un tempo ragionevole.

Leave a Reply

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.