Refactoring

Uno degli aspetti più interessanti e distintivi dell’approccio Maker è quello di apprendere dall’esperienza quello che serve per produrre.
E’ questa una delle ragioni per cui non ci siamo tirati indietro dalla sfida di questo progetto pur non avendo tutte le conoscenze tecniche nell’ambito della meccanica automobilistica.
Un’altro fatto interessante è scoprire che concetti e metodi utilizzati per certi contesti applicativi, possono rivelarsi ugualmente utili per affrontare problemi apparentemente molto diversi rispetto a quelli per cui sono stati definiti.


Nella fase attuale di iaiaGi, stiamo definendo le caratteristiche chiave del motore elettrico adatto ad essere impiegato per convertire un’autovettura di classe B.
Pensando alla sostituzione del motore, viene spontaneo riflettere su quale potrebbe essere l’approccio migliore per pianificare il processo di sostituzione del vecchio motore con il nuovo.
In queste riflessioni mi è tornato alla mente un concetto importante dell’ingegeria del software e delle metodologie agili di sviluppo: il refactoring. E con un po’ di sorpresa mi sono reso conto che tutti gli approcci validi nel refactoring del software saranno applicabili anche nel nostro progetto di conversione.

Il refactoring è una operazione di ristrutturazione di un programma software nel quale viene sostituita una parte del codice sorgente con il vincolo di mantenere inalterato il comportamento generale del programma. Le motivazioni di tale sostituzioni sono in genere per ottenere un miglioramento, quasi sempre legato alle prestazioni, alla manutenibilità o all’estensibilità del codice.
Nel software il refactoring normalmente avviene seguendo questi passi:

  • si individua la sezione di codice sorgente da modificare
  • si delinea un “confine” che individui il minor numero di interazioni ben definite tra tale sezione e tutto il resto del sorgente
  • si definiscono e documentano tutte le interfacce su tale confine
  • si procede con la completa ridefinizione della parte da sostituire, in modo che le interfacce definite in precedenza non vengano modificate nè nella struttura nè nel comportamento.
  • alla fine, si procede al test di regressione.

E’ interessante notare che se al posto di software pensiamo all’autovettura e consideriamo una sua sezione (ad es. il motore), i passi elencati sopra saranno assolutamente validi:

  • La sezione da modificare è il motore
  • Il confine include tutte le connessioni con altri dispositivi che possono essere scollegate e successivamente ricollegate senza alterare le modalità di interazione
  • Tali connessioni sono le interfacce
  • A questo punto, pensando di rimuovere fisicamente il motore, è necessario analizzare e progettare i modi in cui tutte le interfacce verranno operate in maniera immutata, pur essendoci ora un motore asincrono trifase al posto di uno a combustione interna.

Nei casi reali di ristrutturazioni complesse di un software, non si ottiene mai una completa reintegrazione di tutte le interfacce e funzioni. Questo può accadere, per esempio, se il codice di partenza era troppo poco strutturato per permettere un’analisi efficace o, se per motivi di priorità, certe funzionalità precedenti possono essere temporaneamente disattivate per poi reintegrarle in seguito.
Lo stesso, direi, vale per la conversione di un autoveicolo.
Nel disconnettere il motore esistente, potranno accadere alcune cose:

  • Alcune interazioni potranno essere riutilizzate così come sono (ad es., il disco della frizione)
  • Alcune saranno inutili (es. la carburazione, il serbatoio del carburante, la marmitta…)
  • Altre potranno essere riusate in parte e altre dovranno essere disattivate (ad es., tutti le linee di controllo della centralina).

Con lo stesso processo mentale con cui si opera un refactoring di un programma software, potremo analizzare e pianificare le operazioni di conversione del motore.
Ed esattamente come per il software, il refactoring è tanto più efficace e rapido nell’esecuzione quanto più profonda è la conoscenza del sistema originario.
Questo suggerisce la necessità di spendere tempo a conoscere nel dettaglio come funziona un motore tradizionale e come interagiscono le sue sottoparti.

Leave a Reply