Introdução à dívida técnica

Concluído

Dívida técnica é um termo que descreve o custo futuro que será incorrido ao escolher uma solução fácil hoje em vez de usar melhores práticas, porque elas levariam mais tempo para serem concluídas.

O termo dívida técnica foi escolhido por sua comparação com a dívida financeira. É comum que pessoas endividadas financeiramente tomem decisões que parecem apropriadas ou a única opção no momento, mas, ao fazê-lo, os juros aumentam.

Quanto mais juros se acumularem, mais difícil será para eles no futuro e mais opções menores estarão disponíveis para eles mais tarde. Com a dívida financeira, logo, os juros aumentam sobre os juros, criando um efeito bola de neve. Da mesma forma, a dívida técnica pode se acumular a ponto de os desenvolvedores gastarem quase todo o seu tempo resolvendo problemas e fazendo retrabalho, planejado ou não, em vez de agregar valor.

Então, como isso acontece?

A desculpa mais comum são prazos apertados. Quando os desenvolvedores são forçados a criar código rapidamente, eles geralmente usam atalhos. Por exemplo, em vez de refatorar um método para incluir uma nova funcionalidade, vamos copiar para criar uma nova versão. Em seguida, eu só teste meu novo código e posso evitar o nível de teste necessário se eu alterar o método original porque outras partes do código o usam.

Agora tenho duas cópias do mesmo código que preciso modificar no futuro em vez de uma, e corro o risco de a lógica divergir. As causas são muitas. Por exemplo, pode haver falta de habilidades técnicas e maturidade entre os desenvolvedores ou nenhuma propriedade ou direção clara do produto.

A organização pode não ter padrões de codificação. Então, os desenvolvedores nem sabiam o que deveriam estar produzindo. Os desenvolvedores podem não ter requisitos precisos para segmentar. Bem, eles podem estar sujeitos a alterações de requisitos de última hora.

O trabalho de refatoração necessário pode ser adiado. Pode não haver nenhum teste de qualidade de código, manual ou automatizado. No final, apenas torna cada vez mais difícil entregar valor aos clientes num prazo razoável e a um custo razoável.

A dívida técnica é uma das principais razões pelas quais os projetos não cumprem os seus prazos.

Com o tempo, aumenta da mesma forma que a dívida monetária. As fontes comuns de dívida técnica são:

  • Falta de estilo e padrões de codificação.
  • Falta ou má conceção de casos de teste unitário.
  • Ignorar ou não compreender os princípios de design orientados a objetos.
  • Classes monolíticas e bibliotecas de código.
  • Mal imaginado o uso de tecnologia, arquitetura e abordagem. (Esquecendo que todos os atributos do sistema, afetando manutenção, experiência do usuário, escalabilidade e outros, precisam ser considerados).
  • Código de engenharia excessiva (adicionando ou criando código que não é necessário, adicionando código personalizado quando as bibliotecas existentes são suficientes ou criando camadas ou componentes que não são necessários).
  • Comentários e documentação insuficientes.
  • Não escrever código de auto-documentação (incluindo nomes de classe, método e variáveis que sejam descritivos ou indiquem intenção).
  • Tomando atalhos para cumprir prazos.
  • Deixando o código morto no lugar.

Nota

Com o tempo, a dívida técnica deve ser paga. Caso contrário, a capacidade da equipe de corrigir problemas e implementar novos recursos e aprimoramentos levará mais tempo e, eventualmente, se tornará proibitiva em termos de custos.

Vimos que a dívida técnica adiciona um conjunto de problemas durante o desenvolvimento e torna muito mais difícil agregar valor extra ao cliente.

Ter dívida técnica em um projeto diminui a produtividade, frustra as equipes de desenvolvimento, torna o código difícil de entender e frágil, aumenta o tempo para fazer alterações e validar essas alterações. O trabalho não planeado atrapalha frequentemente o trabalho planeado.

A longo prazo, também elimina a força da organização. A dívida técnica tende a aumentar sobre uma organização. Começa pequeno e cresce com o tempo. Cada vez que um hack rápido é feito ou o teste é contornado porque as mudanças precisam ser apressadas, o problema fica cada vez pior. Os custos de suporte aumentam cada vez mais e, invariavelmente, surge um problema sério.

Eventualmente, a organização não consegue responder às necessidades dos seus clientes de forma atempada e rentável.

Medição automatizada para monitoramento

Uma maneira fundamental de minimizar a constante aquisição de dívida técnica é usar testes e avaliações automatizados.

Nas demonstrações que se seguem, veremos uma das ferramentas comuns usadas para avaliar a dívida: o SonarCloud. (A versão local original era SonarQube).

Existem outras ferramentas disponíveis, e discutiremos algumas delas.

Mais tarde, no próximo laboratório prático, você verá como configurar seus Pipelines do Azure para usar o SonarCloud, entender os resultados da análise e, finalmente, como configurar perfis de qualidade para controlar os conjuntos de regras usados pelo SonarCloud ao analisar seus projetos.

Para obter mais informações, consulte SonarCloud.

Recapitulando:

O Azure DevOps pode ser integrado com uma ampla gama de ferramentas existentes usadas para verificar a qualidade do código durante as compilações.

Quais ferramentas de qualidade de código você usa atualmente (se houver)?

O que você gosta ou não gosta nas ferramentas?