A decisão de arquitectura cara costuma ser uma reescrita de que ninguém precisava. Uma loja que já recebe encomendas em WordPress não fica mais segura porque a página inicial muda para uma framework mais nova. Um produto que é sobretudo uma API e um quadro não fica mais claro porque o forcei no mesmo tema da loja. Escolho a stack que já segura o comportamento, e mantenho a fronteira nítida o bastante para uma pessoa ainda conseguir ver para o outro lado.
Fica onde o negócio já vive
Se a receita é um checkout WooCommerce, o trabalho pertence ao lado desse checkout: o tema, os plugins em que realmente confio, o servidor, o correio, as cópias. Mudar o catálogo para um frontend à parte para a stack parecer actual é um projecto. Não é, por si, uma correcção de um código promocional ou de um webhook perdido. Tenho mais paciência para uma mudança simples em PHP que sai esta semana do que para uma migração cujo ganho é estético.
O Laravel ganha o seu lugar quando a coisa é uma aplicação com as suas próprias regras, as suas próprias filas e a sua própria administração, e não deve ser dobrada em páginas. Um pipeline de conteúdo com um tecto de gasto e um passo de aprovação humana é esse tipo de aplicação. Um site de marketing não é.
| O sistema já é | Recorro a | Não recorro a |
|---|---|---|
| Uma loja que recebe encomendas | WordPress, WooCommerce e o servidor à volta | Uma reescrita para a página inicial ser outro framework |
| Uma aplicação com filas e um admin | Laravel, ou Nest se o resto desse produto já é TypeScript | Um monte de plugins a fazer de conta que são um produto |
| Uma interface tipada partilhada por um quadro e uma API | TypeScript, de ponta a ponta | Uma segunda linguagem só para os botões |
| Recuperação, pontuação, um serviço pequeno sobre documentos | Python | O runtime PHP da loja, por lealdade |
Uma linguagem ao longo de um produto, não de uma carreira
Dentro de um produto quero uma língua principal, para que uma mudança na API e uma mudança no ecrã sejam a mesma revisão. Ao longo do meu trabalho não finjo que tudo seja uma só língua. PHP, TypeScript e Python estão todos em produção aqui, de propósito. O erro é misturá-los dentro de um só caminho de pedido porque cada camada foi a preferência de alguém.
PostgreSQL quando os dados têm relações e quero que a base as faça cumprir. MySQL quando é isso que a loja já corre e mudá-lo não é a tarefa. Redis para uma fila ou uma cache, não como segunda fonte de verdade. Docker e um nginx aborrecido quando o deploy tem de ser descrito, não quando me apetece aprender um orquestrador.
Uma reescrita tem de nomear o incidente que remove
Peço uma frase antes de uma framework nova entrar no plano. Que incidente, que a stack actual não consegue fechar, desaparece por causa da mudança? Se a frase for sobre gosto, recrutamento ou uma palestra de conferência, a mudança espera. Se a frase for “o plugin de checkout não consegue exprimir esta regra de preço, e já o remendei duas vezes”, essa é uma frase real, e mesmo assim procuro um remendo mais pequeno antes de uma montra nova. O remendo mais pequeno costuma estar lá.
O mesmo teste vale para um serviço que me tenta acrescentar ao lado da loja. Uma fila justifica-se quando um pedido tem de sobreviver a uma nova tentativa. Um frontend à parte justifica-se quando dois clientes, não um programador, precisam da mesma API. Uma base nova quase nunca se justifica no mesmo trimestre que um problema de fiabilidade. Os dados que já tens são o sistema. Mudá-los é um projecto próprio, com o seu próprio inventário, e não corrige o código promocional.
Consigo segurar uma loja e um serviço ao lado porque se encontram numa fronteira documentada: um webhook, uma fila, uma tabela. Não consigo segurar um sistema cujas fronteiras são “pergunta a quem construiu essa parte”. Essa pessoa tenho de ser eu, também depois do lançamento. Por isso uma ferramenta nova tem de pagar renda. Se não tira uma passagem de mão ou uma classe de incidente, é gosto, e o gosto pode esperar.
Escolhe a stack que mantém o próximo incidente dentro de uma só cabeça. A novidade tem de vencer isso, não o contrário.
