Dívida técnica de software: fio dental ou tratamento de canal?

Dívida técnica é um assunto que vem ganhando cada vez mais importância. Isso pela a crescente necessidade de adaptação das empresas, com rapidez, seus produtos de software às volúveis necessidades dos clientes, dos negócios ou do mercado. Se esse aspecto da qualidade do produto for negligenciado, o risco e o esforço para adaptar e evoluir o software tende a aumentar indefinidamente. Pior, pode rapidamente tornar a operação e os negócios insustentáveis. 

Quando os times e as organizações percebem isso, uma dúvida surge automaticamente: O que devemos fazer com a nossa dívida técnica? Quando vamos atacar esse problema? Quanto esforço vale a pena investir nisso? Devemos planejar e incluir itens no nosso backlog com o objetivo de reduzir essa dívida? Qual ponto do sistema eu melhoro primeiro?

Kent Beck, um dos criadores do XP, TDD e do manifesto ágil, costuma explicar algumas possíveis abordagens com uma metáfora que eu gosto bastante. Segundo ele, existem duas formas de reduzir a dívida técnica de um software: uma delas é como passar fio dental. A outra, é o tratamento de canal. 

Fio dental

Na primeira forma, o time de desenvolvimento torna o ato de refatorar o código em um hábito diário. Assim como passar fio dental, um time ágil, disciplinado e bem orientado, sabe que é preciso realizar esse ato de “higiene” constantemente, aos poucos, conforme vai realizando suas outras atividades de evolução ou correção do sistema. 

Por exemplo, antes de alterar o comportamento de um pequeno componente do software que não possui cobertura de testes, alguns testes podem ser criados para assegurar os comportamentos já existentes. O código a ser alterado pode, antes, ser refatorado para que o trabalho a ser realizado logo em seguida seja mais fácil e menos arriscado. 

Com isso, a qualidade do código vai melhorando de forma gradual e constante, com a dívida técnica sendo reduzida consistentemente e com baixo risco. Com esses bons hábitos fazendo parte da cultura do time, é possível cuidar da “saúde” interna do software, assim como passar fio dental nos ajuda a garantir a nossa saúde bucal. 

Se não tivermos o hábito de passar fio dental, com o passar do tempo, corremos o risco de adquirirmos graves problemas e doenças bucais. Isso ocorre até um momento em que a dor desses problemas nos impede de realizarmos nossas atividades do dia a dia. Chegou o momento de irmos ao dentista e fazermos um tratamento de canal. 

Tratamento de canal

Na segunda forma, tentamos resolver um problema grande, que cresceu com o passar do tempo, de forma mais brusca, invasiva e arriscada. O tratamento é doloroso e, como toda cirurgia, envolve riscos para o paciente. 

No caso do software, o equivalente a isso é quando o time resolve fazer grandes ações para reduzir a dívida técnica do software. Caros e arriscados projetos que visam a melhoria da qualidade interna do software, eventualmente tornam-se longas empreitadas cujos benefícios e o término são difíceis de mensurar. Um grande risco, no caso do tratamento de canal em software, é quando uma das dívidas técnicas adquiridas é a falta de testes automatizados. Ao remodelar o código sem a proteção de testes regressivos automatizados, o time se arrisca a alterar, de forma indesejada, o comportamento já existente do software. Em outras palavras, estragando o que já funcionava antes. 

Outro problema dessa abordagem é a incerteza do retorno sobre o investimento. O retorno de termos baixa dívida técnica em uma parte do sistema é que provavelmente será mais fácil, mais barato e menos arriscado alterar aquele ponto do sistema no futuro. Ao realizarmos grandes investidas para reduzir a dívida técnica de uma parte do sistema, podemos não ter certeza de que iremos alterar de novo aqueles mesmos pontos. Pode demorar meses ou até anos para percebermos retorno de tais refatorações, pois isso está condicionado à necessidade de mudar, evoluindo ou corrigindo, esses pontos. 

Opinião pessoal

Até mesmo o tipo de melhoria pode ter sido mal escolhido por não sabermos exatamente que mudanças ocorrerão no futuro. Por exemplo, podemos refatorar o código e encapsular parte do comportamento de uma classe utilizando o padrão de projetos Strategy, visando facilitar a implementação de “prováveis” novas variações desse comportamento. Se, com o passar do tempo, as alterações que forem realizadas na classe nunca demandarem esse tipo específico de variação, teremos que lidar com a complexidade introduzida pelo padrão sem usufruir dos benefícios. 

Particularmente, eu prefiro a primeira opção. Se as melhorias forem feitas logo antes de realizarmos as mudanças desejadas, além de termos um retorno imediato, teremos mais certeza do ponto do código e do tipo de alteração que será realizada. Assim, saberemos quais melhorias no código facilitarão esse trabalho. Além do mais, como hoje existe uma necessidade de alterar um certo ponto do código, há uma boa chance desse mesmo ponto ser alterado novamente no futuro. Não é coincidência, faz parte da natureza do desenvolvimento de software. 

No entanto, aproveitando ainda a metáfora, algumas vezes ações um pouco mais incisivas são realmente necessárias para curar condições graves na saúde (nossa e do software). No caso de software, um aspecto de dívida técnica em que vale a pena investir em ações maiores e focadas, é melhorar a cobertura e eficácia dos testes automatizados. Em muitos casos, o risco desse tipo de melhoria é mais baixo e temos como resultado uma proteção para realizarmos futuras melhorias com mais segurança. 

Mas, o que traz um melhor retorno para a organização é fomentar uma cultura de melhoria contínua da qualidade de código. Nela, os times sabem que podem agir para reduzir a dívida técnica diariamente, cobrindo o código legado com testes e refatorando logo antes e durante a realização de suas atividades. 

Se você gostou deste artigo, tenho certeza que vai curtir também as indicações abaixo.

_ Refactoring – Not on the backlog! do Ron Jeffries. O título do artigo é um tanto radical, mas serve para destacar as diferenças dessa abordagem. O artigo tem explicação criativa por uma outra metáfora e utiliza desenhos;

_ OpportunisticRefactoring  do Martin Fowler;

_ What Is Clean Code?  do Robert C. Martin (Uncle Bob). Fala sobre uma regra aplicada pelos escoteiros e que pode ser adotada como um bom hábito pelos desenvolvedores.