코드 라인의 수명을 어떻게 추정 할 수 있습니까?

오픈 소스 프로젝트에서 코드 수명을 분석하는 방법을 찾으려고합니다. 즉, 특정 코드 줄이 활성화되어 사용되는 시간입니다.

내 생각은 코드의 수명이 처음 커밋되면 시작되고 다음 중 하나가 발생하면 끝납니다.

• 편집 또는 삭제되었습니다.
• 빌드에서 제외
• 빌드 내의 코드는 일정 기간 (예 : 1 년) 동안 유지되지 않습니다.

참고 : "편집"이 "죽음"으로 계산되는 이유에 대한 설명으로 편집 된 줄은 "새로운"세대 또는 코드 줄로 계산됩니다. 또한, 이렇게하는 쉬운 방법이 없다면 혈통의 수명이나 조상의 하강에 대한 설명이 없을 것입니다.

코드의 수명을 결정하는 다른 것은 무엇입니까?

Andy Ozment는 2006 년 OpenBSD에서 우유 또는 와인 같은 종류의 질문을 검토했습니다.

당신은 그의 정의에서 배울 수 있습니다. 또한 소프트웨어 관리 기술에 포함되지 않은 흥미로운 결론과 함께 매우 흥미로운 논문이기도합니다.

7.5 년 15 개의 릴리스 기간 동안 OpenBSD에보고 된 140 개의 취약점 중 62 %가 기초 가되었습니다 .

이 기본 취약점의 상반기가보고 되려면 2 년 반 이상이 걸렸습니다. 연구 한 최종 버전에서 소스 코드의 61 %가 기본입니다. 7.5 년 전에 출시 된 초기 버전과는 달라지지 않았습니다. 따라서 OpenBSD의 기본 취약점보고 비율은 전반적인 취약점보고 비율에 계속 큰 영향을 줄 것입니다.

또한 연구 기간 동안 기초 취약성 보고서의 비율이 감소했다는 통계 학적으로 중요한 증거가 발견되었습니다. 기본 버전의 취약점 중 67.6 %가 발견 된 것으로 추정하기 위해 안정성 성장 모델을 활용했습니다. 일일보고 된 예상 기본 취약점 수에 대한 모델의 추정치는 연구 시작시 0.051에서 0.024로 감소했습니다.

나는 그것에 대한 답이 없다고 생각합니다. 프로젝트에 크게 의존합니다. 일부는 수년에 걸쳐 더 안정적이고, 다른 일부는 수년에 걸쳐 더 휘발성 / 리팩터링 / 진화됩니다.

또한 측정하기가 어렵습니다. 편집 된 줄이 실제로 수명의 끝입니까? 탭이나 공백으로 코드베이스를 다시 포맷하는 것과 같은 외관상의 변화는 어떻습니까? IMHO는 갱신 된 코드베이스로 계산되지 않지만 기준에 따라 다릅니다.

즉, 나는 LOC의 좋은 덩어리가 영원히 산다고 생각합니다.

이유는 간단합니다. 일부 코드를 제거하는 대신 새 코드를 추가하는 것이 훨씬 쉽습니다. 특히 시스템이 수년에 걸쳐 복잡하고 성장할 때. 그런 다음 사소한 코드를 제거하거나 변경하는 것이 "위험"한 지점에 빨리 도달합니다. 버그가 생길 수 있고, 호환성이 깨질 수 있으며, 변경으로 인한 나비 효과가 발생할 수 있습니다. 따라서 코드베이스가 커질수록 LOC가 더 오래 유지 될 것으로 생각합니다.

또한, 훌륭한 프로그래머 만이 코드베이스를 정리하고 줄을 줄이는 경향이 있습니다. 다른 모든 사람들은 LOC를 쌓는 경향이 있습니다. 그리고 지금까지는 후자가 승리하고 있습니다. ;)

코드 줄을 삭제하거나 제외하면 수명이 끝났음을 나타냅니다.

편집을 업그레이드하면서 다음과 같은 질문을합니다. 이 문장은 편집 후 다른 결과를 생성합니까?

대답이 '예'이면 이전 진술을 더 이상 사용할 수 없다고 말하고, 그렇지 않으면 여전히 이전 진술의 계속으로 간주합니다.

결과 변경 예 :

if ( a && b )

에:

if ( a || b )

수명을 연장하는 예 :

foo.bar( baz );

에:

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