Projetar antes de implementar
Se eu pudesse dizer uma coisa só sobre como eu trabalho, seria esta: penso o problema inteiro antes de escrever a primeira linha. Com o que sustenta cada afirmação ao lado.
| O que eu afirmo | O que sustenta |
|---|---|
| Especifico antes de implementar | um em cada cinco repositórios tem especificação numerada versionada junto ao código |
| Busco o padrão de mercado | tratamento de erro segue RFC 9457; a suíte segue Clean Architecture canônica |
| Trato robustez como critério, não consequência | xUnit em 66% dos repositórios; validação declarativa em 54% |
| Projeto para evoluir | 5 abstrações extraídas e generalizadas de sistemas reais, publicadas como pacote |
| Entendo o todo antes da parte | 319 aplicações e ~3.200 integrações mapeadas antes de decidir sobre elas |
Como isso funciona na prática
A especificação vem numerada e versionada com o código: o problema, a pesquisa do que já existe, o plano e a lista de tarefas. Não é documento cerimonial. É onde as decisões difíceis são tomadas enquanto ainda são baratas de mudar.
O que eu procuro nessa fase:
- Qual é o problema real, não o pedido. O pedido costuma já vir com uma solução embutida, e quase sempre não é a melhor
- O que já existe que resolve isso, no parque, no ecossistema ou como padrão publicado
- Onde a coisa vai doer em dois anos: o ponto que vai virar dívida, e se dá para evitar agora barato
- O que fica de fora, explicitamente
Por que não é lentidão
A objeção óbvia é que isso atrasa. Na minha experiência inverte, porque o tempo gasto em especificação volta em decisão que não precisa ser refeita. O monitoramento industrial é o exemplo: tratar operação offline como requisito, e não como recurso a acrescentar depois, mudou a arquitetura inteira do cliente. Descoberta na fase de projeto, custou uma conversa. Descoberta depois, teria custado a reescrita.
Ver também
As cinco decisões em Decisões/ são a demonstração concreta disto. Cada uma registra as
alternativas consideradas, por que foram rejeitadas, o trade-off aceito e como a decisão envelheceu.
ADR 1 — Política de risco em dado, não em código · ADR 2 — Notificação acumulada em vez de exceção · ADR 3 — Operação offline como requisito de arquitetura · ADR 4 — Uma implementação por canal, não um motor parametrizado · ADR 5 — Estado derivado, nunca atribuído
Como eu trabalho · Engenharia com IA · Documentação e mapeamento de sistemas · Qualidade e engenharia de contexto