Documentação e mapeamento de sistemas

Entender um parque grande o suficiente para decidir sobre ele, e deixar esse entendimento numa forma que outra pessoa use. É a competência que sustenta a liderança técnica: não dá para responder por um parque inteiro de aplicações sem um mapa.

O que está mapeado: as aplicações, as integrações entre elas e os sistemas externos com que o parque conversa. Fora do trabalho, 5 pacotes públicos no NuGet, com 4.308 downloads.

A distinção entre contribuir e ser dono vale ser feita. Contribuir na biblioteca que trinta pessoas usam é um sinal; ser autor principal dela é outro. Os dois contam, e são coisas diferentes.

O que eu faço

• Levantar o que um parque grande de aplicações faz, com quem fala e quem depende de quem, e transformar isso em mapa navegável
• Documentar a regra de negócio que só existe no código, antes que a pessoa que a escreveu saia
• Identificar o que se repete entre serviços e extrair para biblioteca, com contrato e versão
• Publicar SDK para o consumidor do meu serviço, em vez de deixar cada time reescrever o cliente
• Escrever o padrão da casa em regra citável, para que a revisão seja objetiva
• Escrever e manter biblioteca pública para o problema que reaparece em todo serviço; ver Suíte PMQ

Por que isso é competência técnica, e não só zelo

Decisão de arquitetura em parque grande depende de saber o custo de mudar, e “posso alterar este contrato?” só tem resposta se alguém souber quem consome. Mapear é o que transforma palpite em decisão, e foi mapeando as aplicações que eu consegui responder tecnicamente por elas.

Onde apliquei

O mapa do parque · Reporte ao fabricante · Experiência · Suíte PMQ

O que eu ainda não fiz

O mapa é gerado a partir do código e do pipeline, então enxerga integração declarada. Não enxerga acoplamento por banco compartilhado que não aparece em configuração, nem combinado informal entre times. E documentação envelhece: parte das fichas já está desatualizada em relação ao que mudou depois da varredura.