Princípios de Engenharia

conquistados, não adotados

Cada princípio tem uma origem e pelo menos um lugar onde foi aplicado de novo. Abra um.

explicação
Quando dois caminhos de código podem produzir o mesmo valor derivado, eles eventualmente discordam, porque retries, reordenação e falhas parciais garantem isso. Consistência não se alcança sincronizando computações; se alcança tornando todas menos uma impossíveis.
origem
Nascido ao debugar uma métrica voltada ao cliente que dois serviços computavam de forma independente na Dynamox.
onde apliquei de novo
Reaplicado no design de sincronização de workspace: um dono por tipo de entidade, todo o resto converge.
explicação
Padrões não falham por estarem errados; falham porque ignorá-los dá menos trabalho. Um design system precisa vencer soluções locais em esforço, então importar o componente tem que ser melhor do que escrever um.
origem
Construir o primeiro Design System da AQTech como estagiária sem autoridade para mandar em nada.
onde apliquei de novo
A mesma lógica conduziu a adoção de observabilidade na Dynamox: ownership de triagem desenhado para ser mais leve do que ignorar erros.
explicação
Um design cuja corretude decorre da estrutura (idempotência, ownership único, reversibilidade) não precisa de vigilância. Um design engenhoso que é correto sob suposições decai conforme as suposições decaem.
origem
Contrastando a abordagem do job de reconciliação (engenhosa, com vazamentos) com o redesign de dono único (enfadonho, hermético).
onde apliquei de novo
Correções de dados de produção: scripts reversíveis em três fases em vez de UPDATEs pontuais cuidadosos.
explicação
Uma biblioteca economiza semanas agora e custa indefinidamente, através de upgrades, lacunas no comportamento central, e o roadmap de outra pessoa. Quanto mais perto um componente estiver do coração do seu domínio, mais forte o argumento para ser dono dele.
origem
Avaliar bibliotecas de seletor em árvore na AQTech e descobrir que todo candidato falhava em comportamento central.
onde apliquei de novo
O mesmo cálculo moldou o serviço de analytics: seja dona do caminho de query, alugue o motor de armazenamento.
explicação
Sincronização significa manter concordância entre cópias para sempre. Recomputação significa derivar a verdade da fonte sob demanda. A segunda é mais lenta por operação e drasticamente mais barata por ano.
origem
O design de sinal de desatualização: serviços sinalizam 'isso pode ter mudado' em vez de mandar valores computados por aí.
onde apliquei de novo
Guia toda decisão de cache e projeção que tomo desde então.
explicação
Um padrão mandado é seguido enquanto alguém observa. Um padrão que vence pelo mérito, provado em telas reais e mais barato de seguir do que de pular, sobrevive à saída de sua autora. O meu sobreviveu.
origem
Os padrões do Design System da AQTech continuarem em uso depois que saí da empresa.
onde apliquei de novo
Como introduzo toda prática desde então: evidência primeiro, adoção segundo, mandato nunca.
explicação
Review comprime anos do julgamento de outra pessoa em comentários sobre o seu próprio trabalho. Levar feedback de review a sério, e depois dar feedback a sério, é o ciclo de aprendizado de maior densidade que conheço.
origem
Trabalho freelance sob um engenheiro experiente que tratava todo PR como um momento de ensino.
onde apliquei de novo
Como referência frontend na AQTech, review virou como eu ensinava o Design System.
explicação
Docs de implementação respondem 'o que é isso'. Docs de decisão respondem 'por que é isso e não a alternativa', a única pergunta que importa seis meses depois. Contexto, restrições, alternativas, trade-offs.
origem
Escrever a avaliação OLTP vs OLAP como um documento e ver isso encerrar debates antes que começassem.
onde apliquei de novo
Toda essa base de conhecimento é o princípio aplicado a uma carreira.
explicação
"Todo caminho de leitura subtrai X" é um cheiro de posicionamento, não um requisito. Se um estado pode ser aplicado uma vez na fronteira de escrita, todo consumidor existente se torna correto sem mudar, e todo consumidor futuro se torna correto sem saber que a regra existe. N compensações é o mesmo bug escrito N vezes.
origem
Um estado de "ativo hibernado" válido para toda a plataforma especificado como uma regra de exclusão para oito caminhos de leitura diferentes (contadores, payload do app, relatórios, impressão, adherence) quando poderia ser aplicado uma única vez removendo o ativo do escopo da rota.
onde apliquei de novo
A mesma pergunta fechou um join de warehouse por requisição: a hierarquia estava sendo resolvida em cada leitura quando o pipeline poderia materializá-la uma vez.
explicação
Checagens de divergência comparam duas derivações e passam quando concordam, e NULL concorda com NULL. Integridade precisa de ao menos um invariante de completude independente, verificado contra uma fonte diferente, ou uma classe inteira de dados ausentes permanece invisível enquanto o dashboard continua verde.
origem
Uma checagem de consistência de pipeline que comparava bruto contra curado usando o mesmo campo de evento, reportando concordância perfeita enquanto 79% das linhas estavam sem uma coluna derivada e 10% dos registros estavam sendo descartados por completo pela semântica de NULL do SQL.
onde apliquei de novo
Agora uma pergunta permanente sobre qualquer coluna derivada: o que garante que ela está populada, e essa garantia lê de outro lugar?