L'obiezione ragionevole
"Perché perdere tempo a costruire un framework quando Laravel esiste?" E la domanda più frequente — e la più ragionevole. Laravel ha un ecosistema sterminato, una community enorme, pacchetti per qualsiasi esigenza. Scegliere di costruire da zero sembra un atto di hybris, l'orgoglio di chi vuole reinventare la ruota per dimostrare di poterlo fare.
Ma la domanda nasconde un'assunzione: che lo scopo del software sia sempre la produttività . Che il valore di un progetto si misuri in feature per ora. Che la strada più corta sia sempre la migliore. E un'assunzione comprensibile nel contesto professionale, dove il tempo e denaro e i clienti hanno scadenze. Ma non e l'unica assunzione possibile.
Nel contesto di un progetto personale e di portfolio, la produttività non e il metro principale. Il metro e la comprensione. E la comprensione profonda di come funziona un framework — dall'ORM al routing, dal middleware alla CLI — non si ottiene usando un framework: si ottiene costruendone uno.
La mappa non e il territorio
Alfred Korzybski ci ricorda che la mappa non e il territorio. Usare Laravel e avere una mappa eccellente: sai dove andare, conosci i percorsi battuti, hai guide per ogni sentiero. Ma costruire un framework e esplorare il territorio stesso: scopri perché i sentieri sono dove sono, cosa c'e fuori dalla mappa, dove i confini sono arbitrari.
Quando implementi un ORM da zero, scopri che il dirty tracking non e magia — e un array che confronta valori originali con valori correnti. Quando scrivi un query builder, scopri che il pattern Builder non e solo un diagramma UML — e una necessita pratica per comporre query complesse senza concatenare stringhe SQL. Quando costrui un sistema di migrazioni multi-driver, scopri che SQL non e uno standard — e quattro dialetti che fingono di essere lo stesso linguaggio.
Cosa impari costruendo un ORM
L'ORM di Soft PHP MVC implementa concetti che in Laravel sono nascosti dietro la magia di Eloquent:
-
Dirty tracking — confronto tra
$originale$attributesper generare solo le colonne modificate nell'UPDATE - Casting dei tipi — conversione trasparente tra tipi PHP e tipi database (boolean, json, datetime, integer)
- Query caching — cache automatica delle query SELECT con invalidazione su INSERT/UPDATE/DELETE della stessa tabella
- Eager loading — precaricamento delle relazioni per evitare il problema N+1
-
Soft deletes — eliminazione logica con
deleted_ate scope automatici
Ogni feature dell'ORM e stata implementata partendo dalla domanda: "Cosa sta realmente succedendo sotto il cofano?". La risposta, in ogni caso, e stata più semplice e più illuminante del previsto. La magia, una volta compresa, e solo buon design.
405 commit come diario di bordo
In 18 mesi, Soft PHP MVC ha accumulato oltre 405 commit. Ognuno racconta una decisione: perché un singleton invece di un container DI, perché file-based cache invece di Redis, perché attributi PHP 8.4 invece di annotazioni YAML. Queste decisioni non sono le "migliori" in assoluto — sono le migliori per questo contesto, con questi vincoli, in questo momento.
E questo e il cuore del paradosso: costruire un framework custom ti rende un utilizzatore migliore dei framework esistenti. Dopo aver scritto un ORM, capisci Eloquent a un livello diverso. Dopo aver implementato le migrazioni, sai esattamente cosa fa artisan migrate sotto il cofano. La comprensione profonda non si ottiene leggendo la documentazione — si ottiene facendo le stesse scelte e vivendo le stesse conseguenze.
Il valore pedagogico delle decisioni sbagliate
Non tutti i 405 commit contengono decisioni brillanti. Alcuni contengono scelte che sono state riviste, approcci abbandonati, refactoring di codice scritto male la settimana prima. E questo e parte del valore: le decisioni sbagliate insegnano più di quelle giuste. Quando implementi un pattern che non scala, capisci visceralmente perché quel pattern non funziona — molto meglio che leggere un articolo che te lo spiega in astratto.
Il portfolio come prova ontologica
Sant'Anselmo provava l'esistenza di Dio ragionando sull'idea stessa di perfezione. Nel mondo dello sviluppo, un framework custom e una prova ontologica di competenza: non dice "so usare gli strumenti", dice "so costruire gli strumenti". E la differenza tra un musicista che suona bene e un liutaio che costruisce lo strumento — entrambi hanno valore, ma dimostrano capacità diverse.
813 test, 26 comandi CLI, un ORM con query caching, migrazioni su quattro database, crittografia con libsodium, CSRF firmato con HMAC, sessioni sicure con flash data e timeout — non sono feature che "servono" per un portfolio personale. Sono la dimostrazione che ogni componente e stato compreso, progettato e implementato consapevolmente.
Cosa dice un framework custom a un recruiter
In un mercato dove ogni sviluppatore PHP elenca "Laravel" nel curriculum, un framework custom si distingue. Non perché sia migliore di Laravel — non lo e, e non pretende di esserlo. Si distingue perché dimostra capacità che l'uso di Laravel non può dimostrare:
- Architettura — saper progettare un sistema da zero, non solo usarne uno esistente
- Comprensione dei fondamentali — sapere come funziona un ORM, non solo come si usa
- Problem solving — aver affrontato e risolto problemi che in Laravel sono risolti "gratis"
- Disciplina — 813 test, pre-push checks, refactoring continuo: abitudini, non solo competenze
Il trade-off consapevole
Non c'e nulla di eroico nel reinventare la ruota se la ruota ti serve per guidare. Il trade-off e chiaro e va accettato senza romanticismi: meno ecosistema, meno pacchetti pronti, meno Stack Overflow answers, meno colleghi che conoscono il tuo framework. In cambio: comprensione totale, assenza di magia, codebase leggera, liberta di sperimentare.
Il filosofo Kierkegaard scrisse che la vita si comprende all'indietro, ma si vive in avanti. Un framework custom si giustifica all'indietro — guardando tutto cio che hai imparato costruendolo. Si vive in avanti — commit dopo commit, feature dopo feature, bug dopo bug. E forse e proprio questa la sua ragione d'essere: non il prodotto finale, ma il percorso che ti ha portato fin qui.
Il paradosso si risolve quando smetti di vedere il framework custom come un'alternativa a Laravel e inizi a vederlo come un complemento. Laravel e lo strumento per i clienti, dove la produttività conta. Soft PHP MVC e il laboratorio dove si impara, si sperimenta, si sbaglia in sicurezza. Due progetti con scopi diversi, che si alimentano a vicenda. L'uno rende migliore l'altro.
