L'
previsto per la release 2.7 mi ha dato lo spunto per un post che avevo in mente da tanto tempo sulla brutta (e sconveniente) abitudine di customizzare "manualmente" le piattaforme.
Parliamo di WordPress che più si presta ad un esempio. Buona parte delle installazioni di WordPress che ho avuto modo di vedere o utilizzare sono state personalizzate. Chi nel template, chi nelle funzionalità , chi nel comportamento... ognuna di esse ha una qualche modifica per rispondere alle esigenze di chi la utilizza.
Prendiamo per esempio questo blog: utilizza una versione personalizzata di WordPress con alcune funzionalità utili alla redazione per gestire i contributi dei collaboratori. Anche il network
, se non ricordo male, si basa su una versione di WordPress intorno alla 1.5.
Ci sono due strade per intervenire su una piattaforma: le modifiche manuali ed i plugin.
Il primo caso è normalmente più rapido ed immediato ma non tiene in considerazione il lungo periodo. Il secondo caso, invece, è la scelta che dovrebbe essere presa in considerazione ogni qual volta si utilizza una libreria esterna, un componente che segue un processo di sviluppo separato rispetto al nostro.
Molte versioni di WordPress sono state profondamente modificate tanto da rendere il loro aggiornamento una storia degna di Indiana Jones. Il prezzo da pagare è spesso molto più alto di quanto sarebbe stato, in termini di tempo, creare un plugin.
Ma allora, se questa soluzione è migliore, perché è la meno diffusa? Questa è la domanda che mi ripeto più spesso e da anni a questa parte ho trovato che la risposta è quasi sempre una sola: cià che non si conosce appare difficile e la pigrizia di "tornare a studiare" condiziona le nostre scelte.
è la dimostrazione concreta di come sia banale usare un plugin per sfruttare le nostre modifiche indipendentemente dall'installazione di WordPress.
WordPress è senz'altro uno degli esempi più calzanti ma potrei benissimo estendere l'esempio anche ad altri ambiti come i framework.
diventa un incubo quando avete modificato la core library invece di adottare uno sviluppo a componenti.
Contrariamente a quanto possa sembrare, questo è un problema tutt'altro che recente. Già nel 1987 l'argomento è stato affrontato e la
(
) è uno dei principi fondamentali per lo sviluppo professionale di software, in particolare nel campo dell'Object Oriented Programming. Una lettura di approfondimento che vale il tempo che gli dedicherete.
