Legacy code: il modo migliore per gestirlo

Il codice sorgente è l’elemento centrale di un software. Che il programma venga eseguito nel modo de­si­de­ra­to e permetta di svolgere de­ter­mi­na­te funzioni, dipende dalle istru­zio­ni e dai comandi re­gi­stra­ti in questo codice. I pro­gram­ma­to­ri lo mo­di­fi­ca­no, lo man­ten­go­no e lo ag­gior­na­no re­go­lar­men­te per fornire agli utenti la migliore frui­bi­li­tà possibile. Qualsiasi modifica del codice può talvolta com­por­ta­re errori del software o com­pro­met­te­re la capacità di ese­cu­zio­ne del programma.

Per gli svi­lup­pa­to­ri e i pro­gram­ma­to­ri, la ma­nu­ten­zio­ne e l’ag­gior­na­men­to del software si rivelano par­ti­co­lar­men­te pro­ble­ma­ti­ci quando devono lavorare con un codice che non hanno scritto loro stessi o che è stato scritto per sistemi operativi più vecchi e non più sup­por­ta­ti, in versioni al­tret­tan­to vecchie del lin­guag­gio di pro­gram­ma­zio­ne che ne sta alla base. Nel nostro articolo vi mostriamo che cos’è esat­ta­men­te il legacy code e il modo migliore per gestirlo.

Il termine “legacy code” è usato nella tec­no­lo­gia software e sta a indicare un codice antico. Si tratta di un codice più vecchio, che di solito non viene più svi­lup­pa­to at­ti­va­men­te. Il legacy code è in un certo senso la con­tro­par­te del “Clean Code”, che è in­tui­ti­va­men­te com­pren­si­bi­le, par­ti­co­lar­men­te facile da mantenere e fa­cil­men­te adat­ta­bi­le. Il legacy code è vo­lu­mi­no­so, obsoleto e di­sor­di­na­to, motivi per i quali possono insorgere numerosi problemi. Esso dipende for­te­men­te dalla visione dello svi­lup­pa­to­re e dal contesto par­ti­co­la­re per il quale viene creato. In linea di principio, è ca­rat­te­riz­za­to dai seguenti aspetti:

• Il codice non viene più mantenuto dallo svi­lup­pa­to­re originale.
• Il codice è stato scritto ori­gi­na­ria­men­te per sistemi operativi non più sup­por­ta­ti.
• Il codice non può essere testato per i bug in modo au­to­ma­tiz­za­to.

Alla luce di questa serie di svantaggi, perché si continua a uti­liz­za­re il legacy code? Sem­pli­ce­men­te perché non si può sempre evitare: spesso accade che nel corso di un progetto subentri un nuovo pro­gram­ma­to­re a occuparsi della ma­nu­ten­zio­ne e dell’ulteriore sviluppo del codice. Mentre lo svi­lup­pa­to­re originale ha scritto il codice in maniera intuitiva, i nuovi membri del team devono prima di tutto com­pren­der­lo per poterne con­ti­nua­re lo sviluppo. Può accadere che parti del codice vengano tra­scu­ra­te o che non vengano com­ple­ta­men­te comprese.

Se un codice viene mantenuto, mi­glio­ra­to e mo­di­fi­ca­to di­ver­sa­men­te da più pro­gram­ma­to­ri nel corso degli anni, il codice può diventare col tempo un’ac­coz­za­glia sempre più difficile da com­pren­de­re e mo­di­fi­ca­re. Il problema è che, a un certo punto, gli ag­gior­na­men­ti o le modifiche ne­ces­sa­rie non possono essere ef­fet­tua­ti se nessuno riesce più a com­pren­de­re il codice e i suoi effetti.

Il codice legacy ha un ulteriore svan­tag­gio: i test di re­gres­sio­ne, cioè i test au­to­ma­tiz­za­ti, non possono essere eseguiti a causa della pro­gram­ma­zio­ne troppo vo­lu­mi­no­sa, in­gom­bran­te e di­so­mo­ge­nea. Agli svi­lup­pa­to­ri che devono occuparsi del legacy code è richiesto quindi un impegno manuale per la verifica de­ci­sa­men­te più elevato. I bug sono più difficili da risolvere, gli ag­gior­na­men­ti più com­pli­ca­ti da im­ple­men­ta­re.

Gli svi­lup­pa­to­ri non amano occuparsi del legacy code per vari motivi. Uno dei problemi maggiori è il fatto che il codice non può essere testato au­to­ma­ti­ca­men­te per bug o errori. Che cosa possono fare, quindi, gli svi­lup­pa­to­ri se im­prov­vi­sa­men­te devono con­fron­tar­si con il legacy code nel corso di un nuovo progetto?

La risposta migliore è: re­fac­to­ring. Con questa tecnica di sviluppo, il codice viene ri­strut­tu­ra­to senza mo­di­fi­ca­re la sua funzione originale. Prima di eseguire il re­fac­to­ring vero e proprio, i pro­gram­ma­to­ri devono aver compreso la finalità di ogni parte del codice. Inoltre, tutte le funzioni devono essere con­va­li­da­te tramite test.

Solo quando è chiaro come funziona il codice, si può procedere al re­fac­to­ring vero e proprio. Il codice viene così ot­ti­miz­za­to pezzo per pezzo. Le parti superflue vengono rimosse o riscritte, le classi di codice e le variabili vengono sem­pli­fi­ca­te e rag­grup­pa­te, i metodi di comando vengono mo­di­fi­ca­ti e riscritti. In de­fi­ni­ti­va, il re­fac­to­ring è una revisione generale del legacy code. Ne risulta un codice più facile da capire, più facile da mantenere e più veloce da mo­di­fi­ca­re.