Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Quando estamos lidando com sistemas complexos, é fácil ficar só na rotina de aplicar patches e atualizações sem lembrar o motivo original de cada decisão. A referência do Oliver Zehentleitner destaca um ponto que muitas equipes esquecem: manter o 'porquê' das mudanças.
No meu dia a dia, percebo que muitos problemas vêm justamente da falta de documentação ou de entender o motivo por trás de uma implementação. É aí que o conhecimento tácito vira um peso, transformando um código que poderia ser simples em um legado difícil de manter. A decisão fica mais saudável quando o time consegue medir o impacto depois.
Se a gente não consegue lembrar o motivo de uma decisão, fica difícil fazer melhorias ou até mesmo reverter mudanças sem quebrar algo importante. Por isso, acho que investir em documentação prática e em registros de decisões — mesmo que sejam rápidas — ajuda demais na hora de manter o sistema saudável. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.
A sua equipe faz algo para registrar esses porquês? Ou ainda fica no modo 'só na cabeça' mesmo?
Exato, Tiago.
Concordo, Rafael. No meu time, a maior dor é justamente quando a documentação fica pra trás e o conhecimento fica só na cabeça de um ou dois devs. Isso dá trabalho depois pra entender o motivo das mudanças.
Sim, e na minha experiência, usar comentários no código ou um arquivo de changelog com o porquê ajuda bastante. Mas é preciso disciplina pra manter atualizado.