Nos últimos dois anos, nós temos acompanhado o débito técnico em nosso backlog de desenvolvimento. Adicionar o pagamento do débito para o backlog, tornar o custo e o risco de débito técnico visíveis para a equipe e para o dono do produto, priorizar pagamentos com outro trabalho: isso tudo deveria garantir que o débito seja pago.

Mas eu não estou convencido de que vale a pena. Eis o porquê:

Débitos que não valem a pena rastrear porque não valem a pena pagar

Não vale a pena se preocupar com alguns débitos.

Um pouco (mas não muito) de copiar e colar. Questões de estilo de codificação espalhafatosos pegas por algumas ferramentas de análise estática (importa realmente onde estão os colchetes?). Método pobres e nomenclatura de variáveis. Os métodos que são muito grandes. Código que não segue corretamente as normas ou os padrões de codificação. Outras inconsistências. Codificação difícil. Números mágicos. Falhas triviais.

Isso é irritante, mas não é o tipo de débito que você precisa controlar no backlog. É possível resolvê-los na refatoração oportunista do dia a dia. A próxima vez que você estiver no código, limpe-o. Se não for alterar o código, então quem se importa? Não custa nada. Se você fechar os olhos e fingir que ele não está lá, nada de ruim vai realmente acontecer.

Débito de outra pessoa

Software livre ou software de terceiros desatualizados. O tipo de coisas que Sonatype CLM ou a Verificação da Dependência do OWASP vai falar sobre.

Parte disso é ruim – gravemente ruim. Vulnerabilidades de segurança exploráveis. Pense em Heartbleed. Isso não deve mesmo levá-lo para o backlog. Deve ser corrigido imediatamente. Certifique-se de que você sabe que pode construir e implantar uma biblioteca corrigida rapidamente e com confiança (como parte do seu pipeline de build/integração/entrega contínua).

Todo o resto é de baixa prioridade. Importa realmente se tiver uma versão mais recente com algumas correções de bugs, mas o código funcionar do jeito que você quer? Atualizar para o bem de atualização é um desperdício de tempo, e há uma chance de que você possa trazer novos problemas, quebrar alguma coisa de que você depende agora, com pouco ou nenhum retorno. Lembre-se: você tem o código-fonte – se realmente precisa reparar algo ou acrescentar alguma coisa, você pode sempre fazer isso sozinho.

Débito que você não sabe que tem

Alguns débitos mais assustadores são os que você não sabe que tem. Débito que você assumiu inconscientemente porque não sabia de nada… e ainda não sabe. Você tomou algumas decisões ruins de design. Você não sabia como usar corretamente o seu framework de aplicativo. Você não conhecia o Top 10 do OWASP e como se proteger contra ataques de segurança comuns.

Esse débito não pode estar no seu backlog. Se alguma coisa muda – uma pessoa nova e com mais experiência se junta à equipe, ou você é auditado, ou hackeado – esse débito pode se expor de repente. Caso contrário, continua se somando, silenciosamente, nos bastidores.

O débito que é muito grande para se lidar

Existe outro débito que é muito grande para se lidar efetivamente. Tal como o débito nacional dos EUA. O débito que você adquiriu no início, fazendo as premissas erradas ou tomando as decisões erradas. Talvez você não soubesse que estava errado, mas agora você sabe. Você – ou alguém antes de você – escolheu a arquitetura errada. Ou o idioma errado, ou o framework errado. Ou a tecnologia errada. O sistema não escala. Ou não é confiável sob carga. Ou ele está cheio de falhas de segurança. Ou é frágil e difícil de mudar.

Você não pode refatorar seu caminho para fora disso. Você tem que aguentá-lo da melhor forma possível, ou começar tudo de novo. Rastreá-lo em seu backlog parece sem sentido:

Como um desenvolvedor, quero reescrever o sistema, para que tudo não seja um saco…

Corrija agora, ou não será consertado em momento algum

O débito técnico que você pode fazer algo a respeito é a dívida que você assumiu, consciente e deliberadamente – às vezes de forma responsável, às vezes não.

Você pegou atalhos para ter o e obter o feedback rapidamente (testes A/B, prototipagem etc.). Existe uma boa chance de que você vai ter que reescrevê-lo ou até mesmo jogá-lo fora, então por que se preocupar em obter o código direito na primeira vez? Esse é o débito estratégico – que você pode se dar ao luxo de levá-lo, pelo menos por um tempo.

Ou você estava sob pressão e não podia se dar ao luxo de fazê-lo direito na época. Você tinha que fazê-lo rápido, e os resultados não são bonitos.

O código funciona, mas é um trabalho de hack. Você copiou e colou muito. Não seguiu as convenções, não teve o código revisado, não escreveu testes, ou pelo menos não o suficiente. Você deixou algum código de depuração. Vai ser um saco de manter.

Se você não chegar a isso em breve, se não limpá-lo ou reescrevê-lo em algumas semanas ou alguns meses, então existe uma boa chance de que esse débito nunca será pago. Quanto mais tempo ele permanece, mais difícil é para justificar a fazer alguma coisa a respeito, afinal de contas, ele está funcionando bem e todo mundo tem outras coisas para fazer.

A prioridade de fazer algo sobre isso continuará caindo, até que fique como limo, estabelecendo-se no fundo. Eventualmente, você vai esquecer que está lá. Quando você o vir, ele vai te deixar um pouco triste, mas você vai superar isso. Tal como compradores em Nova York, olhando para o relógio da dívida nacional dos Estados Unidos, em seu caminho para a loja para comprar uma nova TV a crédito.

E, se você tiver sorte, esse débito pode ser pago à vista, sem você saber dele. Alguém refatora algum código enquanto faz uma mudança, ou talvez até mesmo o apaga porque o recurso não é usado mais, e o débito desapareceu da base de código. Mesmo que ainda esteja em seus livros.

Não monitore débito técnico – lide com ele

Monitorar débito técnico soa como a coisa responsável a fazer. Se você não rastreá-lo, não é possível compreender o alcance dele. Mas qualquer coisa que você gravar em seu backlog nunca será um registro exato ou completo do quanto de débito você realmente tem – por causa do débito oculto que você obteve involuntariamente, aquele que você não entende ou ainda não encontrou.

Mais importante ainda, o trabalho de rastreamento que você não vai fazer é um desperdício do tempo de todos. Apenas monitore os débitos que todos concordam que são importantes o suficiente para serem pagos. Em seguida, certifique-se de pagar o débito o mais rápido possível. Dentro de 1 ou 2 ou talvez 3 sprints. Caso contrário, você pode ignorá-lo. Gaste seu tempo refatorando lixo em vez de recuperar o atraso. Isso não é ser irresponsável. É ser prático.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/02/dont-waste-time-tracking-technical-debt.html