Dev Log - Settimana 1: posare le fondamenta

Questa settimana ho iniziato un importante lavoro di refactoring sui miei tre moduli WHMCS: Billing Extension, Commission Manager e Mercury.

Al momento sto anche valutando la possibilità di unire tutti e tre in un unico prodotto, semplicemente chiamato Katamaze. Si tratta ancora solo di un'ipotesi, non di una decisione definitiva, ma è una direzione che sto esplorando seriamente. Il concetto è semplice: invece di scegliere quale modulo acquistare, i clienti avrebbero un'unica soluzione completa che include la fatturazione (Billing Extension), la gestione delle provvigioni degli affiliati (Commission Manager) e la pubblicazione di contenuti (Mercury). Naturalmente ognuno potrebbe comunque utilizzare solo le parti di cui ha bisogno.

A causa di questo enorme refactoring, lo sviluppo di nuove funzionalità sugli attuali moduli è sospeso. Non avrebbe senso continuare ad ampliare la vecchia codebase mentre sto ricostruendo dalle fondamenta tutti e tre i moduli contemporaneamente.

Un po' di contesto. Gran parte del codice che sto riscrivendo risale al 2014. All'epoca WHMCS non forniva molti degli strumenti su cui oggi gli sviluppatori possono contare: niente autoloader, nessun sistema moderno a classi, nessuna gestione adeguata della multilingua. Ho dovuto creare il mio framework da zero – autoloader, sistema di lingua, livelli di accesso al database – tutto.

Ha funzionato per anni, ma ha anche generato debito tecnico. Mentre WHMCS introduceva gradualmente queste funzionalità nelle versioni 6, 7 e 8, i miei moduli erano già legati all'ecosistema personalizzato che avevo costruito. Non ero contrario ai miglioramenti di WHMCS, semplicemente non potevo adottarli senza rompere il mio software.

Ora, per la prima volta, posso finalmente sfruttare appieno gli standard moderni offerti da WHMCS e lasciarmi alle spalle il framework personalizzato che ho portato avanti così a lungo.

Un'altra importante fonte di debito tecnico è stata la mia scelta, protratta per anni, di supportare troppe eccezioni. Per dare un'idea: mentre WHMCS 9 è ormai in arrivo, i miei moduli supportano ancora le versioni 5, 6, 7 e 8. Non è solo obsoleto, è insostenibile.

Ho anche passato anni a implementare workaround per casi limite causati da template personalizzati o da moduli di terze parti (spesso scritti dando per scontato di essere l'unico modulo presente nel WHMCS di un cliente). Questo ha rappresentato un enorme dispendio di tempo ed energie, e alla fine ha portato beneficio solo a pochi setup a discapito di tutti gli altri.

D'ora in avanti mi allineo a quanto già fanno tutti gli altri sviluppatori in questo ecosistema:

• Supporterò solo le versioni di WHMCS attivamente supportate da WHMCS stessa
• Non introdurrò più fix o codice custom per gestire conflitti creati da moduli o template di terze parti. Ogni sviluppatore è responsabile del proprio software

So che questo potrà deludere qualcuno, ma mantenere la compatibilità con versioni non supportate o con codice di terze parti progettato male non è più sostenibile. Il focus deve essere su stabilità, prestazioni e mantenibilità a lungo termine per la maggioranza degli utenti.

Ecco cosa ho realizzato in questa prima settimana:

• Adozione delle funzionalità moderne di WHMCS: autoloader, gestione aggiornata della lingua e strumenti nativi per sviluppatori sostituiscono ora le mie vecchie soluzioni custom
• Ridefinizione dell'archiviazione delle configurazioni: la nuova struttura del database è flessibile e pronta per il futuro
• Introduzione di un sistema di log dedicato: log multilingua, professionali e separati dall'activity log di WHMCS
• Ottimizzazione della gestione dei dati: classi auto-inizializzanti con cache riducono le query ridondanti e velocizzano le prestazioni
• Installer, disinstallazione e aggiornamenti più robusti: l'installazione fornisce feedback dettagliati, la disinstallazione crea automaticamente backup e le migrazioni includono rollback per prevenire fatal error o perdite di dati durante gli aggiornamenti

Questo è solo l'inizio, ma le fondamenta per il futuro sono già state poste. Che alla fine io decida di unire tutto in un unico modulo oppure di mantenerli separati, la direzione è chiara: una codebase più pulita, veloce e affidabile.

Non posso e non voglio impegnarmi su tempistiche, visto che sto anche gestendo altri progetti e responsabilità. Ciò che posso dire è che sto lavorando attivamente a questo refactoring ogni settimana, passo dopo passo, con l'obiettivo di consegnare qualcosa di davvero solido e duraturo.

Side note: nelle ultime settimane ho ricevuto molte richieste in merito alla fatturazione elettronica spagnola, che diventerà obbligatoria il prossimo anno. In realtà gran parte delle logiche alla base della fatturazione elettronica in Spagna (così come in altri paesi) sono molto simili al sistema che Billing Extension utilizza da anni per l'Italia: in teoria basterebbe adattare l'output.

Detto questo, non intendo occuparmene: sarebbe in conflitto con gli obiettivi che mi sono prefissato in questa fase di refactoring. WHMCS ha già annunciato ufficialmente che la prossima versione supporterà la fatturazione elettronica, quindi vi invito a fare riferimento a loro per questo aspetto.

Personalmente nutro qualche perplessità: per introdurre davvero la fatturazione elettronica servono modifiche strutturali e concettuali profonde in WHMCS, oltre a un'estrema attenzione ai dettagli. Staremo a vedere.