Qualche tempo fa stavo discutendo con una conoscenza circa una funzionalità da aggiungere ad un programma che stava sviluppando.
Ad un tratto la fatidica, classica frase:
“Per adesso va bene così, grazie. Tanto non so cosa ne farò e quindi non voglio spenderci troppo tempo.”
Nulla di male nel non voler buttare troppa carne sul fuoco, ma ogni volta che ho pensato quella stessa frase, puntualmente mi sono ritrovato poi a dover riprendere ed estendere qualcosa. Non parliamo poi del riuso.
Pensare per estendere e per riciclare
È indubbio che tutti i programmi, presi come entità singole, siano differenti gli uni dagli altri, nel senso che ognuno ha una sua vita propria. Tuttavia, è altrettanto vero che molto spesso, programmi anche molto diversi fra loro, contengano porzioni di codice simili o del tutto identiche.
E’ il bello dello sviluppo modulare: operando in modo opportuno, ogni cosa può essere estesa e riciclata all’infinito:
“Code reuse, also called software reuse, is the use of existing software, or software knowledge, to build new software”
La frase, tratta Wikipedia, mi pare renda bene l’idea: di solito si parla di riuso del codice riferendosi agli artefatti prodotti in fase implementativa, ma riuso è anche quello delle idee e della conoscenza.
Un piccolo, banale caso di studio: la console degli eventi
Indipendentemente dal progetto specifico, inserisco sempre nei miei programmi una console degli eventi“, un registro di quanto accade nel programma e che mi permette di verificarne lo stato di esecuzione anche quando non ho gli strumenti di debug a portata di mano.
Che tale console funzioni via seriale, via HTTP (browser) oppure una semplice listview a comparsa/scomparsa inserita direttamente nell’interfaccia del programma, non ha importanza.
Con l’andare del tempo ho di fatto astratto le caratteristiche base che un tipo di modulo come questo dovrebbe avere, rendendolo facilmente portabile da progetto a progetto e perfino da linguaggio a linguaggio: una console, alla fine, non è che una “finestrella” che sputa dei dati di funzionamento e, si suppone, non debba far altro.
Quindi, si tratta di qualcosa di semplicissimo e innocuo: è talmente piccolo e isolato come “modulo concettuale” da poter essere anche esteso senza timore di danneggiare il resto del codice, qualunque esso sia.
Anzi, è pensato per essere esteso. Normalmente “rappresento” internamente la console come una piccola coda circolare contenente eventi sotto forma di semplici strutture contenenti 4 campi: timestamp, tipo di evento, sorgente e messaggio vero e proprio. All’occorrenza basta ingrandire la struttura, quindi basta toccare la funzione che aggiunge un nuovo evento alla coda (es: addEvent()).
Il fatto di avere una struttura al posto di una singola stringa con dentro tutto agevola alcune operazioni a fronte di un piccolo aumento di memoria occupata. In ogni caso la presenza a monte di una coda circolare attua un controllo ben più restrittivo sull’uso della memoria, per cui il “costo” si una singola struttura-evento è relativamente trascurabile.
Tutto ciò, nella sua banalità, comporta dei vantaggi interessanti. Tanto per cominciare, se serve, posso rapidamente aggiungere una funzione di ricerca per campi in quella coda e non devo “riparsare” le stringhe per cercare qualcosa di specifico.
In secondo luogo separare rappresentazione e logica di funzionamento interna (model e controller) da rappresentazione esterna (view) fa molto pattern Model-View-Controller (MVC), con tutti i benefici del caso: recentemente ho aggiunto una funzione di esportazione dei dati della console in formato PDF che riordinava i campi con certi criteri, partendo dalle strutture prima dell’export vero e proprio. Inoltre alcuni linguaggi (es: C#) permettono di serializzare e deserializzare velocemente strutture dati per cui trasferire gli “eventi” da un posto all’altro risulta estremamente semplice.
A lungo andare la “combo” console + coda circolare + eventi come strutture è diventata una mia prassi, un mio paradigma operativo derivato dall’esperienza, qualcosa di sufficientemente piccolo da essere facilmente portabile, riusabile ed estendibile pressochè ovunque.
Sia chiaro, non è una panacea nè si configura come una soluzione adatta in ogni contesto, ma i ragionamenti che sono alla sua base probabilmente lo possono diventare.
Riassumendo…
Ora il paradigma “console” non è più “mostrare i dati in un posto e stop“, ma è qualcosa di più: col tempo è diventato la somma della mia esperienza nel trattare quel tipo di modulo, in un ampio numero di casi specifici. È il minimo comun denominatore dell’utilizzo “canonico” che ne faccio abitualmente.
Ovviamente il discorso non vale solo per la console, ma lo applico in modo diffuso. Questo è il mio algoritmo mentale:
- se una volta ho avuto bisogno di qualcosa, è probabile che prima o poi ne avrò bisogno;
- costruito uno schema logico (es: “console degli eventi”), pensato per essere esteso e riusato, è un gioco da ragazzi adattarlo ad un singolo caso specifico, aggiungendo o eliminando quello che non serve a seconda della necessità del momento.
- se un caso specifico ha comportato qualche novità interessante e a costo relativamente contenuto (ricerca per campi agevolata dagli eventi definiti come strutture), allora vale la pena aumentare lo schema logico iniziale, in modo che tutti i successivi progetti ne traggano beneficio.
Una sorta di “impara l’arte e (ri)usala” unita a “programmatore, conosci te stesso“.
Che ne pensate?
