Como posso quantificar o montante de dívida técnica existente em um projeto?

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.

O Sonar tem uma heurística de dívida técnica, bem como vários outros recursos úteis para um projeto de software.

Também suporta uma ampla gama de idiomas.

SonarQube (formerly Sonar) is an open source platform for Continuous Inspection of code quality...

• Support 25+ languages: Java, C/C++, C#, PHP, Flex, Groovy, JavaScript, Python, PL/SQL, COBOL, etc.
• SonarQube is also used in Android Deveopment.
• Offers reports on duplicated code, coding standards, unit tests, code coverage, complex code, potential bugs, comments and design and architecture.
• Time machine and differential views.
• Fully automated analyses: integrates with Maven, Ant, Gradle and continuous integration tools (Atlassian Bamboo, Jenkins, Hudson, etc.).
• Integrates with the Eclipse development environment
• Integrates with external tools: JIRA, Mantis, LDAP, Fortify, etc.
• Expandable with the use of plugins.
• Implements SQALE methodology to compute technical debt...

Eu odeio usar uma analogia das finanças, mas parece realmente apropriado. Quando você está precificando algo (ativos de qualquer tipo), pode ter valor intrínseco e extrínseco. Neste caso, o código existente tem valor intrínseco que seria uma quantidade correspondente à qualidade relativa do código e também teria valor extrínseco (valor do que poderia ser feito para o código) e essas quantidades seriam aditivas. O valor intrínseco pode ser dividido em créditos e débitos (bom vs. ruim) usando qualquer metodologia que você esteja usando para marcar o código (+5 para comentários / legibilidade, -10 para cobertura de código, etc.)

Eu certamente não conheço nenhuma ferramenta que quantifique isso hoje e eu acho que você teria uma discussão totalmente nova em suas mãos se você discutir os méritos das diferentes estratégias de "avaliação da dívida", mas eu concordo com Matthew - o A dívida é o custo acumulado de obter o código tão bom quanto você pode obtê-lo, usando o método que você usa para custar o homem-hora que leva para chegar lá.

Outra coisa a considerar é que há certamente uma medida de custo-efetividade em que à medida que a pessoa se aproxima da "perfeição", o valor de uma hora gasto na base de código está mais do que provável decrescendo exponencialmente; problema de otimização para maximizar a utilidade do trabalho realizado.

Acho que a questão é quanto custaria "recomprar" sua dívida técnica - ou seja, quanto trabalho é para consertá-lo? Bem, cabe à equipe descobrir isso.

Durante o planejamento de sprints, peço à equipe que estime a complexidade de corrigir itens de dívida técnica da mesma forma que estimaria a complexidade de uma história de usuário. Nesse ponto, é um jogo de negociação entre a equipe e o product owner para determinar qual dívida técnica é alta o suficiente para ser feita no sprint atual (deslocando as histórias reais do usuário) e o que pode esperar.

Se você não está fazendo scrum, eu manteria minha premissa - a dívida técnica deve ser medida pelo custo do remédio.

Entre desenvolvedores, uma medida bastante confiável de dívida técnica parece ser WTFs / minuto .

_{O problema com essa "métrica" é que normalmente é bastante difícil se comunicar "fora".}

A métrica que funcionou para mim ao comunicar a dívida técnica para "pessoas de fora" foi uma quantidade de testes e esforço de correção de erros (especialmente para corrigir erros de regressão ) necessários para uma entrega bem-sucedida.

Uma palavra de cautela: embora esta abordagem seja bastante poderosa, é melhor verificar com bons e velhos WTFs / minuto antes de recorrer a ela. O problema é que é um pouco complicado: para obter os dados, é preciso rastrear com cuidado o tempo e registrá-lo com precisão por categorias apropriadas.

• é muito mais fácil declarar 3 semanas gasto na implementação do recurso A do que
  Passei 14 horas na implementação do rascunho do recurso A e depois 29 horas no teste de fumaça e 11 horas na implementação de correções para regressões que descobri, depois de 18 horas testando a implementação do recurso pronto para QA. Depois disso, pessoal de controle de qualidade passou 17 horas testando a versão inicial do candidato. Depois disso, passei 13 horas analisando os bugs enviados pelo controle de qualidade para a liberação inicial do candidato e 3 horas para implementar as correções. Depois disso, passei 11 horas fumando testando as alterações que fiz na liberação inicial do candidato. Depois disso ...

De qualquer forma, dados sobre testes e esforços de correção de erros foram muito fáceis de se comunicar na minha experiência.

For recent release, we spent about 90% time on testing and fixing regression bugs. For next release, suggest to allocate some effort on getting this value down to 60-70%.

Outra palavra de cautela. Dados como 90% acima poderiam ser interpretados não apenas como uma indicação de dívida técnica, mas também (surpresa surpresa) como indicação de um não ser bem proficiente em programação / tecnologia específica. "Você só faz muitos erros no seu código".

Se houver um risco de que os dados sejam mal interpretados dessa forma, será útil ter um dado adicional de referência em algo menos WTF propenso para comparar.

• Digamos que existem dois componentes / aplicativos similares mantidos pelo (s) mesmo (s) desenvolvedor (es), primeiro lançando "taxa de desperdício" em torno de 50% e segundo em 80-90, o que faz um strong argumento a favor de segundo sendo objeto de dívida técnica.

Se houver testadores dedicados no projeto, eles também podem contribuir para uma avaliação mais objetiva dos dados. Como mencionei em outra resposta ,

With testers, you get someone to backup your understanding of design issues. When there are only developers complaining about code quality, this often sounds like subjective WTFs from behind the closed door.
 
But when this is echoed by QA guy saying something like component A had 100 regression bugs for 10 new features, as opposed to component B which had 10 regression bugs per 20 new features, communication suddenly turns into whole another game.

Existe uma plataforma bastante strong chamada CAST para procurar dívidas técnicas em grandes aplicações. Usamos em um projeto onde assumimos um grande aprimoramento para um sistema legado. Ele não diz a você o que estava na mente das pessoas que escreveu o código, mas examina o código e encontra falhas de código e arquitetura, então quantifica a dívida técnica, se você quiser. O uso real em olhar para isto, entretanto, não é a quantia de $ mas a lista de problemas já no código. Isto diz-lhe sobre uma parte da dívida técnica que você tem (por isso não concordo com algumas das respostas acima). Existe alguma dívida técnica que é puramente baseada em design e isso é muito subjetivo - como a pornografia - você sabe disso quando vê e conhece o contexto. Eu diria se isso é realmente uma dívida "técnica". Existe alguma dívida técnica puramente na implementação e acredito que vale a pena medir e rastrear.

Aqui está um Webinar do MIT descrevendo pesquisas sobre dívida técnica em grandes sistemas de software: link

Os autores escreveram código para analisar um projeto e extrair métricas de 'complexidade arquitetônica'. Essas métricas demonstraram ter um strong relacionamento com a densidade de defeitos, a produtividade do desenvolvedor e a rotatividade de pessoal de desenvolvimento.

O trabalho descrito no Webinar baseia-se na pesquisa de modularidade feita por Alan MacCormack e Carliss Baldwin na Harvard Business School. Eu também olhava os documentos deles. Seu "custo de propagação" pode ser o que você está procurando.

Eu diria que as métricas de código padrão podem ser usadas como uma visão relativa de alto nível de endividamento técnico. O VS Ultimate inclui um Analisador de Código que lhe dará um "Índice de Sustentabilidade" baseado na Complexidade Cyclomática, Acoplamento, LoC e Profundidade de Herança. Você pode mergulhar em qualquer ponto problemático e ver detalhes (até o nível da função). Eu apenas o executei no meu projeto e as pontuações mais baixas que obtivemos foram 69 no nosso pacote de dados (configuração e inicialização do EF) e no nosso conjunto de testes. Tudo o resto foi de 90 ou acima. Existem outras ferramentas que oferecem mais métricas como como as discutidas em PPP

Eu não pensaria em dívida técnica como dólares, onde você precisa de um modelo sofisticado para quantificá-lo. Eu pensaria nisso como favores. Se alguém lhe faz um favor e é provável que você esqueça, você o escreve. Quando você pega um atalho, escreva-o. Isso ajuda você a lembrar, e mais impotente força você a reconhecer isso. Nenhuma ferramenta sofisticada é necessária. Bloco de notas ou Ecxel podem fazer o truque.

Se você tem um bom histórico através de um bugtracker ou algum tipo de software ágil, pode mantê-lo simples. Tempo gasto na conclusão de tarefas básicas. Além disso, a confiabilidade das estimativas quando o projeto era jovem vs. agora.