🏷️ Engenharia de Software

Se você chegou até aqui com a aplicação da Parte 2 no ar, então já tem um servidor que sobe, troca de perfil e responde o /api/status. O que você não tem ainda é domínio. Não existe tarefa, não existe estado, não existe nada para persistir. A aplicação é um esqueleto saudável, mas ainda é um esqueleto.

Se você trabalha com desenvolvimento ou infraestrutura há tempo suficiente, certamente guarda na memória um sistema que te dava calafrios. Aquele monstro sagrado da empresa que ninguém tinha coragem de reiniciar numa sexta-feira. Aquele software cujo processo de deploy parecia um ritual de invocação medieval, com quinze passos manuais, três rezas e uma oferenda aos deuses do hipervisor.

No primeiro post da série, montamos nossa bancada de trabalho com Debian Trixie, SDKMAN travando o JDK 26 e o VS Codium livre de telemetrias. Com as ferramentas no lugar, o impulso natural da maioria dos tutoriais é abrir o editor e sair cuspindo código de negócio desordenado. Mas se queremos construir uma aplicação que sobreviva ao mundo real, precisamos falar antes sobre como uma aplicação nasce e como ela lida com seus ambientes.

A forma como descrevemos o desenvolvimento de software diz muito sobre como escolhemos construí-lo. Por muito tempo, tentamos nos convencer de que éramos engenheiros erguendo estruturas imutáveis de concreto e aço, seguindo plantas rígidas e previsíveis. Mas quem vive o dia a dia do código sabe que essa caixa de ferramentas não dá conta da realidade: somos, na verdade, algo muito diferente disso.

Se tivéssemos que apontar uma única característica que define como é programar em Elixir ¹, seria o pattern matching. Esse recurso da linguagem vai muito além da atribuição tradicional que conhecemos em outras linguagens: ele molda a forma como pensamos e estruturamos o código.