La decisione di architettura costosa di solito è una riscrittura di cui nessuno aveva bisogno. Un negozio che già prende ordini su WordPress non diventa più sicuro perché la homepage passa a un framework più nuovo. Un prodotto che è soprattutto un’API e una bacheca non diventa più chiaro perché l’ho forzato nello stesso tema del negozio. Scelgo lo stack che già regge il comportamento, e tengo il bordo abbastanza netto perché una persona possa ancora vedere dall’altra parte.
Resta dove il business vive già
Se il ricavo è un checkout WooCommerce, il lavoro sta accanto a quel checkout: il tema, i plugin di cui mi fido davvero, il server, la posta, i backup. Spostare il catalogo in un frontend separato perché lo stack sembri attuale è un progetto. Non è, da solo, una correzione per un codice promozionale o un webhook perso. Ho più pazienza per un cambiamento PHP semplice che esce questa settimana che per una migrazione il cui guadagno è estetico.
Laravel si guadagna il posto quando la cosa è un’applicazione, con le sue regole, le sue code e la sua amministrazione, e non va piegata in pagine. Una pipeline di contenuti con un tetto di spesa e un passo di approvazione umana è quel tipo di applicazione. Un sito di marketing no.
| Il sistema è già | Prendo | Non prendo |
|---|---|---|
| Un negozio che prende ordini | WordPress, WooCommerce e il server intorno | Una riscrittura perché la home sia un altro framework |
| Un’applicazione con code e un admin | Laravel, o Nest se il resto di quel prodotto è già TypeScript | Un mucchio di plugin che si spaccia per un prodotto |
| Un’interfaccia tipizzata condivisa da una lavagna e da un’API | TypeScript, da capo a fondo | Un secondo linguaggio solo per i pulsanti |
| Recupero, punteggio, un piccolo servizio sui documenti | Python | Il runtime PHP del negozio, per lealtà |
Un linguaggio su un prodotto, non su una carriera
Dentro un prodotto voglio un linguaggio principale, così un cambiamento nell’API e un cambiamento nella schermata sono la stessa revisione. Nel mio lavoro non fingo che tutto sia un solo linguaggio. PHP, TypeScript e Python sono tutti in produzione qui, di proposito. L’errore è mescolarli dentro un solo percorso di richiesta perché ogni strato era la preferenza di qualcuno.
PostgreSQL quando i dati hanno relazioni e voglio che il database le faccia rispettare. MySQL quando è quello che il negozio già esegue e spostarlo non è il compito. Redis per una coda o una cache, non come seconda fonte di verità. Docker e un nginx noioso quando il deploy va descritto, non quando mi va di imparare un orchestratore.
Una riscrittura deve nominare l’incidente che toglie
Chiedo una frase prima che un framework nuovo entri nel piano. Quale incidente, che lo stack attuale non può chiudere, sparisce per via del passaggio? Se la frase parla di gusto, di assunzioni o di un talk a una conferenza, il passaggio aspetta. Se la frase è “il plugin di checkout non può esprimere questa regola di prezzo, e l’ho già rattoppato due volte”, quella è una frase vera, e cerco ancora una pezza più piccola prima di una nuova vetrina. La pezza più piccola di solito c’è.
Lo stesso test vale per un servizio che sono tentato di aggiungere accanto al negozio. Una coda si giustifica quando una richiesta deve sopravvivere a un nuovo tentativo. Un frontend separato si giustifica quando due client, non un solo sviluppatore, hanno bisogno della stessa API. Un database nuovo non si giustifica quasi mai nello stesso trimestre di un problema di affidabilità. I dati che hai già sono il sistema. Spostarli è un progetto a sé, con il suo inventario, e non sistema il codice promozionale.
Posso tenere un negozio e un servizio a fianco perché si incontrano su un bordo documentato: un webhook, una coda, una tabella. Non posso tenere un sistema i cui bordi sono “chiedi a chi ha costruito quella parte”. Quella persona devo essere io, anche dopo il lancio. Quindi uno strumento nuovo deve pagare l’affitto. Se non toglie un passaggio di mano o una classe di incidente, è gusto, e il gusto può aspettare.
Scegli lo stack che tiene il prossimo incidente dentro una sola testa. La novità deve battere quello, non il contrario.
