Quando você deixa de escolher bons nomes para namespaces, classes, métodos ou variáveis, você faz com que o programador que precisará dar manutenção nesse código (talvez, você mesmo) precise de mais tempo para o entender.
Criando classes e métodos grandes, pouco coesos, você, além de deixar o código mais difícil de entender, torna o versionamento mais complexo.
Adotando uma estratégia ruim para escrever códigos pequenos, você torna seu código muito mais difícil de depurar. O cursor fica, literalmente, “saltando” de um arquivo para outro até que ninguém consiga entender o fluxo de execução.
Implementando “todos os padrões do mundo” só porque os conhece, sem boas justificativas e sem conexão com o domínio, você dá a entender que esta seria a forma certa. Assim, influencia programadores menos experientes embora, talvez, não menos competentes, a fazer o mesmo, perpetuando e proliferando complexidade desnecessária.
Ao ignorar padrões, técnicas e algoritmos consolidados para resolver determinadas categorias de problemas, escrevendo código de maneira ingênua, você aumenta as chances de que o sistema seja menos performático ou muito menos seguro do que deveria.
Quando você escreve código acoplado, você torna o código mais difícil de testar, seja de forma automática ou manual.
Toda vez que você deixa de escrever um teste automatizado porque o código que está alterando não é testável, você está o tornando ainda menos testável.Quando você adiciona camadas em seu sistema que fazem nada além de “repassar a mensagem”, você está criando código a mais para entender e manter sem agregar valor algum.
Quando você “programa do jeito certo” sem entender as motivações para as técnicas que está aplicando, provavelmente está o fazendo pelos motivos errados.Nos parágrafos anteriores, relacionamos apenas alguns dos tipos de dívidas técnicas mais comuns. Alguns tem o mérito de, pelo menos, reduzir o tempo para desenvolver uma feature. Outros, nem isso.
Quanto mais dívidas técnicas um código tiver, mais tempo será necessário para entender, alterar, testar e entregar. Logo, menor será a quantidade de features que o time consegue implementar. Aliás, é importante ressaltar que qualquer “boa prática” que impacte negativamente o velocity do time é, na verdade, uma dívida técnica.
Bons programadores estudam para entregar código mais performático, escalável e tolerante a falhas. Os melhores programadores também se empenham para gerar mais valor em prazos mais curtos.
Com minha experiência nos projetos percebi que, além de tornar a evolução mais difícil, o acúmulo de débitos faz o time ter uma performance fictícia por um determinado tempo. Por exemplo, entrega 40 pontos por Sprint. Depois fica difícil justificar para os stakeholders porque a performance está diminuindo ou porque passar a planejar apenas 30 pontos porque precisa de tempo para resolver débitos
Muitos começam a desenvolver sem saber o porque aquele software existe ou precisa existir. Só se liga no o que vai fazer e talvez o como. Falha no recrutamento? Talvez… Mas eu penso que é mais comum do que parece. Esse é o ponto mais crítico, mas vamos supor que o time saiba o porque, temos outra questão que é o nível de customização, eu preciso criar novas entidades/colunas ou foi estruturado pro comportamento mudar a nível de registro? Estamos falando de gravar um JSON e a tela mudar totalmente de comportamento… Isso faz com que as mudanças sejam rápidas e gere valor para o negócio, se o time sabe o pq e sabe o como, o que elas vão fazer será algo parecido com o que eu disse para que as alteraçōes sejam as mínimas possíveis.