Introdução à dívida técnica

A dívida técnica é um termo que descreve o custo futuro que virá da escolha de uma solução fácil hoje em vez de usar práticas melhores que levariam mais tempo para serem concluídas.

O termo "dívida técnica" foi escolhido porque é semelhante à dívida financeira. É comum que as pessoas com dívidas financeiras tome decisões que pareçam certas ou como a única opção no momento, mas ao fazê-lo, os juros aumentam.

Quanto mais interesse se acumula, mais difícil fica para eles no futuro e menos opções eles têm mais tarde. Com dívida financeira, logo os juros aumentam sobre os próprios juros, criando um efeito bola de neve. Da mesma forma, a dívida técnica pode se acumular até o ponto em que os desenvolvedores gastam quase todo o seu tempo corrigindo problemas e fazendo retrabalho, planejado ou não planejado, em vez de adicionar 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 frequentemente adotam atalhos. Por exemplo, em vez de refatorar um método para incluir novas funcionalidades, eles podem copiá-lo para criar uma nova versão. Em seguida, eles só testam o novo código e podem evitar o nível de teste necessário se alterarem o método original porque outras partes do código o usam.

Agora eles têm duas cópias do mesmo código que precisam ser modificadas no futuro, em vez de uma, e correm o risco de a lógica se tornar diferente. Há muitas causas. 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, portanto, os desenvolvedores nem sabiam o que deveriam estar produzindo. Os desenvolvedores podem não ter requisitos claros a serem seguidos ou 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, isso só torna cada vez mais difícil entregar valor aos clientes em um período razoável e a um custo razoável.

A dívida técnica é um dos principais motivos pelos quais os projetos não cumprem seus prazos.

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

• Falta de estilo e padrões de codificação
• Falta ou projeto inadequado de casos de teste de unidade
• Ignorando ou não entendendo os princípios de design orientados a objetos
• Classes monolíticas e bibliotecas de código
• Uso mal planejado de tecnologia, arquitetura e abordagem (esquecendo-se de que todos os atributos do sistema, afetando a manutenção, a experiência do usuário, a 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 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ável que são descritivos ou indicam intenção)
• Tomando atalhos para cumprir prazos
• Deixar código morto no lugar

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

Ter dívida técnica em um projeto reduz 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 planejado frequentemente fica no caminho do trabalho planejado.

A longo prazo, também enfraquece a força da organização. A dívida técnica tende a aumentar em uma organização. Começa pequeno e cresce com o tempo. Toda vez que um hack rápido é feito ou o teste é ignorado porque as alterações precisam ser aceleradas, o problema fica cada vez pior. Os custos de suporte ficam cada vez mais altos e, eventualmente, surge um problema sério.

Eventualmente, a organização não pode responder às necessidades de seus clientes de maneira oportuna e econômica.

Medida automatizada para monitoramento

Uma maneira fundamental de minimizar o acúmulo constante de dívida técnica é usar testes e avaliação automatizados.

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

Há outras ferramentas disponíveis e discutiremos algumas delas.

Posteriormente, no próximo laboratório prático, você verá como configurar o Azure Pipelines para usar o SonarCloud, entender os resultados da análise e, por fim, 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.

Para examinar:

O Azure DevOps pode ser integrado a uma ampla gama de ferramentas existentes usadas para verificar a qualidade do código durante builds.

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

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