Como lidar com o Débito Técnico

Se você está trabalhando em algum projeto de desenvolvimento de software e sente que não é ágil e produtivo o suficiente, pare um momento, junte sua equipe e faça a seguinte pergunta:

Como vocês se sentem com a qualidade do nosso código?

Peça para todos avaliarem o código com notas entre 1 e 5, sendo 5 "código maravilhoso, não poderia ser melhor" e 1 "socorro, este código fede". Caso você tenha somente notas entre 5 e 4 e nada abaixo disso, ignore este artigo, você está no caminho certo.

Se você tiver muitas notas altas (5 e 4) e algumas notas baixas (abaixo de 3), então você precisa entender por que as notas são tão diferentes.

  1. A diferença é em partes diferentes do código?
    Se for, qual o motivo de tamanha diferença?
  2. As notas representam a mesma parte do código?
    Tente entender muito bem o que cada um da sua equipe considera código de qualidade?

Mas se você tiver muitas notas 2 (ou abaixo) e algumas notas altas (4 e 5), sinto lhe informar, vocês sofrem sintomas de Débito Técnico.

Se você chegou até aqui é porque provavelmente o seu código não é muito bom. Mas se você está conseguindo entregar o que lhe é pedido e corrigir os bugs que aparecem, você deve estar se perguntando:

Por que devo me preocupar com isso?

Caso você seja um programador ou faça parte da equipe de produto, você deve estar lidando com um ou mais dos problemas listados abaixo:

  • Dificuldade para estimar tarefas;
  • Programadores desmotivados;
  • Bugs recorrentes;
  • Falta de confiança e atraso nas entregas;

Por que nosso código é ruim?

Ok, vamos lá. Código ruim é feito por programadores. Sinto informar mas você e/ou sua equipe estão escrevendo um código ruim. Independente das circunstâncias, são as ações dos programadores que determinam a qualidade do código.

E o primeiro passo, por mais difícil que seja, é aceitar e admitir isto.

Mas este código já estava assim quando eu cheguei. NÃO é minha culpa.

Ok, pode ser também. Mas e aí? O código está melhorando ou piorando? Avalie isso em uma escala de 1 a 5, então reavalie este artigo baseado nisto.

Qual a causa do código precário?

Bom, entendo que neste ponto você já tenha entendido o que gera código mal feito. Acredito também que já tenha passado da fase da aceitação. Agora, precisamos buscar na raiz. Por quê os programadores não estão criando um bom código?

Isto pode estar relacionado ao seguinte fato: código ruim, atrai código ruim. As pessoas tendem a se adaptar à situação que estão expostas e ao que acontece ao seu redor. Se você tem uma equipe desorganizada e um código lixo, a tendência é ter cada vez mais lixo.

Porém, a causa mais provável de seu código estar assim é a pressão. Certamente quando questionados, alguém da equipe irá dizer:

Nós não temos tempo para escrever um código bom. O que importa é estar pronto.

De onde vem essa pressão?

Vamos tentar entender de onde vem toda essa pressão. É o product owner que está pressionando? Por quê? Quem está pressionando o product owner?

A pessoa que está criando a pressão, realmente sabe que será gerado um código ruim? Ela está ciente das consequências? E mesmo assim ela continua achando que vale a pena? Eu acho que não. Questione-se:

Essa pressão realmente existe?

Na maioria dos casos, os próprios desenvolvedores, no intuito de se mostrarem produtivos, se pressionam para entregar o maior número de tarefas no menor tempo possível. Mas nós precisamos de tempo. Pergunte a sua equipe: quantos destes pontos vocês levam em consideração quando estimam uma tarefa?

  1. Fazer o código da melhor maneira possível.
  2. Escrever testes.
  3. Alguma coisa pode dar errada.
  4. Necessidade de utilizar/refatorar algum método do código legado. 😓

Se não são levados em consideração pelo menos dois pontos dessa lista, tenho uma má notícia, as coisas só vão piorar.

Hora de parar com a loucura

Bom, se você é desenvolvedor, você é responsável pelo problema. Mas se acalme, tenho boas notícias: você é o mais capaz de resolvê-lo. Aproveite a oportunidade, a hora é agora. Tome coragem, respire fundo, levante-se de sua mesa e diga para sua equipe:

Vamos parar de escrever código de merda! Agora!

Escreva isso na parede, no quadro, no vidro, no README da aplicação, onde quer que sua equipe veja isso e lute por isso. Cobre quando alguém escrever algum código sem testes, quando tentarem inserir algum lixo no seu código, seja chato. Eles irão te agradecer por isso.

Nunca mais ao código de merda

Se sua equipe continuar escrevendo um código ruim, a produtividade de vocês irá diminuir cada vez mais. Se tomarem a decisão de parar, terão uma vida profissional mais sustentável. Mas tudo nessa vida tem um custo, e a curto prazo, vocês perderão velocidade.

Basicamente isso quer dizer que vocês entregarão menos funcionalidades a curto prazo, e o product owner precisará priorizar as coisas com muito mais carinho. Quero dizer que ele vai precisar diminuir o número de tarefas que vocês farão em um sprint (ou release, ou qualquer métrica que utilizem). Ele vai ter que deixar coisas de fora.

Tenha na mente que qualidade é invisível a curto prazo, vocês terão uma dura batalha pela frente mas se vocês não se preocuparem com o código e a qualidade do que vocês escrevem, quem vai se preocupar?

Código legado

Bom, agora que vocês não escrevem mais um código ruim. Parabéns 🎉! Neste momento você parou de acumular Débito Técnico. Mas e o que ficou pra trás? Você não está aumentando sua dívida, mas ainda está devendo.

Este é o momento para tomar um decisão importante. Vocês conseguem continuar trabalhando normalmente com o código existente ou prefere acabar com todo esse débito? Bom, se você quer acabar com isso sua velocidade vai diminuir ainda mais a curto prazo, mas no longo prazo vai estar cada vez mais rápido.

Existem diversas maneiras de lidar com isso, tudo depende de quanto tempo vocês têm e quantas tarefas vocês podem deixar de entregar. Caso sua equipe faça parte da maioria, pare de escrever código de merda e melhore o código legado aos poucos.

Assuma estes compromisso com sua equipe:

  • Sempre que forem desenvolver uma funcionalidade ou alterar qualquer coisa no código, vocês irão deixar o código melhor que encontraram. Com pequenos passos você notará uma grande diferença ao longo do tempo. Deixe o nome de um método mais claro, remova códigos duplicados, etc.

  • Vocês irão listar as 10 áreas mais importantes do código para serem melhoradas (você pode usar o churn, importância para regra de negócios e a utilização em outras áreas do código como parâmetro), priorize e explique a necessidade para o product owner de incluí-las no sprint.

Tenha em mente, independente da forma que escolher, pagar Dívida Técnica significa menos features a curto prazo. Pense nisso como um investimento a longo prazo, você paga o preço agora, mas colhe os frutos depois. Garanta que todos entendam essa parte.

Você precisa reduzir a velocidade para poder ir cada vez mais rápido.

Conclusão

A qualidade do código é responsabilidade única e exclusivamente de quem trabalha nele (a.k.a. programadores).

Como programador, o problema é seu, e a solução também. Não se envergonhe do passado. Ao invés disso, tenha orgulho e use todo o seu poder para resolver isso. Você está tomando uma decisão que fará muita diferença, pare de escrever código de merda.

Isso vai desencadear uma série de eventos. Coisas boas irão acontecer no longo prazo. É difícil, é preciso ter coragem, é preciso brigar, e não vai ser fácil. Porém eu não conheço nenhuma outra forma de pagar uma Dívida Técnica, mas uma coisa eu posso te garantir: vai valer a pena!

Boa sorte!