소프트웨어 품질에 대한 객관적인 지표

소프트웨어 제품에서 측정 할 수있는 다양한 유형의 품질이 있습니다 (예 : 목적 적합성 (예 : 최종 사용), 유지 보수성, 효율성). 이들 중 일부는 다소 주관적이거나 도메인에 따라 다릅니다 (예 : 훌륭한 GUI 디자인 원칙은 문화에 따라 다를 수 있거나 사용 상황에 따라 달라질 수 있습니다.

내가 관심이있는 것은 유형의 네트워크 (또는 그래프) 및 관련성, 즉 각 유형이 참조하는 유형과 관련된 더 깊은 품질의 품질 형식이며, 올바르게 관련된 유형의 상호 연결성 클러스터가 있는지 계층 구조, 또는 거꾸로 유형 참조의 큰 '공'( '모 놀리 식'코드)이 있습니다. 또한 각 유형 및 / 또는 방법의 크기 (예 : Java 바이트 코드 또는 .Net IL의 수량으로 측정)는 복잡한 복잡한 알고리즘이 더 관리 가능하고 유지 관리 가능한 것으로 분해되는 대신 모 놀리 식 코드 블록으로 구현 된 위치를 나타냅니다. 덩어리.

그러한 아이디어를 기반으로 한 분석가는 최소한 품질에 대한 대리인 통계를 계산할 수 있습니다. 높은 품질과 낮은 품질 사이의 정확한 임계 값 / 결정 점은 주관적이라고 생각합니다. 예를 들어 유지 관리 성으로 인해 인간 프로그래머가 유지 관리 성을 의미하므로 기능적 분해가 인간의 마음이 작동하는 방식과 호환되어야합니다. 따라서 모든 가능한 시나리오에서 가능한 모든 소프트웨어를 능가하는 소프트웨어 품질에 대한 수학적으로 순수한 정의가 있는지 궁금합니다.

또한 품질에 대한 객관적인 프록시가 대중화되면 비즈니스 압력으로 인해 개발자가 전반적인 품질 (프록시가 측정하지 않는 품질의 측면)을 희생하여 이러한 메트릭을 추구하게 될 것입니다.

품질에 대한 다른 사고 방식은 엔트로피의 관점에서입니다. 엔트로피는 시스템이 질서 상태에서 무질서 상태로 되돌아가는 경향이 있습니다. 실제, 중대 규모 소프트웨어 프로젝트에서 일해 본 사람이라면 시간이 지남에 따라 코드베이스의 품질이 저하되는 정도를 이해할 것입니다. 비즈니스 압력은 일반적으로 새로운 기능 (예 : 항공 전자 공학 소프트웨어에서 품질 자체가 주요 판매 지점 인 경우 제외) 및 회귀 문제를 통한 품질 저하와 '신발 호닝'기능에 맞지 않는 변경에 영향을 미칩니다. 품질 및 유지 관리 관점. 그렇다면 소프트웨어의 엔트로피를 측정 할 수 있습니까? 그렇다면 어떻게?

이것은 위험한 생각입니다. 품질에 대한 "객관적인"프록시는 관리 보상으로 직접 이어지며 개발자는 실제 품질을 희생하면서 이러한 메트릭을 추구합니다.

이것은 의도하지 않은 결과의 법칙입니다.

품질은 중요하지만 소프트웨어의 작은 측면 일뿐입니다. 소프트웨어로 생성 된 기능과 가치는 품질보다 훨씬 중요합니다.

모든 메트릭은 메트릭을 최적화하는 활동으로 이어집니다. 그것은 결국 당신이 정말로 좋아하지 않을 결과를 초래합니다.

소프트웨어는 매우 복잡합니다. 얼마나 복잡한 지 이해하기가 어렵습니다.

단위 테스트 코드 적용과 같은 "분명한"것조차도 시간을 낭비 할 수 있습니다. 100 %가 되려면 실제로 테스트하는 사소한 코드보다 복잡한 테스트를 작성해야 할 수도 있습니다. 100 % 적용 범위에 도달하려면 허용 할 수없는 비용이 발생할 수 있습니다. [사소하고 거의 사용되지 않는 사소한 코드에 대한 대안은 검사 별 테스트입니다. 그러나 이것은 100 %의 메트릭 게임에는 맞지 않습니다.]

또 다른 예로는 Cyclomatic Complexity가 있습니다. 코드 품질의 가장 좋은 척도 중 하나입니다. 그러나 하나의 큰 함수보다 읽기 어렵고 유지하기 어려운 많은 작은 함수를 만들어서 게임을 할 수 있습니다. 읽을 수는 없지만 복잡도 임계 값을 충족한다는 데 동의하는 코드 검토를 시작합니다.

또한 품질에 대한 객관적인 프록시가 대중화되면 비즈니스 압력으로 인해 개발자가 전반적인 품질 (프록시가 측정하지 않는 품질의 측면)을 희생하여 이러한 메트릭을 추구하게 될 것입니다.

빙고, 그것에 대해 "if"가 없습니다. 이것을 "측정 장애"라고하며 , 2002 년 에 하버드 교수의 책을 인용하면서 Joel이 그것에 관한 기사를 쓴 적이 여러 번 관찰되고 쓰여졌습니다 .

그렇다고 그러한 메트릭이 쓸모 없다는 의미는 아니며, 그러한 프록시 측정에 대해 인센티브 나 정책을 명시 적으로 기초해서는 안됩니다. 품질을 향상 시키려면 값이 매우 나쁜 프록시 메트릭을 시작하는 것이 좋습니다. 그러나 모든 측정 항목의 가치가 높기 때문에 품질이 좋다고 결론을 내릴 수 없습니다.

내가 관심이있는 것은 유형의 네트워크 (또는 그래프) 및 관련성, 즉 각 유형이 참조하는 유형과 관련된 더 깊은 품질의 품질 형식이며, 올바르게 관련된 유형의 상호 연결성 클러스터가 있는지 계층 구조, 또는 거꾸로 유형 참조의 큰 '공'( '모 놀리 식'코드)이 있습니다.

팬인 및 팬 아웃처럼 들립니다. 팬인은 주어진 모듈을 호출하는 모듈의 수를 센다. 팬 아웃은 주어진 모듈이 호출 한 모듈의 수를 센다. 사용하기위한 경고 신호는 팬인 및 팬 아웃이 큰 모듈 일 수 있습니다. 이는 불량한 디자인과 리팩토링 또는 재 설계의 주요 목표를 나타낼 수 있기 때문입니다.

또한 각 유형 및 / 또는 방법의 크기 (예 : Java 바이트 코드 또는 .Net IL의 수량으로 측정)는 복잡한 복잡한 알고리즘이 더 관리 가능하고 유지 관리 가능한 것으로 분해되는 대신 모 놀리 식 코드 블록으로 구현 된 위치를 나타냅니다. 덩어리.

간단한 측정은 코드 라인입니다. 전체 프로젝트의 전체 코드 줄과 모듈 당 코드 줄로 나눌 수 있습니다 (아마도 다른 크기의 모듈 사용). 이를 특정 모듈을 검토해야 함을 나타내는 경고 표시기로 사용할 수 있습니다. 소프트웨어 품질 측정 및 메트릭 에 관한 책 은 결함 비율과 모듈 크기 간의 관계가 곡선임을 나타내는 일부 작업에 대해 설명합니다. 여기서 KSLOC 당 평균 결함은 175-350 SLOC 크기의 모듈과 함께 제공됩니다.

좀 더 복잡한 것은 시스템의 테스트 가능성, 이해 가능성 및 유지 관리 성을 나타내도록 설계된 순환 적 복잡성입니다. 순환 복잡도는 애플리케이션 또는 모듈을 통한 독립 경로 수를 계산합니다. 테스트의 수와 테스트를 생성하고 실행하는 데 필요한 노력은 순환 복잡성과 밀접한 관련이 있습니다.

높은 품질과 낮은 품질 사이의 정확한 임계 값 / 결정 점은 주관적이라고 생각합니다. 예를 들어 유지 관리 성으로 인해 인간 프로그래머가 유지 관리 성을 의미하므로 기능적 분해가 인간의 마음이 작동하는 방식과 호환되어야합니다.

나는 그것이 확실하지 않다.

예를 들어, 인간의 작업 메모리는 7 +/- 2 객체 만 보유 할 수 있다는 연구 결과가 있습니다 . 팬인 및 팬 아웃을 측정하는 데 관심이있을 수 있습니다. 모듈에서 작업 중이고 ~ 7 개 이상의 다른 모듈에 연결된 경우 해당 모듈을 정확히 추적 할 수 없습니다. 다른 모듈은 내 머리 속에 있습니다.

사이클로 매틱 복잡성과 같은 메트릭스에 결함을 관련시키는 작업도 진행되어왔다. 시스템의 결함을 최소화하고자하므로 사이클로 매틱 복잡성이 높을수록 테스트 또는 리팩토링에 더 많은 노력이 필요한 지점을 식별 할 수 있습니다.

또한 품질에 대한 객관적인 프록시가 대중화되면 비즈니스 압력으로 인해 개발자가 전반적인 품질 (프록시가 측정하지 않는 품질의 측면)을 희생하여 이러한 메트릭을 추구하게 될 것입니다.

모든 측정 또는 메트릭의 경우입니다. 시스템을 이해하고 정보에 입각 한 결정을 내리는 데 사용해야합니다. "측정 할 수없는 것을 관리 할 수 ​​없습니다"라는 문구가 떠 오릅니다. 고품질 소프트웨어를 원하는 경우 해당 품질을 평가하기위한 측정 및 메트릭이 필요합니다. 그러나 이에 대한 반대 측면이 있습니다. 숫자로만 관리 할 수는 없습니다. 숫자를 사용하여 정보에 근거한 결정을 내릴 수 있지만 숫자가 그렇게해서 만 결정을 내릴 수는 없습니다.

관심있는 여러 가지 특성에 대한 메트릭 또는 프록시가 있습니다.

1. 코드 라인
2. 팬인, 팬 아웃
3. 1000 줄의 코드 당 오류율
4. 순환 복잡성
5. 코드 범위
6. 결정 포인트 범위
7. 유지 보수 활동으로 수정 / 도입 된 오류 비율
8. 기능 점 분석

이 모든 항목에는 몇 가지 문제가 있습니다.

1. 메트릭을 최적화하기 위해 수행되는 작업-보편적 인 추세; 팀 또는 개인에 대한 평가 또는 보상의 기준으로 메트릭이 사용되는 경우 엄청나게 악화됩니다.
2. 컨텍스트가없는 메트릭은 알 수 없습니다. 이는 시간이 지남에 따라 상점 내에서만 비교할 수 없음을 의미합니다. 이러한 비교에서 비롯된 지표는 여전히 유용합니다. "1 년 전보다 코드를보다 정확하게 생성하고 있습니다".

이러한 문제의 총 효과는 TQM, 품질 보증 (통제 아님), 지속적인 개선, 카이 잔 등과 같이보다 광범위한 문화권 내에서만 가치가있을 가능성이 높다는 것입니다. 두 문화의 요소를 정의해야합니다. 변경 방법 이러한 정의가 있으면 코드 품질, 실무 관행, 생산성 등을 향상시키는 데 도움이되는 필수 도구가됩니다. 이러한보다 광범위한 컨텍스트가 없으면 메트릭이 메트릭을 최적화하는 작업을 생성합니다. 생산성을 높이고 비용을 줄이기 위해 콩 카운터의 도구가 될 것입니다. 개발 직원이 게임을하는 데 장애가 될 것입니다.

측정 항목에 집착하거나 엔지니어링을위한 최고의 인력, 도구, 관행 및 QA에 집착 할 수 있습니다. 'Fooled by Randomness'를 읽었으며 숫자가있는 멋진 형식의 보고서보다 자동화하고 싶은 몇 가지 편집증 QA 천재가있는 것이 훨씬 더 행복합니다.

측정 항목에이 근본적인 문제가 있습니다.

실제 코드에서 제안 된 거의 모든 메트릭은 원시 SLOC (소스 코드 라인)와 강력하거나 매우 밀접한 상관 관계가있는 것으로 나타났습니다.

이것이 1970 년대에 Halstead의 지표를 죽인 것입니다. (언젠가 1978 년경 우연히, 나는 Halstead의 측정 항목에 대해 새로운 박사 학위에서 이야기를 나 he습니다. 그는 이것을 지적했습니다.)

최근에 McCabe의 순환 복잡도는 원시 SLOC와 매우 밀접한 상관 관계가있는 것으로 나타 났으며, McCabe의 메트릭이 우리에게 유용한 것을 말하면 연구를 한 사람이 크게 궁금해하는 시점까지 나타났습니다.

우리는 수십 년 동안 큰 프로그램이 작은 프로그램보다 문제가있을 가능성이 높다는 것을 알고 있습니다. 우리는 수십 년 동안 큰 서브 루틴이 작은 서브 루틴보다 버그를 갖는 경향이 있음을 알고있었습니다. 테이블 위에 펼쳐져있는 4 개의 프린터 페이지를 볼 때 충분히 설득력이 있어야하는 이유는 무엇입니까?

여기에 다른 모든 대답이 주어지면이 작은 것에 대해 바보 같은 느낌이 들었습니다. Crap4j를 살펴보십시오.이 메소드는 얼마나 많은 냄새가 나는지 Java로 메소드 순위를 지정하려고합니다. (프로젝트가 버려진 것 같습니다.)

순환 복잡성과 테스트 범위의 조합을 사용합니다. 다른 모든 메트릭과 마찬가지로 게임 가능합니다.