ENGENHARIA / FUNDAÇÕES INVISÍVEIS / FABRÍCIO CASTRO
Antes de construir para cima,
é preciso cavar para baixo.
Uma tela pode parecer simples. Por trás dela existem pessoas, decisões, regras, dados, testes e aprendizado. A fundação de um arranha-céu serve apenas de parábola para o trabalho invisível: aqui, o objeto de estudo é a engenharia de software, com suas escolhas, restrições, falhas e responsabilidades.
01 / O QUE NÃO APARECE NA TELA
O código é visível. A engenharia o sustenta.
A comparação com um arranha-céu ajuda a compreender por que o trabalho decisivo nem sempre é visível, mas não define o método do desenvolvimento. Em software, investigar necessidades, confrontar regras, identificar riscos, modelar dados, verificar contratos e aprender com testes pode ser mais importante do que a aparência inicial de uma tela. As atividades não formam uma sequência rígida: cada projeto é singular e exige iterações.
Um botão, um relatório, uma experiência.
Quem usa o produto observa a tarefa resolvida: por exemplo, aprovar uma compra. Não precisa conhecer transações, políticas de acesso, índices de banco ou filas para realizá-la. A simplicidade da interface pode ser fruto de muitas decisões invisíveis.
Critério: a pessoa entende a tarefa, recebe retorno adequado e consegue lidar com erro, carregamento e permissão negada.
Regras, responsabilidades, dados e evidências.
Antes de prometer uma solução, investigamos se o problema exige software, quais regras não podem ser violadas, quem pode decidir, como o dado será protegido e como reconhecer uma falha em produção. Não é burocracia por princípio: é redução de incerteza orientada ao risco.
Limite: nem toda ideia é tecnicamente, economicamente ou legalmente viável. Descobrir que não construir é a melhor decisão também pode ser um bom resultado.
02 / DIAGNÓSTICO, CONTEXTO E ALTERNATIVAS
Um pedido descreve um desejo. Não necessariamente o problema.
Considere uma organização fictícia que pede: “Precisamos de um botão para aprovar compras mais rápido”. A demanda parece pequena, mas pode esconder decisões por mensagem, alçadas financeiras indefinidas, ausências, dados duplicados e integrações frágeis. Este é um cenário didático, não um relato de cliente ou software implantado.
Quem perde tempo, onde e por quê?
Conversar com solicitantes, gestores, financeiro, suporte e segurança; observar o processo atual (AS-IS); examinar exceções; distinguir sintomas de causas. Uma tela nova não corrige, sozinha, uma política contraditória.
Evidência: mapa do processo, partes interessadas, hipóteses, decisões, restrições e riscos.
Construir, configurar ou corrigir o processo?
Antes de escolher Next.js, NestJS, filas ou banco, comparar automação da ferramenta existente, ajuste operacional e desenvolvimento específico. Tempo, custo, manutenção, privacidade e suporte fazem parte da decisão.
Evidência: alternativas, premissas, riscos e decisão registrada, passível de revisão.
03 / RESPONSABILIDADES COMPARTILHADAS
Um desenvolvedor escreve código. O produto depende de muitas vozes.
Software não nasce exclusivamente do conhecimento de quem programa. Pessoas que utilizam, conhecem o negócio, definem objetivos, cuidam da experiência, avaliam riscos e operam a solução influenciam requisitos e decisões. Não se trata de exigir uma grande equipe: é reconhecer que toda implementação depende de informações e validações além do editor de código.
Quem conhece o problema precisa participar.
Usuários: revelam tarefas, obstáculos e consequências. Especialistas do negócio: validam regras e exceções. Produto e design: ajudam a priorizar e investigar a experiência. Qualidade, segurança e operação: confrontam falhas, riscos, acessos e recuperação. Cada participação ocorre conforme necessidade e contexto, não por cerimônia.
Evidência possível: entrevistas, mapeamento de responsáveis, decisões de escopo, protótipos avaliados, testes de aceitação e registro de feedback divergente.
Uma pessoa pode programar só, mas não saber tudo.
Em um projeto individual, a mesma pessoa pode descobrir, desenhar, desenvolver, testar e publicar. Ainda assim, precisa consultar documentação, bibliotecas e padrões de terceiros, observar quem vai utilizar, validar suposições, revisar segurança e buscar feedback. Quando não há cliente, pesquisar necessidades reais e ouvir a comunidade continua sendo útil.
Limite: delegar não elimina responsabilidade; trabalhar sozinho tampouco significa que todas as disciplinas estejam dominadas. Registrar riscos não resolvidos é mais honesto do que prometer domínio universal.
04 / DA NECESSIDADE À PROVA
Requisitos não são uma lista de botões e telas.
Um requisito funcional (RF) descreve o comportamento esperado. Um requisito não funcional (RNF) define qualidade ou restrição, como segurança e disponibilidade. Uma regra de negócio representa uma política do processo e deve ser confirmada por quem responde por ela.
EXEMPLO HIPOTÉTICO / APROVAÇÃO
Um clique pode ter quatro decisões escondidas.
O pedido possui valor, responsável, estado e histórico. A decisão deve considerar alçada, segregação entre solicitante e aprovador, concorrência e falhas de integração. O domínio é discutido antes da implementação.
RF-01 Permitir aprovar somente pedidos pendentes por agente autorizado.
RNF-01 Impedir acesso entre empresas e registrar autor, momento e resultado.
REGRA Quem solicitou não pode aprovar o próprio pedido, caso essa seja a política validada.
EXCEÇÃO Duas decisões simultâneas não podem criar versões finais incompatíveis.
PROVA Critérios de aceite, testes negativos, API e histórico da decisão.
Um critério de aceite ilustrativo, compreensível também por quem não programa:
Dado um pedido pendente e duas pessoas autorizadas Quando ambas tentam aprovar simultaneamente Então apenas uma transição final é confirmada E a outra tentativa recebe um resultado coerente E o histórico registra o desfecho sem duplicidade
Um teste como esse não demonstra automaticamente que o sistema é seguro. Políticas de acesso, concorrência no banco, idempotência na integração e falhas de rede exigem verificações adicionais.
ATLAS / REQUISITOS
Do pedido incerto ao requisito verificável.
O capítulo de requisitos aprofunda entrevistas, RF/RNF, casos de uso, exceções, rastreabilidade e artefatos para revisar decisões.
05 / ARQUITETURA, EXPERIÊNCIA E OPERAÇÃO
Projetar é tornar as consequências visíveis.
O esboço ajuda a descobrir tarefas; o protótipo valida hipóteses sem exigir o produto inteiro. Arquitetura organiza responsabilidades e trade-offs. Nenhum diagrama ou padrão substitui as regras de negócio, os testes e a operação real.
- 01Esboço e protótipo navegável
Desenhar jornada, estados vazio, carregando, erro e permissão negada; validar com pessoas e teclado. Evidência: fluxo e protótipo revisados.
- 02Modelagem e contratos
Definir domínio, transições, dados, API, erros e limites entre módulos. Evidência: modelo, contrato e registro de decisão (ADR).
- 03Segurança e integridade
Autorização no servidor, dados pessoais, segregação de funções, concorrência, transações e rastreabilidade. Evidência: matriz de acesso e testes adversariais.
- 04Entrega, observabilidade e recuperação
Definir como testar, publicar, reconhecer falhas, reprocessar eventos, reverter mudanças e restaurar dados. Evidência: CI executada, logs, smoke e runbook.
ATLAS / ARQUITETURA
Arquitetura boa é uma escolha que pode ser explicada.
Explore domínio, monólito modular, serviços distribuídos, ADR, C4, consistência, testes e os custos de operar decisões.
06 / PERSISTÊNCIA COM MÉTODO
Persistir não é repetir a tentativa. É aprender com o que falhou.
Uma falha deve mudar nossa compreensão. Formular hipótese, reproduzir sintoma, isolar causas, corrigir a menor unidade segura, verificar cenários positivos e negativos e observar o resultado é mais útil do que insistir no mesmo caminho. Às vezes é necessário pausar, reverter ou abandonar uma alternativa.
Dois gestores aprovam o mesmo pedido.
Falha: duas requisições leem “pendente” e gravam decisões. Investigação: reproduzir simultaneidade e revisar transação. Correção possível: atualização condicional, versão ou bloqueio adequado ao banco. Prova: teste concorrente real e uma única transição válida.
A técnica depende de requisitos e banco. Verificar também resposta de conflito, retry e efeitos colaterais.
O ERP responde com timeout. A compra foi enviada?
Falha: uma resposta se perde depois de o destino processar a requisição; reenviar pode duplicar. Investigação: correlacionar tentativas com identificador estável. Correção possível: idempotência, reconciliação, outbox e retry controlado. Prova: repetir a requisição sem duplicar operação financeira.
Retry não é prova de sucesso. Sem confirmação, manter estado indeterminado e reconciliar.
07 / DESAFIOS E EVOLUÇÃO CONTÍNUA
Não conhecer a solução ainda não encerra a engenharia.
Cada projeto combina domínio, equipe, tecnologias, riscos, tempo e orçamento de modo particular. Não domino todas as linguagens e ferramentas; por isso estudo experiências anteriores, padrões, pesquisas e casos de falha para construir repertório. Esse conhecimento não elimina o desconhecido nem vira uma receita: ajuda a identificar riscos, formular hipóteses e escolher o que verificar. A mesma estratégia que funcionou em um sistema pode ser inadequada em outro.
O que sabemos, o que supomos e o que falta provar?
Separar fatos de hipóteses, consultar documentação primária, criar uma prova de conceito pequena, medir o comportamento em ambiente seguro e registrar alternativas. Um protótipo pode revelar que uma biblioteca, arquitetura ou integração não atende às restrições. Aprender cedo evita consolidar um erro.
Exemplo fictício: antes de adotar filas e microsserviços, reproduzir o risco de duplicação de um webhook, medir a necessidade real e comparar uma transação local com uma solução distribuída.
Falhar com método amplia repertório.
Uma investigação malsucedida pode produzir conhecimento útil: o que não funciona, por quê e em quais limites. Pedir revisão, reduzir escopo, descartar um experimento ou mudar arquitetura também são decisões maduras. Persistência sem critério pode desperdiçar recursos ou ampliar riscos.
Evidência: hipótese, experimento, resultado, aprendizado, decisão revisada e próximo passo. O crescimento profissional é contínuo, mas não autoriza prometer solução para qualquer problema.
Dividir o sistema em módulos não é dividir as telas.
David Parnas mostrou que a escolha das fronteiras de um módulo afeta sua capacidade de evoluir. O princípio ajuda a proteger decisões que podem mudar, mas exige compreender acoplamento, regras e contratos antes de desenhar componentes.
Aplicação: se regras de aprovação mudam sem que o cadastro de produtos mude, investigar limites de responsabilidade. Fonte: trabalho de Parnas. Não é prova de implementação neste portfólio.
Começar com monólito ou microsserviços?
Martin Fowler reuniu argumentos a favor do monólito inicial. Stefan Tilkov publicou a posição contrária para situações em que separação e autonomia são prioridades. O desacordo é útil: arquitetura não se resolve repetindo um conselho sem conhecer equipe, domínio, operação e custo.
Verificar: fronteiras estáveis, necessidade de deploy independente, observabilidade e capacidade de operar serviços. Fowler · Tilkov. Referências de estudo, não receitas.
CONHECIMENTO / APLICAÇÃO E ESTUDO
Dominar tudo não é a meta. Aprender com critério é.
Explore como as competências técnicas se relacionam a entregas, estudo, experimentos e responsabilidades, sem confundir tecnologias conhecidas com experiência comprovada em produção.
08 / INCIDENTES REAIS, LIÇÕES DOCUMENTADAS
Algumas falhas podem ser recuperadas. Outras não.
Casos publicados pelas organizações responsáveis, independentes deste portfólio. Não representam trabalhos do autor nem métricas de cliente.
Um contrato de unidades que não foi verificado.
A investigação NASA/JPL identificou incompatibilidade entre unidades inglesas e métricas em dados críticos de navegação. A missão foi perdida; não houve recuperação da nave. A lição é verificar a semântica dos contratos entre equipes, unidades e validações independentes antes que a falha se propague.
Aplicação: tipos, unidades, formatos e testes de contrato entre serviços. Fonte NASA/JPL
Restaurar o serviço não significou recuperar todos os dados.
Uma operação equivocada afetou o banco primário do GitLab.com. A equipe restaurou o serviço a partir de snapshot, enfrentando limitações no processo; parte das alterações de dados se perdeu. O postmortem mostra por que backup sem restauração testada não garante continuidade.
Aplicação: RPO, RTO, ensaio de restauração, acessos privilegiados e runbooks. Postmortem GitLab
09 / PROGRESSO SEM MÉTRICAS INVENTADAS
O que não aparece na tela também deixa evidência.
Cada artefato deve reduzir incerteza, registrar decisão ou permitir verificação reproduzível. Um produto pode evoluir em incrementos pequenos, sem antecipar toda uma infraestrutura empresarial.
- 01Problema e hipótese
Quem sofre impacto e o que se espera melhorar? Evidência: mapa AS-IS, responsáveis e objetivo acordado.
- 02Regras e critérios
RF, RNF, exceções, permissões e exemplos positivos e negativos. Evidência: aceites rastreáveis.
- 03Projeto e protótipo
Jornada, fluxos, estados de erro, alternativas e decisões técnicas. Evidência: protótipo, modelo e ADR.
- 04Implementação e verificação
Commit/PR, testes sobre o SHA, revisão, segurança e limites conhecidos. Evidência: logs, cenários e resultados reproduzíveis.
- 05Entrega e aprendizado
Deploy, smoke, alertas, feedback, incidentes, revisão e reversão segura. Evidência: estado da produção e ações preventivas testadas.
Uma solução pequena pode demandar poucos artefatos; uma solução crítica, muitos. O processo deve ser proporcional ao risco, domínio, equipe e responsabilidade. Mais documentação, isoladamente, não prova qualidade.
10 / REFERÊNCIAS E CONTINUIDADE
Aprender com fontes. Decidir com contexto.
As referências fundamentam conceitos e fatos citados, não certificam esta aplicação. Elas conectam a reflexão às disciplinas técnicas do Atlas.
ISO/IEC/IEEE 29148:2018
Engenharia de requisitos ao longo do ciclo de vida; a aplicação deve ser proporcional ao contexto.
Consultar ISOGoogle SRE — postmortem
Investigação sem culpabilização, causas, ações preventivas e revisão de aprendizados.
Ler SRE BookIdempotent Receiver
Como identificar requisições repetidas e reduzir efeitos duplicados após timeout.
Consultar padrãoPRÓXIMO PASSO / ATLAS
Da analogia ao estudo técnico.
Requisitos, domínio, arquitetura, dados, testes e observabilidade possuem capítulos próprios. Não é preciso dominar todas as ferramentas para começar: é preciso escolher o primeiro incremento verificável.