- Dívida técnica: Este é o código que você sabe que é sub-par, mas que você decidiu escrever por boas razões e que tem um plano para corrigir. Vamos ser sinceros – praticamente qualquer código por aí se encaixa nessa descrição. Quantas equipes de desenvolvimento realmente têm um plano para pagar a dívida técnica? Não muito.
- Complexidade acidental: Fred Brooks cunhou esse termo, que descreve perfeitamente o código que não está certo e que resulta não por negligência ou habilidades ruins de codificação, mas porque ninguém entendeu o sistema e tomou más decisões. Talvez a equipe tenha escolhido uma estrutura que era muito pesada para a tarefa em questão. Talvez a equipe tenha criado abstrações desnecessárias ou tenha adicionado um recurso de uma maneira que não corresponda ao sistema. Infelizmente, esse é o tipo de coisa que não aparece até bem depois do fato.
- Apenas código ruim: A maior parte do que é chamada de dívida técnica é apenas apressada, com um código de “emergência” que nunca foi revisado ou foi encoberto porque “funcionou” e o cliente estava gritando. Band-aids para exercícios de incêndio de clientes, correções críticas de bugs que foram marcadas no fim de semana ou artefatos de desenvolvedores que trabalham sem tempo, clareza ou suporte suficientes.
Uma etiqueta bonita
O problema de chamá -lo de toda a dívida técnica é que ela coloca uma gravadora em problemas evitáveis. Nós nos damos uma desculpa para fazer a coisa errada, porque podemos dar um nome sofisticado que implica que iremos “pagar de volta” mais tarde, quando todos souberem que nunca o faremos. Quando a equipe pode usar o termo para justificar não fazer as coisas da maneira certa, você tem uma cultura em declínio.
Além disso, rotular todas as dívidas técnicas de coisas ruins pode levar a justificar decisões e práticas ruins. Pode ocultar problemas como sub-investimento em engenharia e pressão tóxica e constante de prazo.
Então, vamos parar de fazer isso. Vamos todos concordar que não podemos chamá -lo de dívida técnica, a menos que tenhamos um item de backlog para corrigi -lo. A dívida técnica real deve ter um bilhete de trabalho, um plano de correção e um prazo. Qualquer outra coisa deve ser reconhecida pelo que é: código ruim. Vamos construir uma cultura em que temos dívidas técnicas reais e onde chamamos todo o resto pelo nome certo. Vamos reservar “dívida técnica” pelo que realmente é: uma troca consciente com um plano de reembolso.
Todo o resto? Não é dívida técnica. É um código antigo simples.
