코드 기반의 기술 부채에 일종의 코드 메트릭으로 사용할 수있는 도구가 있는지 아는 사람이 있습니까? 그렇지 않다면 누구든지 알고리즘이나 휴리스틱 집합을 알고 있습니까?

지금까지 그중 어느 것도 존재하지 않는다면 그러한 일을 시작하는 방법에 대한 아이디어에 관심이 있습니다. 즉, 메소드, 클래스, 네임 스페이스, 어셈블리 등에 의해 발생하는 기술적 부채를 어떻게 정량화 할 수 있습니까?

C # 코드 기반을 분석하고 평가하는 데 가장 관심이 있지만, 특히 개념이 언어 초월 인 경우 다른 언어도 자유롭게 사용할 수 있습니다.

기술 부채는 시스템 설계, 구축, 테스트 및 유지 관리 라인을 따라 제품을 테스트하고 유지하기가 더 어려워지는 특정 결정을 내렸다는 추상적 인 아이디어 일뿐입니다. 기술 부채가 많다는 것은 시스템 개발을 계속하기가 더 어려워진다는 것을 의미합니다. 기술 부채에 대처하고 간단한 작업이 될 수있는 시간을 더 많이 할당하거나 자원 (시간 및 코드를 리팩토링하고 테스트를 개선하는 등 기술 부채를 줄일 수 있습니다.

코드 품질에 대한 몇 가지 지표를 제공 할 수있는 여러 가지 메트릭이 있습니다.

• 코드 범위. 이 다양한 도구 단위 테스트에 의해 보호됩니다 귀하의 기능, 문 및 라인의 비율을 알려줍니다. 시스템 및 테스트를 요구 사항에 다시 매핑하여 시스템 수준 테스트에서 다루는 요구 사항의 백분율을 결정할 수도 있습니다. 적절한 적용 범위는 응용 프로그램의 특성에 따라 다릅니다.
• 커플 링 과 응집력 . 낮은 결합과 높은 응집력을 나타내는 코드는 일반적으로 읽고 이해하고 테스트하기가 더 쉽습니다. 주어진 시스템에서 커플 링 및 응집 량을보고 할 수있는 코드 분석 도구가 있습니다.
• 순환 복잡도 는 응용 프로그램을 통한 고유 한 경로의 수입니다. 일반적으로 방법 / 기능 수준에서 계산됩니다. 순환 복잡성은 모듈의 이해 및 테스트 가능성과 관련이 있습니다. 순환 복잡도 값이 높을수록 코드를 따르는 데 더 많은 문제가 발생할 수 있음을 나타낼뿐만 아니라 순환 복잡도는 적용 범위를 달성하는 데 필요한 테스트 사례 수를 나타냅니다.
• 다양한 Halstead 복잡성 측정 은 코드의 가독성에 대한 통찰력을 제공합니다. 이들은 연산자, 피연산자를 세어 볼륨, 난이도 및 노력을 결정합니다. 종종, 이는 코드 검토 나 코드 기반의 새로운 개발자와 같은 경우에 누군가가 코드를 집어 이해하는 것이 얼마나 어려울지를 나타낼 수 있습니다.
• 중복 코드의 양입니다. 중복 된 코드는 메소드에 대한 리팩토링 가능성을 표시 할 수 있습니다. 코드가 중복되면 버그가 발생할 줄이 더 많고 여러 곳에서 동일한 결함이있을 가능성이 높아집니다. 동일한 비즈니스 로직이 여러 곳에 존재하는 경우 변경 사항을 설명하기 위해 시스템을 업데이트하기가 더 어려워집니다.

정적 분석 도구 는 종종 잠재적 인 문제를 경고 할 수 있습니다. 물론, 도구가 문제를 표시한다고해서 문제가있는 것은 아닙니다. 어떤 문제가 길에서 문제가 될 수 있는지 판단하려면 사람의 판단이 필요합니다. 이러한 메트릭은 시스템이나 모듈을보다 자세히 살펴볼 때가되었다는 경고 만 제공합니다.

그러나 이러한 특성은 코드에 중점을 둡니다. 시스템 아키텍처 나 디자인에서 다양한 품질 특성과 관련 될 수있는 기술적 부채를 쉽게 나타내지 않습니다.

Sonar 는 기술적 부채 추론과 소프트웨어 프로젝트에 유용한 몇 가지 다른 기능을 가지고 있습니다.

또한 매우 다양한 언어를 지원합니다.

SonarQube (이전의 Sonar )는 코드 품질의 지속적인 검사를위한 오픈 소스 플랫폼입니다.

• Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL 등 25 개 이상의 언어 지원
• SonarQube는 Android Deveopment에서도 사용됩니다.
• 중복 코드, 코딩 표준, 단위 테스트, 코드 적용 범위, 복잡한 코드, 잠재적 버그, 의견 및 디자인 및 아키텍처에 대한 보고서를 제공합니다.
• 타임머신 및 차동 뷰.
• 완전 자동화 된 분석 : Maven, Ant, Gradle 및 지속적인 통합 도구 (Atlassian Bamboo, Jenkins, Hudson 등)와 통합됩니다.
• Eclipse 개발 환경과 통합
• 외부 도구 (JIRA, Mantis, LDAP, Fortify 등)와 통합
• 플러그인을 사용하여 확장 가능
• 기술 부채 계산을 위한 SQALE 방법론 구현 ...

나는 금융의 비유를 사용하는 것을 싫어하지만 실제로는 적절 해 보입니다. 가격을 책정 할 때 (어떤 종류의 자산이든) 내재적 가치와 외적 가치를 모두 가질 수 있습니다. 이 경우에, 기존 코드는 상기 코드의 상대적인 품질에 대응하는 양이 될 고유 값을 가지며, 또한 고유 값 (코드에 수행 될 수있는 것으로부터의 값)을 가질 것이며 그 양은 부가적일 것이다. 고유 한 가치는 코드를 점수 매기기 위해 사용하는 방법 (댓글 / 가독성 +5, 코드 범위 -10 등)을 사용하여 크레딧과 차변 (좋은 대 나쁜)으로 나눌 수 있습니다.

나는 오늘 이것을 정량화하는 도구를 전혀 모른다. 당신이 다른 "부채 평가"전략의 장점을 주장하지만 매튜에 동의한다면, 당신은 당신의 손에 대해 완전히 새로운 토론을 할 것이라고 생각한다. 코드를 얻을 수있는 한 좋은 품질을 얻는 데 드는 누적 비용. 여기에 도달하는 데 소요되는 시간을 계산하는 데 사용하는 모든 방법을 사용합니다.

고려해야 할 또 다른 점은 "완벽"에 가까워 질수록 코드베이스에 소비되는 시간의 값이 기하 급수적으로 감소 할 가능성이 있으므로 추가적인 최적화 문제가있을 수 있다는 점에서 비용 대비 효과가 있다는 점입니다. 수행 한 작업의 유용성을 극대화합니다.

개발자들 사이에서 상당히 신뢰할만한 기술적 부채 측정 값은 분당 WTF 인 것 같습니다 .

_{이 "메트릭"의 문제점은 일반적으로 "외부"와 통신하기가 다소 어렵다는 것입니다.}

"외부인"에게 기술 부채를 전달하는 데 도움이 된 지표는 성공적인 전달에 필요한 테스트 및 버그 수정 노력 (특히 회귀 버그 수정 )이었습니다.

주의 사항 :이 방법은 매우 강력하지만, 사용 하기 전에 오래된 WTF / 분으로 재확인 하는 것이 좋습니다. 데이터를 가져 오려면 시간을 신중하게 추적하고 적절한 범주별로 정확하게 기록해야합니다.

• 기능 A를 구현하는 데 14 시간을 사용한 후 연기 테스트에 29 시간을 사용한 후 발견 한 회귀에 대한 수정 사항을 구현하는 데 11 시간을 사용한 후 QA를 테스트하는 데 18 시간을 소비 한 것보다 기능 A를 구현하는 데 소요 된 총 3 주 를 언급하는 것이 훨씬 쉽습니다.
   
  준비된 기능 구현. 그 후 QA 직원은 초기 후보 릴리스를 테스트하는 데 17 시간을 보냈습니다. 그 후 QA에서 초기 후보 릴리스에 대해 제출 한 버그를 분석하는 데 13 시간을, 수정을 구현하는 데 3 시간을 보냈습니다. 그 후, 나는 11 개월 동안 연기하여 초기 후보 릴리스 변경 사항을 테스트했습니다. 그 후 ...

어쨌든 테스트 및 버그 수정 노력에 대한 데이터는 내 경험에서 매우 쉽게 전달할 수있었습니다.

최근 릴리스에서는 회귀 버그를 테스트하고 수정하는 데 약 90 %의 시간이 걸렸습니다. 다음 릴리스에서는이 값을 60-70 %로 낮추는 데 약간의 노력을 기울이십시오.

또 다른주의 사항. 90 % 이상의 데이터 는 기술 부채의 표시 일뿐만 아니라 프로그래밍 / 특정 기술에 능숙하지 않은 것으로 해석 될 수도 있습니다. "코드에 너무 많은 버그를 만들었습니다."

데이터가 그런 식으로 잘못 해석 될 위험이있는 경우, 비교 하기 어려운 WTF가 적은 것에 대한 추가 참조 데이터를 갖는 것이 도움이됩니다 .

• 동일한 개발자가 유지 관리하는 두 개의 유사한 구성 요소 / 응용 프로그램이 처음에 "폐기율"로 약 50 %, 두 번째로 80-90으로 릴리스되는 경우, 두 번째 기술 부채가 유리 하다는 점 에서 꽤 강력한 사례가됩니다 .

프로젝트에 전담 테스터가있는 경우 데이터의 객관적인 평가에 기여할 수도 있습니다. 내가에서 언급 한 바와 같이 다른 답변 ,

테스터를 사용하면 디자인 문제에 대한 이해를 백업 할 수 있습니다. 코드 품질 에 대해 불평하는 개발자 만있는 경우, 종종 닫힌 문 뒤에서 주관적인 WTF 처럼 들립니다 .
 
그러나 QA 사람 component A이 10 개의 새로운 기능에 대해 100 개의 회귀 버그가component B 있다고 말하면서 20 개의 새로운 기능 당 10 개의 회귀 버그 가 있는 것과는 달리 통신은 갑자기 완전히 다른 게임으로 변합니다.

문제는 기술 부채를 "구매"하는 데 드는 비용, 즉 문제를 해결하는 데 얼마나 많은 비용이 드는 것입니다. 그것을 알아내는 것은 팀의 몫입니다.

스프린트 계획 중에는 팀에게 사용자 스토리의 복잡성을 추정하는 것과 같은 방식으로 기술 부채 항목을 수정하는 복잡성을 추정하도록 요청합니다. 이 시점에서 현재 스프린트에서 수행 할 수있는 우선 순위가 높은 기술 부채 (실제 사용자 스토리 대체)와 대기 ​​할 수있는 항목을 결정하기 위해 제품 소유자와 팀 사이의 협상 게임입니다.

당신이 스크럼을하지 않는다면, 나는 나의 전제에 충실 할 것이다. 기술적 부채는 구제 비용에 의해 측정되어야한다.

CAST 라는 꽤 강력한 플랫폼이 있습니다.큰 응용 분야에서 기술 부채를 찾을 수 있습니다. 우리는 레거시 시스템을 크게 향상시킨 프로젝트에서 사용했습니다. 코드를 작성한 사람의 머릿속에 무엇이 있는지 알려주지는 않지만 코드를 검사하고 코드 및 아키텍처 결함을 찾은 다음 원하는 경우 기술 부채로 수량화합니다. 그러나 이것을 볼 때 실제로 사용하는 것은 $ 금액이 아니라 이미 코드에있는 문제 목록입니다. 이것은 당신이 가진 기술적 부채의 일부에 대해 알려줍니다 (따라서 위의 답변 중 일부에 동의하지 않습니다). 순전히 디자인 기반이며 포르노와 같이 매우 주관적인 기술적 부채가 있습니다.이를 보면 상황을 알 수 있습니다. 나는 그것이 정말로 "기술적 인"부채인지 논할 것이다. 순전히 구현에 기술적 부채가 있으며

다음은 대규모 소프트웨어 시스템의 기술 부채에 대한 연구를 설명하는 MIT 웹 세미나입니다. http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

저자는 프로젝트를 분석하고 '건축 복잡성'메트릭을 추출하는 코드를 작성했습니다. 이러한 지표는 결함 밀도, 개발자 생산성 및 개발 직원 이직률과 강한 관계가있는 것으로 나타났습니다.

웹 세미나에 설명 된 작업은 Harvard Business School의 Alan MacCormack 및 Carliss Baldwin이 수행 한 모듈화 연구를 기반으로합니다. 나는 그들의 논문도 볼 것이다. 그들의 '전파 비용'은 당신이 찾고있는 것일 수 있습니다.

표준 코드 메트릭스 를 기술적 부채에 대한 높은 수준의 상대적인 관점 으로 사용할 수 있다고합니다 . VS Ultimate에는 Cyclomatic Complexity, Coupling, LoC 및 Depth of Inheritance를 기반으로하는 "유지 관리 성 지수"를 제공하는 코드 분석기가 포함되어 있습니다. 문제 지점으로 뛰어 들어 세부 사항을 볼 수 있습니다 (기능 수준까지). 방금 프로젝트에서 실행했으며 데이터 패키지 (EF 구성 및 초기화)와 테스트 스위트에서 69 점을 받았습니다. 다른 모든 것은 90 이상이었습니다. Bob 아저씨의 PPP 에서 논의 된 것과 같은 더 많은 메트릭을 제공하는 다른 도구가 있습니다

나는 기술 부채를 당신이 그것을 정량화하기 위해 멋진 모델이 필요한 달러로 생각하지 않을 것입니다. 나는 그것을 호의로 생각할 것이다. 누군가 당신에게 호의를 베풀고 잊어 버릴 수 있다면, 그것을 적어 두십시오. 지름길을 쓰면 적어 두십시오. 이것은 당신이 기억하도록 돕고, 더 무력한 것이 그것을 인정하도록 강요합니다. 멋진 도구가 필요하지 않습니다. 메모장이나 Ecxel이 트릭을 수행 할 수 있습니다.

나는 이것을 정확하게 조사하는 회사에서 일합니다. 다음은 기술 부채를 해결할 때 권장되는 3 가지 실행 가능한 지표입니다. "어떻게"와 "언제"를 추적하는 방법에 대한 자세한 내용은 기술 문서 이해 및 해결을 위한 요약 문서 3을 정리했습니다 .

당신의 생각은 무엇입니까? 모든 질문에 답하고 기꺼이 귀하의 의견을 듣고 싶습니다 :).

결함 및 원치 않는 기술 부채 방지를위한 소유권

소유권은 엔지니어링 건강의 주요 지표입니다.

많은 사람들로부터 기부금을받는 코드베이스의 일부는 시간이 지남에 따라 뭉개지지만, 적은 사람들로부터 기부금을받는 사람들은 더 나은 상태에있는 경향이 있습니다. 코드베이스의 일부에 대해 잘 알고있는 엄격한 그룹에서 높은 표준을 유지하는 것이 더 쉽습니다.

이것은 약간의 예측력을 제공합니다. 코드베이스의 약한 소유 부분은 시간이 지남에 따라 부채를 축적하고 작업하기가 점점 어려워 질 수 있습니다. 특히, 불완전한 정보의 부수적 인 영향과 코드 품질의 희석 된 소유권으로 인해 의도 치 않게 부채가 발생할 가능성이 높습니다 .

이것은 공통 의 비극 과 다소 유사합니다 .

아키텍처 개선을위한 응집력

응집력은 잘 정의 된 구성 요소의 후행 지표입니다.

응집력과 그 대응 물인 커플 링은 소프트웨어 설계시 중점을 두어야 할 중요한 개념으로 오랫동안 인식되어 왔습니다.

코드는 대부분의 요소가 함께 속해있을 때 응집력이 높다고합니다. 높은 응집력은 일반적으로 유지 보수성, 재사용 성 및 견고성과 관련되어 있기 때문에 선호됩니다. 높은 응집력과 느슨한 결합은 서로 밀접한 관계가 있습니다.

재사용 성이 높고 유지 보수가 용이 한 코드와 관련하여 높은 응집력은 코드베이스의 특정 부분을 수정하는 데 참여해야하는 사람들의 수를 최소화하여 생산성을 향상시킵니다.

문제 영역을 식별하기 위해 이탈

이탈 (반복 활동)은 성장하는 시스템에서 리팩토링하기에 익은 영역을 식별하고 순위를 매기는 데 도움이됩니다.

시스템이 성장함에 따라 개발자가 아키텍처를 이해하기가 더 어려워집니다. 개발자가 새로운 기능을 제공하기 위해 코드베이스의 많은 부분을 수정해야하는 경우 버그로 이어지는 부작용을 피하는 것이 어려울 것이며 더 많은 요소와 개념에 익숙해 져야하므로 생산성이 떨어집니다.

따라서보다 안정적인 시스템을 만들고 의도하지 않은 결과를 피하기 위해 단일 책임을 수행하는 것이 중요합니다. 일부 파일은 아키텍처 허브이며 새로운 기능이 추가됨에 따라 활성화 상태를 유지하지만 파일을 닫을 수있는 방식으로 코드를 작성하고 철저한 검토, 테스트 및 QA 이탈 영역을 작성하는 것이 좋습니다.

Churn은 이러한 활성 파일을 표면화하므로 코드베이스의 표면적 변경 영역을 줄이기 위해 파일을 분할할지 여부를 결정할 수 있습니다.

버그 추적 기나 일종의 애자일 소프트웨어를 통해 좋은 기록을 가지고 있다면 간단하게 유지할 수 있습니다. 기본 작업을 완료하는 데 소요 된 시간입니다. 또한 프로젝트가 젊었을 때와 현재의 추정치의 신뢰성.