Alcuni punti per riflettere sulla definizione di codice gestibile e non in riferimento a WordPress.
L'autore della guida Single Page App Book ci offre dei punti che a suo avviso rendono il codice non gestibile:
- ha molte dipendenze che lo rendono difficile da capire e da testare in modo indipendente
- accede e modifica i dati nello scope globale, il che rende difficile riprodurre lo stesso stato nei test
- produce effetti collaterali, ossia non può essere instanziato facilmente e in modo ripetuto nei test
- espone i dettagli della sua implementazione, il che rende difficile il refactoring col rischio di generare errori negli altri componenti che dipendono dalla sua interfaccia pubblica.
Il primo punto non deve trarci in inganno: verrebbe infatti da pensare a molti framework MVC PHP, ma in realtà questi framework sono già concepiti in modo da poter effettuare test atomici e indipendenti. In realtà il problema si presenta in quei CMS non MVC o nelle nostre implementazioni personali del pattern MVC.
Ad esempio in WordPress il problema si presenta nei plugin o nei temi che dipendono da plugin. A ben vedere nei CMS come WordPress possono presentarsi tutti i 4 problemi elencati sopra: 1) un bug in un plugin può distruggere un tema o un altro plugin e 2) agendo tutti nel flusso globale possono generare errori nel CMS e 3) creare effetti collaterali usando di fatto 4) delle API pubbliche (filtri ed hook).
In WordPress viene effettuato solo un test iniziale sui temi e plugin per rilevare errori di sintassi, ma ovviamente l'unico modo per rilevare malfunzionamenti è quello di disabilitare i plugin uno alla volta o abilitare la modalità di debug.
Il problema è che usando un unico flusso globale, qualsiasi componente aggiuntivo può interrompere questo flusso. Quindi non si tratta del core del CMS, ma di tutto il codice che viene inserito e che si interfaccia al core.