Como posso estimar a vida útil de uma linha de código?

Estou tentando descobrir uma maneira de analisar a longevidade do código em projetos de código aberto: ou seja, quanto tempo uma linha específica de código está ativa e em uso.

Meu pensamento atual é que uma linha de vida útil do código começa quando é confirmada pela primeira vez e termina quando ocorre um dos seguintes:

• Ele foi editado ou excluído,
• Excluído das compilações,
• Nenhum código dentro de sua compilação é mantido por algum período de tempo (digamos, um ano).

NOTA: Como esclarecimento sobre por que uma "edição" está sendo contada como "morte", as linhas editadas seriam contadas como uma "nova" geração ou linha de código. Além disso, a menos que haja uma maneira fácil de fazer isso, não haveria contabilização da longevidade de uma linhagem ou descendência de um ancestral.

O que mais determinaria a vida útil de uma linha?

Andy Ozment olhou para o OpenBSD em 2006 com o mesmo tipo de pergunta: leite ou vinho: a segurança do software melhora com a idade?

Você pode aprender com a definição dele. Também é um artigo muito interessante, com uma conclusão interessante, que não foi incorporada ao conhecimento de gerenciamento de software:

Durante um período de 7,5 anos e quinze lançamentos, 62% das 140 vulnerabilidades relatadas no OpenBSD foram fundamentais : presentes no código no início do estudo.

Levou mais de dois anos e meio para que a primeira metade dessas vulnerabilidades fundamentais fosse relatada. Descobrimos que 61% do código-fonte na versão final estudada é fundamental: ele permanece inalterado em relação à versão inicial lançada 7,5 anos antes. Portanto, é provável que a taxa de relatório de vulnerabilidades fundamentais no OpenBSD continue a influenciar bastante a taxa geral de relatório de vulnerabilidades.

Também encontramos evidências estatisticamente significativas de que a taxa de relatórios de vulnerabilidade fundamental diminuiu durante o período do estudo. Utilizamos um modelo de crescimento de confiabilidade para estimar que 67,6% das vulnerabilidades na versão básica foram encontradas. A estimativa do modelo do número esperado de vulnerabilidades fundamentais relatadas por dia diminuiu de 0,051 no início do estudo para 0,024.

Eu não acho que há uma resposta para isso. É altamente projeto dependente. Alguns são mais estáveis ​​ao longo dos anos, outros são mais voláteis / refatorados / evoluindo ao longo dos anos.

Além disso, é difícil de medir. Uma linha editada é realmente o fim de sua vida útil? Que tal apenas uma mudança estética, como reformatar a base de código com guias ou espaços? IMHO que não conta como renovada base de código, mas seria de acordo com seus critérios.

Dito isto, acho que boa parte dos LOCs vive para sempre.

O motivo é simples: é muito mais fácil adicionar um novo código do que remover alguns. Especialmente quando o sistema é complexo e crescido ao longo dos anos. Em seguida, vem rapidamente a um ponto em que é "arriscado" para remover ou alterar o código não-trivial. Ele poderia introduzir erros, compatibilidade intervalo, introduzir um efeito borboleta de mudanças ... Então eu acho que, quanto maior a base de código torna-se, o mais velho ele é, mais as LOCs está indo para ficar.

Além disso, apenas bons programadores tendem a bases de código de limpeza e reduzir as linhas. Todos os outros tendem a acumular os LOCs. E até agora, os últimos estão ganhando de longe. ;)

Excluir ou excluir definitivamente uma linha de código é uma indicação do fim de sua vida útil.

Ao rever a edição, eu faria a seguinte pergunta: Esta declaração produz um resultado diferente após a edição?

Se a resposta for afirmativa, diria que a declaração anterior não está mais disponível, caso contrário, ainda a consideraria a continuação da declaração anterior.

Exemplo de alteração do resultado:

if ( a && b )

para:

if ( a || b )

Exemplo de continuidade da vida útil:

foo.bar( baz );

para:

foo.prototype.bar.call( this, baz );