A dívida técnica é apenas uma ideia abstrata que, em algum ponto das linhas de design, construção, teste e manutenção de um sistema, certas decisões foram tomadas de tal forma que o produto se tornou mais difícil de testar e manter. Ter mais dívida técnica significa que será mais difícil continuar a desenvolver um sistema - ou você precisa lidar com a dívida técnica e alocar mais e mais tempo para o que de outra forma seriam tarefas simples, ou você precisa investir recursos (tempo e dinheiro). dinheiro) para reduzir a dívida técnica, refatorando o código, melhorando os testes e assim por diante.
Há várias métricas que podem fornecer alguma indicação sobre a qualidade do código:
- Cobertura de código. Existem várias ferramentas que informam qual porcentagem de suas funções, instruções e linhas são cobertas por testes de unidade. Você também pode mapear os testes de sistema e aceitação de volta aos requisitos para determinar a porcentagem de requisitos cobertos por um teste em nível de sistema. A cobertura apropriada depende da natureza do aplicativo.
- Acoplamento e coesão . O código que exibe baixo acoplamento e alta coesão é geralmente mais fácil de ler, entender e testar. Existem ferramentas de análise de código que podem relatar a quantidade de acoplamento e coesão em um determinado sistema.
- Complexidade ciclomática é o número de caminhos únicos através de uma aplicação. É tipicamente contado no nível do método / função. Complexidade ciclomática está relacionada à compreensibilidade e testabilidade de um módulo. Não só valores de complexidade ciclomática mais altos indicam que alguém terá mais dificuldade em seguir o código, mas a complexidade ciclomática também indica o número de casos de teste necessários para atingir a cobertura.
- As várias medidas de complexidade do Halstead fornecem informações sobre a legibilidade do código. Estes contam os operadores e operandos para determinar o volume, a dificuldade e o esforço. Muitas vezes, isso pode indicar o quão difícil será para alguém pegar o código e compreendê-lo, geralmente em instâncias como uma revisão de código ou um novo desenvolvedor para a base de código.
- Quantidade de código duplicado. Código duplicado pode indicar potencial para refatoração para métodos. Ter código duplicado significa que há mais linhas para um bug ser introduzido e uma maior probabilidade de existirem os mesmos defeitos em vários lugares. Se a mesma lógica de negócios existir em vários lugares, será mais difícil atualizar o sistema para levar em conta as alterações.
Muitas vezes, as ferramentas de análise estática poderão alertá-lo sobre possíveis problemas. Claro, só porque uma ferramenta indica um problema não significa que há um problema - é preciso um julgamento humano para determinar se algo pode ser problemático no futuro. Essas métricas apenas fornecem avisos de que talvez seja hora de examinar um sistema ou módulo mais de perto.
No entanto, esses atributos se concentram no código. Eles não indicam prontamente nenhuma dívida técnica na arquitetura ou no design do sistema que possa estar relacionada a vários atributos de qualidade.