O verdadeiro motivo para evitar dívidas técnicas

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.

Em Resumo
  • O problema

    O acúmulo de dívidas técnicas, muitas delas contraídas sem necessidade, por preciosismo ou amadorismo, faz com que os times técnicos precisem cada vez de mais tempo para entregar cada vez menos valor para o negócio.
  • O insight

    Evidenciar a importância da redução dos prazos de entrega de features para negócio, sem comprometer qualidade, evitando o acúmulo de dívidas técnicas.
  • Os benefícios

    Código com menos dívidas técnicas é mais fácil de entender, manter e evoluir. Logo, permite que mais valor seja entregue ao negócio em prazos menores.
2 Comentários
  1. Mauro Leal

    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

  2. Felipe Almeida

    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.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *