Dívida tecnica

• Dívida tecnica

O que é dívida técnica?

A dívida técnica pode causar muita frustração e esgotamento para as equipes de desenvolvimento. Engenheiros de software podem estar cientes dos efeitos colaterais da dívida técnica. No entanto, eles geralmente precisam explicar à equipe de produto por que soluções rápidas e fáceis para o desenvolvimento de codificação são arriscadas.

Então, em vez de estabilizar a situação, o negócio continua adicionando mais recursos , e a dívida técnica cresce . Por isso, costumamos dizer que dívida técnica não é um problema técnico . Por esse motivo, toda equipe de desenvolvimento de software deve tentar ao máximo evitar que a dívida técnica se acumule para que não resulte no pior cenário, que é a paralisação do projeto.

Ward Cunningham cunhou o termo em 1992 na conferência OOPSLA [1] como uma metáfora para o desenvolvimento de um ativo de software. Ele concluiu que o processo de desenvolvimento leva a um novo aprendizado, pois depende de artefatos que ele cunhou como dívida técnica.

Dívida técnica é tudo o que nos impede de desenvolver software rapidamente . Martin Fowler explica em seu quadrante de dívida técnica quatro caminhos diferentes que levam à criação de dívida técnica [4], mas há mais. Podemos ver isso, especialmente com empresas iniciantes que querem ir rápido e não pensam primeiro na qualidade.

Pode-se criar intencionalmente ou não dívida técnica . Usando o Quadrante da Dívida Técnica como exemplo, Martin Fowler explica:

Quadrante da Dívida Técnica [4]

Em estudos sobre produtividade de desenvolvedores [2], os desenvolvedores geralmente são forçados a introduzir uma nova dívida técnica, pois as empresas continuam negociando qualidade por objetivos de curto prazo, como novos recursos brilhantes . No entanto, a dívida técnica não afeta apenas toda a organização, mas também a felicidade, a satisfação no trabalho [3] e o moral dos desenvolvedores [8].

O principal problema com a Dívida Técnica é que o código é um conceito abstrato , então é difícil explicar o que acontece com os negócios e a gestão. Então, as empresas podem facilmente ignorar o que não veem ou não entendem. Então, aqui, precisamos ser explícitos e visualizar nossa Dívida Técnica para a empresa e a gestão.

Geralmente, durante o desenvolvimento de nossos sistemas de software, a capacidade disponível para novos recursos por ciclo de desenvolvimento diminui (o lead time está aumentando) enquanto a complexidade aumenta . Então, passamos mais tempo lutando contra a complexidade do que desenvolvendo novos recursos .

A imagem abaixo mostra como a dívida técnica reduz a capacidade das equipes de desenvolver novos recursos.

Com o tempo, a capacidade de desenvolver novos recursos diminui

Queremos uma organização de alto desempenho que nos dará uma vantagem competitiva para sermos mais responsivos e inovadores. Precisamos de um processo de desenvolvimento de software de alta qualidade para fazer isso rapidamente.

A Dívida Técnica ocorrerá de qualquer forma, mas precisamos de uma estratégia para reduzir a criação de novas dívidas, ao mesmo tempo em que nos permite reduzir as dívidas existentes. Investir nisso construirá riqueza técnica para nossa empresa.

Tipos de dívida técnica

Geralmente pensamos que código ruim = Dívida Técnica, mas há mais do que isso. Existem diferentes tipos de dívida técnica:

1. Qualidade do código — nosso código poderia ser mais claro de entender. Ele não tem padrões de codificação, é mal projetado e é muito complexo. Além disso, há muitos comentários de código explicando o que algo faz.
2. Testes precisamos de uma abordagem de teste adequada (confira a Pirâmide de Testes ), desde testes unitários até testes de integração e testes E2E.
3. Acoplamento entre módulos que bloqueiam uns aos outros aumenta o tempo para lidar com esse código.
4. Bibliotecas ou ferramentas desatualizadas estamos usando algumas bibliotecas ou ferramentas legadas com vários problemas, como segurança ou incapacidade de atualização para novas tecnologias e plataformas. Nós, como desenvolvedores, sempre queremos trabalhar com as tecnologias mais atualizadas e ferramentas eficientes.
5. Processo Manual —Alguns processos em nossa entrega precisam ser automatizados. Não há builds automatizados e nenhum processo de CI/CD.
6. Arquitetura errada ou inexistente não temos arquitetura adequada, ou é apenas uma grande bola de lama . Nossa arquitetura não reflete o que queremos alcançar com nosso sistema, ou não escala bem .
7. Falta de documentação — Não há documentação ou ela não foi atualizada para refletir o estado atual do sistema.
8. Falta de Compartilhamento de Conhecimento — Não temos uma cultura de compartilhamento de conhecimento, então não é fácil para os novatos se atualizarem. Devemos sempre documentar nossas decisões e especificações durante nosso trabalho.

E há mais tipos também, relacionados a trabalhos de baixo valor, problemas com monitoramento, etc.

No entanto, muitas organizações precisam de mais processos e estratégias para gerenciar e reduzir a dívida técnica, o que significa uma cultura de engenharia adequada .

Não há tempo para melhorias

Como medir a dívida técnica?

Quando você pergunta a especialistas como medir a Dívida Técnica, você obterá respostas diferentes. Às vezes, é o oposto. Durante muitos anos trabalhando como especialista e consultor em engenharia de software, descobri algumas maneiras práticas de medi-la.

1. Índice de Dívida Técnica (TDR). Isso compara o custo de consertar a dívida técnica com o custo de desenvolvimento original. Você pode expressar isso em termos de tempo ou dinheiro gasto. O TDR ajuda a obter adesão das partes interessadas do negócio ao traduzir a dívida técnica em termos financeiros.

Uma proporção do custo para consertar um sistema de software (Custo de Remediação) para o custo de desenvolvê-lo (Custo de Desenvolvimento). Essa proporção é chamada de Taxa de Dívida Técnica (TDR):

Índice de dívida técnica = (custo de remediação / custo de desenvolvimento) x 100%

Queremos ver essa proporção em 5% ou menos. Se for maior, o software está em um estado ruim. Essa pontuação indica, em tempo, quanto tempo a equipe de engenharia levaria para melhorar sua base de código para a qualidade desejada.

Uma proporção entre 20% e 50% indica dívida técnica significativa , onde os custos de remediação começam a questionar a viabilidade de continuar sem investimento substancial na resolução desses problemas. Projetos dentro dessa faixa geralmente exigem estratégias de redução de dívida direcionadas para evitar escalada.Proporções que excedem 50% geralmente sinalizam que o custo de consertar a dívida é metade ou até excede o custo inicial de desenvolvimento . Esse é normalmente o limite no qual as empresas devem considerar seriamente reescrever ou abandonar o projeto. No entanto, antes de decidir, você precisa saber algumas coisas, como o impacto comercial, tecnologia de preparação para o futuro, análise de custo-benefício, tempo de colocação no mercado, etc.

2. Métricas de qualidade de código . Use ferramentas para analisar a complexidade do código, duplicação e violações de padrões de codificação. Métricas como complexidade ciclomática, rotatividade de código, profundidade de herança e proporção de linhas de código podem fornecer dados quantitativos sobre o estado da sua base de código. Ferramentas automatizadas como o SonarQube podem analisar o código e identificar problemas como complexidade do código, possíveis bugs e duplicação.

3. Taxa de defeitos e lead time . Rastreie o número de novos bugs introduzidos em comparação com o número corrigido (taxa de defeitos) ou a Taxa de falhas de alterações nas métricas do Dora (qual porcentagem de suas alterações causa uma falha). O lead time mede o tempo para entregar uma alteração. Altas taxas de defeitos e longos lead times podem indicar dívida técnica, tornando o desenvolvimento lento e propenso a erros. Você pode criar um rótulo de "dívida técnica" para novos tickets relacionados a ele e usá-lo para medir a dívida técnica.

4. Cobertura de código . Esta métrica mede a porção de código executada por testes automatizados. Uma cobertura maior indica que uma base de código mais robusta tem menos probabilidade de ter dívida técnica oculta.

5. Pesquisas . Você também pode perguntar regularmente ao seu pessoal o quão ruim é a dívida técnica no projeto na visão deles. Você pode pedir para eles escalarem em uma escala de 1 a 10, o que não significa muito, mas se você acompanhar ao longo do tempo, você pode ver tendências aparentes.

Estratégias para combater a dívida técnica

Então, quais são algumas estratégias para reduzir a dívida técnica? Todos nós deveríamos começar priorizando a Dívida Técnica. Primeiro, precisamos analisar nosso processo de desenvolvimento e base de código para encontrar gargalos e criar um Mapa de Dívida Técnica (mostrado na imagem abaixo) . Então, uma vez que tenhamos esse mapa, precisamos revisar cada parte identificando as causas .

Quando temos essa lista, podemos examiná-la e verificar o que acontece se não fizermos nada (pode piorar ou não) e se essa parte do nosso sistema é usada para novos desenvolvimentos agora e no futuro. Então, quando marcamos essas duas coisas, podemos priorizar e manter coisas com pior dívida tecnológica, e construiremos sobre elas agora e no futuro.

Outra alternativa é construir esse mapa com base no esforço e na dor envolvidos na correção de problemas ou usar o modelo de pontuação RICE .

Mapa da dívida tecnológica

Você também pode organizar um workshop ou Tech Debt retros para construir um mapa. Você também deve auditar regularmente a dívida em todas essas categorias.

Uma estratégia recomendada para lidar com dívida técnica

Uma estratégia recomendada para lidar com a Dívida Técnica consiste nas seguintes etapas:

1. Precisamos ser transparentes sobre nosso desenvolvimento, gargalos e por que precisamos ir mais rápido. Então, precisamos resumir isso em uma linguagem que permita que todas as partes interessadas (engenharia e gestão) compartilhem o mesmo entendimento. Aqui, as visualizações ajudam muito.
2. Nossos sistemas precisam de propriedade e responsabilidade claras . Infelizmente, se algumas partes do nosso sistema não estiverem certas, ninguém se importa com elas.
3. Precisamos priorizar as coisas com base no impacto , como mostramos no Mapa da Dívida Tecnológica acima.
4. Precisamos capacitar equipes para corrigir problemas e resolver dívidas técnicas no fluxo natural do desenvolvimento de produtos. Precisamos de um equilíbrio saudável entre reduzir a dívida técnica e adicionar novas funcionalidades com uma abordagem pragmática. O que funciona bem é investir continuamente de 10 a 20% do tempo de desenvolvimento nisso. Como você pode fazer isso:
   1. Para dívidas menores (de até algumas horas), faça uma refatoração quando tocar nela. Mas, então, deixe as pessoas serem Bons Escoteiros .
   2. Para dívidas médias (de um dia a alguns dias de trabalho), você pode tentar o seguinte:
      1. As Tech Debt Fridays estão trabalhando somente nisso.
      2. Marque a dívida técnica como um recurso , priorize-a e trabalhe nela.
   3. Para dívidas mais significativas (de algumas semanas a alguns meses):
      1. Tire um tempo fixo para dívidas de tecnologia. Por exemplo, pegue uma história e trabalhe dois dias nela.
      2. Tenha uma força-tarefa especial (equipe dedicada) para lidar com isso por algum tempo.
5. Use métricas , como problemas de código (por exemplo, usando SonarQube) ou lead times. Essas métricas podem nos ajudar a tomar melhores decisões sobre a correção da Dívida Técnica.

Dívida tecnológica para 5 anos (fonte: “Storybook Dictionary” de Richard Scarry)

Ferramentas para rastrear dívida técnica

Existem diferentes tipos de ferramentas que podem rastrear a dívida técnica. No entanto, recomendo sempre usar algumas ferramentas existentes porque introduzir novas pode ser custoso. Em geral, a Dívida Técnica pode ser seguida das seguintes maneiras:

1. As ferramentas de gerenciamento de projetos incluem Jira, Asana, GitHub issues, Azure DevOps Board ou ferramentas mais específicas, como Stepsize, CodeScene ou NDepend (para .NET).

2. Ferramentas de análise de código automatizadas: você pode usar ferramentas de software como o SonarQube para rastrear e detectar problemas de código, problemas de segurança ou outros problemas.

3. Método de rastreamento manual — aqui, você pode usar o método mais adequado, como uma tabela do Excel ou o que funcionar para você. Pode até ser uma combinação dos métodos acima, como rastrear a dívida técnica estratégica no Miro , rastrear a dívida tática no Jira e usar métricas do SonarQube . Basta torná-lo acessível e fácil de atualizar.

   CodeScene para rastrear dívida técnica (créditos: Adam Tornhill/CodeScene)

Mantendo a dívida técnica baixa

Queremos produzir código com a velocidade, qualidade e complexidade certas , não de forma rápida e suja. Conforme o software evolui, a arquitetura dos nossos sistemas se torna mais complexa, dificultando a manutenção. No entanto, se começássemos com design e qualidade de código ruins, teríamos problemas mais tarde.

Nosso objetivo é produzir sistemas que sejam fáceis de manter, que possamos evitar erros e que problemas e melhorias adicionais possam ser adicionados a um baixo custo. Arquitetura de software e artesanato devem ser adequadamente definidos para atingir isso. Queremos equilibrar qualidade, velocidade e complexidade (como mostrado na imagem abaixo).

No entanto, quanto mais rápido desenvolvemos novas funcionalidades, mais difícil é garantir a qualidade do software. A dívida tecnológica tende a se acumular, levando a um processo de desenvolvimento mais lento e mais erros. Então, queremos ir mais devagar desde o início, o que nos dará mais velocidade no futuro .

A situação ideal para o desenvolvimento de software

A questão é como evitar criar dívida tecnológica em primeiro lugar. A resposta é ter um processo de desenvolvimento de software de alta qualidade . Aqui estão algumas coisas que podemos fazer:

1. Arquitete sistemas para o resultado desejado . Envolva os arquitetos desde o início na criação de equipes, definindo sua topologia [7], porque, caso contrário, a Lei de Conway [5][6] fará de nossa arquitetura uma imagem dos canais de comunicação de nossa organização, não a arquitetura desejada.
2. Escreva documentação para todas as suas decisões arquitetônicas (ADRs) e documentação técnica. Torne-a fácil de encontrar (coloque-a no repositório perto do código).
3. Escreva testes em todos os níveis da Pirâmide de Testes. Mire em 60-80% de cobertura de código.
4. Incentive uma cultura de revisão de código . Envolva todos nas revisões de código e verifique a legibilidade, o design, o desempenho, a segurança, a testabilidade e a documentação do código. É uma das melhores maneiras de compartilhar conhecimento.
5. A programação em pares funciona quando um desenvolvedor escreve uma ode enquanto outro fornece feedback e sugestões. Isso resulta em maior qualidade de código; com ela implementada, não precisamos de revisões de código.
6. Permita que os desenvolvedores refatorem . Devemos construir uma cultura sem pedir permissão para consertar dívida técnica, especialmente se isso puder ser feito em algumas horas.
7. Siga os padrões da base de código , como design, nomeação e arquitetura. Então, automatize isso por meio de ferramentas como linters ou seu processo de CI/CD.
8. TDD (Test-Driven Development) é um processo de design de software no qual cada funcionalidade é projetada escrevendo um teste e depois implementando-o corretamente.
9. Escreva código de alta qualidade . Eduque seus desenvolvedores primeiro para conhecer sua linguagem de programação em profundidade e entender conceitos de OO, padrões de design, refatoração, princípios de código limpo, padrões e estilos de arquitetura e princípios SOLID, YAGNI, KISS e DRY .
10. Entrega Contínua . O código é ajustado em ciclos curtos, então é sempre fácil para outros membros da equipe verificarem. Este método evita problemas significativos na produção ao empregar lançamentos frequentes e feedback rápido.