Introdução à dívida técnica
Dívida técnica é um termo que descreve o custo futuro em que incorreremos ao escolher uma solução fácil hoje, em vez de usar práticas recomendadas, pois elas levariam mais tempo para serem concluídas.
O termo dívida técnica foi escolhido para sua comparação com a dívida financeira. É comum que pessoas com dívidas financeiras tomem decisões que parecem adequadas ou a única opção no momento, mas, ao fazê-lo, os juros aumentam.
Quanto mais juros se acumulam, mais difícil será para elas no futuro e mais opções menores estarão disponíveis posteriormente. Com a dívida financeira, logo, aumentam os juros sobre os juros, criando um efeito de 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 tempo classificando 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 os 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. Então, eu apenas testo meu novo código e posso evitar o nível de teste necessário se alterar o método original porque outras partes do código o utilizam.
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. 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 nenhum padrão de codificação. Então, os desenvolvedores nem sabiam o que deveriam estar produzindo. Os desenvolvedores podem não ter requisitos precisos para atingir. Bem, eles podem estar sujeitos a alterações de requisitos de última hora.
O trabalho de refatoração necessário pode ser atrasado. Pode não haver nenhum teste de qualidade de código, manual ou automatizado. No final, fica cada vez mais difícil entregar valor aos clientes em um prazo razoável e a um custo razoável.
A dívida técnica é um dos principais motivos pelos quais os projetos falham em atender aos prazos.
Ao longo do tempo, ela aumenta da mesma forma que a dívida monetária. Fontes comuns de dívida técnica são:
- Falta de padrões e estilo de codificação.
- Falta de design ou design ruim de casos de teste de unidade.
- Ignorar ou não compreender os princípios de design orientado a objetos.
- Classes monolíticas e bibliotecas de código.
- Visualização ruim do uso de tecnologia, arquitetura e abordagem. (Esquecer que todos os atributos do sistema, que afetam a manutenção, experiência do usuário, escalabilidade e outros, precisam ser considerados).
- Código de engenharia excessivo (adição ou criação de código desnecessário, adição de código personalizado quando as bibliotecas existentes são suficientes ou criação de camadas ou componentes desnecessários).
- Documentação e comentários insuficientes.
- Não escrever código autodocumentado (incluindo nomes de classes, métodos e variáveis que são descritivos ou indicam intenção).
- Adoção de atalhos para atender aos prazos.
- Deixar código morto no lugar.
Observação
Ao longo do 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, terá um custo proibitivo.
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ívidas técnicas 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 validá-las. O trabalho não planejado frequentemente atrapalha o trabalho planejado.
No longo prazo, também mina a força da organização. A dívida técnica tende a crescer em uma organização. Ela começa pequena e cresce ao longo do tempo. Sempre que um hack rápido é feito ou um teste é contornado porque as alterações precisam ser realizadas rapidamente, o problema fica cada vez pior. Os custos de suporte ficam cada vez mais altos e, invariavelmente, surge um problema sério.
Eventualmente, a organização não conseguirá responder às necessidades de seus clientes de maneira oportuna e econômica.
Medida automatizada para monitoramento
Uma maneira fundamental de minimizar a aquisição constante de dívida técnica é usar testes e avaliação automatizados.
Nas demonstrações a seguir, vamos analisar uma das ferramentas comuns usadas para avaliar a dívida: o SonarCloud. (A versão local original era o SonarQube.)
Há outras ferramentas disponíveis e discutiremos algumas delas.
Posteriormente, no próximo laboratório prático, você verá como configurar seus Azure Pipelines para usar o SonarCloud, entender os resultados da análise e, finalmente, como configurar perfis de qualidade para controlar os conjuntos de regras que são usados pelo SonarCloud ao analisar seus projetos.
Para saber mais, confira SonarCloud.
Revisando:
O Azure DevOps pode ser integrado a uma ampla variedade de ferramentas existentes usadas para verificar a qualidade do código durante os builds.
Quais ferramentas de qualidade de código você usa atualmente (se alguma)?
Do que você gosta ou não gosta nas ferramentas?