Como lidar com a dívida técnica: Fio dental ou tratamento de canal?

06 09 2021

Dívida técnica é um assunto que vem ganhando cada vez mais importância, dado a crescente necessidade que as empresas têm de adaptar, 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, podendo 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 XPTDD 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. 

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, 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. 

No tratamento de canal, 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. 

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, com o objetivo de facilitar a implementação de “prováveis” novas variações desse comportamento no futuro. 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 seus 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, do tipo de alteração que será realizada e, consequentemente, quais melhorias no código vão facilitar esse trabalho. Além do mais, como hoje existe uma necessidade de alterar um certo ponto do código, existe uma boa chance desse mesmo ponto ser alterado novamente no futuro. Isso 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 acredito 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, sem dúvida, o que pode trazer um melhor retorno para a organização é fomentar uma cultura de melhoria contínua da qualidade de código, onde os times sabem que podem agir para reduzir a dívida técnica todos os dias, 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, que é explicada de forma criativa por uma outra metáfora e 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).

3 respostas para “Como lidar com a dívida técnica: Fio dental ou tratamento de canal?

Deixe uma resposta

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

Postagens relacionadas

Se você aceitar vamos utilizar cookies para melhorar sua experiência neste site. Alguns coletarão suas preferências de uso (idioma, localização, personalização), outros coletarão estatísticas. Você pode aceitar ou declinar, mas em todos os casos a Softplan encoraja você a ler o nosso Aviso de Privacidade.