경험적 메트릭을 기반으로 소프트웨어가 좋은지 나쁜지를 어떻게 알 수 있습니까?

현재 5 개월 전에 핵심 개발이 완료되었지만 여전히 높은 수준의 결함이있는 프로젝트를 조사해야합니다. 약 10 개의 결함이 수정 될 때마다 발생하는 문제는 최소 4 개, 경우에 따라 8 개가 발생합니다.

벤더의 코딩 관행이 좋지 않다고 생각하며 이에 대한 일반적인 합의가 있습니다. 그러나 소프트웨어에 구조적 문제가 있는지 궁금합니다. 결함 밀도는 유용한 측정 방법이지만 핵심 소프트웨어가 잘못 작성된 경우 더 많은 공급 업체가 문제를 해결하고 있습니다.

인프라에서 무언가 잘못 구축 된 경우, LOC 당 결함 외에 어떤 측정을 소프트웨어에 사용할 수 있습니까?

제품이 4 개월 동안 결함 수정 단계에 있으며 여전히 중요한 결함을 해결하지 못했습니다. 우리는 새로운 기능을 주입하지 않고 회귀 문제를 해결합니다.

이는 만족스럽지 않은 개발 품질 문제를 나타냅니다. 그러나 제품 자체에 근본적인 결함이 있으면 다른 문제입니다. 핵심 코드 기반이 잘못 작성되어 문서화가 제한되는 것에 대한 우려는 모든 외부 개발자가 문제를 A에서 B로 옮기는 것입니다. 내부 개발 팀이 인수 한 후에는 코드를 근본적으로 다시 작성해야 할까 걱정됩니다. 작동 시키십시오.

따라서 타사의 제품을 수락하고 지원하도록 요청하면 표준을 정의하기 위해 어떤 수락 기준을 사용 하시겠습니까?

리드 개발자가 릴리스 당 코드를 피어 검토하도록하는 것 외에 다른 작업을 수행 할 수 있는지 확실하지 않습니까?

당신은하지 않습니다.

소프트웨어 품질은 객관적으로 측정하기가 어렵습니다. 해결책이 없을 정도로 힘들다. 나는이 대답에서 전혀 해결책이있을 수 있는지에 대한 질문에 손을 대지 말고 하나를 정의하는 것이 왜 정말로 어려운지 지적하십시오.

현 상태에 의한 추론

Kilian Foth가 지적했듯이 "좋은"소프트웨어에 대한 간단한 조치가 있다면 모두 사용하고 있으며 모든 사람들이 요구할 것입니다.

관리자가 특정 지표를 시행하기로 결정한 프로젝트가 있습니다. 때로는 효과가 있었고 때로는 효과가 없었습니다. 중요한 상관 관계는 없습니다. 특히 중요한 시스템 소프트웨어 (비행기, 자동차 등)는 SW 품질을 "보장"하기위한 많은 메트릭 요구 사항을 가지고 있습니다. 이러한 요구 사항이 실제로 더 높은 품질을 가져온다는 것을 보여주는 연구는 없습니다. 반대로.

반 지능에 의한 추론

또한 Kilian은 이미 힌트를 받았고 더 일반적으로 "모든 메트릭은 재생할 수 있고 재생됩니다"라고 말합니다.

메트릭을 재생한다는 것은 무엇을 의미합니까? 개발자를위한 재미있는 게임입니다. 메트릭 값이 정말 좋아 보이는 동시에 정말 까다로운 작업을 수행 할 수 있습니다.

LOC 당 결함을 측정한다고 가정 해 봅시다. 어떻게하면 되나요? 쉬움-더 많은 코드를 추가하십시오! 100 줄 이상 작동하지 않는 어리석은 코드를 만들고 갑자기 LOC 당 결함이 줄어 듭니다. 무엇보다도 : 실제로 소프트웨어 품질을 저하 시켰습니다.

도구의 단점이 남용되고 정의가 최대로 확장되고 완전히 새로운 방식이 발명되었습니다. 기본적으로 개발자는 정말 똑똑한 사람이며 팀에서 재미있는 메트릭스를 가진 한 명의 개발자 만 있으면 메트릭스에 의문이 생길 수 있습니다.

그렇다고 메트릭이 항상 나쁜 것은 아닙니다. 그러나 이러한 메트릭에 대한 팀의 태도는 매우 중요합니다. 특히 이는 하도급 업체 / 타사 공급 업체 관계에서 제대로 작동하지 않음을 의미합니다.

잘못된 타겟팅으로 추론

측정하려는 것은 소프트웨어 품질입니다. 측정하는 것은 하나 이상의 메트릭입니다.

당신이 측정하는 것과 그것이 당신에게 말할 것이라고 믿는 것 사이에는 차이가 있습니다. 이 격차는 거대합니다.

그것은 우리 주변의 모든 종류의 사업에서 항상 발생합니다. KPI (핵심 성과 지표)를 기반으로 한 결정을 본 적이 있습니까? 그것은 단지 똑같은 문제입니다-회사가 잘하기를 원하지만 다른 것을 측정하십시오.

정량화에 의한 추론

측정 항목을 측정 할 수 있습니다. 이것이 우리가 전혀 다루지 않는 유일한 이유입니다. 그러나 소프트웨어 품질은 측정 가능한 엔터티를 넘어서서 정량화하기가 매우 어렵습니다. 소스 코드는 어떻게 읽을 수 있습니까? 디자인은 얼마나 확장 가능합니까? 신입 팀원이 탑승하기가 얼마나 어려운가요? 등

측정 항목으로 만 소프트웨어 품질을 판단하고 정량화 할 수없는 품질 부분에 대해 눈을 돌리는 것은 확실히 잘되지 않을 것입니다.

편집하다:

요약

위의 모든 사항은 메트릭스를 기준으로 소프트웨어의 우수 여부를 객관적으로 판단하는 것입니다. 즉, 메트릭 적용 여부와시기에 대해서는 아무 것도 말하지 않습니다.

실제로 이것은 단방향 적 의미입니다. 잘못된 메트릭은 잘못된 코드를 의미합니다. 단방향은 잘못된 코드가 잘못된 메트릭을 보장하지 않으며 우수한 메트릭이 올바른 코드를 보장하지 않음을 의미합니다. 반면, 이는 자체적으로 의미를 유지할 때 메트릭을 적용하여 소프트웨어를 판단 할 수 있음을 의미합니다.

소프트웨어 A를 측정하면 메트릭이 실제로 나쁩니다. 그러면 코드의 품질이 나쁘다는 것을 확신 할 수 있습니다. 소프트웨어 B를 측정하고 메트릭이 정상이면 코드 품질에 대한 실마리가 없습니다. 실제로 "code good => metrics good"일 때 "metrics good = code good"이라는 생각에 속지 마십시오.

본질적으로 메트릭을 사용하여 품질 문제를 찾을 수 있지만 품질 자체는 찾을 수 없습니다.

예, 메트릭을 어느 정도 살펴봄으로써 코드에 품질 문제가 있음을 알 수 있습니다.

보다 구체적으로, 코드 기반에서 복잡성 분석 도구를 실행하면 코드의 우수성 여부를 알 수 있습니다.

예를 들어 source monitor를 실행할 수 있습니다 .

이것이 당신에게 말할 것은 코드가 얼마나 복잡한 지입니다. 내가 경험 한 모든 문제가있는 시스템에 불량 번호가 있다고 말할 수 있습니다. 수용 가능한 한계를 넘어서는 10에서 100까지의 방법의 복잡성. 끔찍한 숫자. 끔찍한 복잡성, 중첩, 깊이 등. 이로 인해 많은 문제가 발생하고, 높은 결함률이 지속적으로 발생하며, 변경하기가 어렵고, 다른 것을 깨뜨리지 않습니다.

또 다른 것은 결함입니다. 시간이 지남에 따라 시스템이 안정화되어야합니다. 이상적으로는 새로운 결함이 0으로 향하거나 적은 수로 평평해야하므로 시간이 지남에 따라 새로운 결함과 현재 결함이 감소해야합니다.

줄거리는 다음과 같아야합니다.

시간이 지남에 따른 결함

이들이 일정하게 유지되거나 증가하면 소프트웨어가 좋지 않습니다. 당신의 4 개월 밖에 걸리지 않아서 몇 달에서 1 년 더 줄 것입니다. 6 개월에서 1 년이 지나도 지속적으로 결함이 발생하면 품질이 떨어집니다. 당신의 팀은 또 다른 진흙 공을 개발했습니다 .

다음 테스트. 그것들이 있습니까? 그렇다면 품질이 떨어지고 버그가 많고 이탈이 심합니다. 코드 범위가있는 경우 코드 범위와 같은 메트릭을 사용하여 코드의 양을 파악할 수 있지만 품질을 측정하지는 않습니다 . 훌륭한 코드 적용 범위 번호를 보았지만 실제 테스트는 엉망이었습니다. 그들은 시스템의 동작이나 기능을 테스트하지 않았습니다. 개발자는 관리를 위해 지표 수를 개선하기 위해 작성했습니다. 그래서 당신 은 테스트를 받아야하고 잘되어야합니다. 코드 커버리지 메트릭 자체는 품질을 나타내는 지표가 아닙니다.

코드 검토, 수행 중입니까? 그렇지 않으면 품질이 떨어집니다. 이것은 주니어 개발자들에게 특히 중요합니다. 민첩한 작업을하는 경우 스토리에 "code review"라는 코드 검토 작업을 추가하십시오. 경영진이 숫자를 추적하려면 Crucible 과 같은 검토를 추적하는 도구가 필요합니다 . 코드 검토 번호 또는 메트릭은 프로세스의 일부가되어야한다는 사실 외에는 중요하지 않습니다. 모든 체크인에 검토가 필요한 것은 아닙니다. 그러나 리뷰를 통해 사람들이 이해하거나 유지 관리 할 수없는 휠을 다시 만들거나 코드를 작성하지 않도록 할 수 있습니다.

마지막으로, 코드를 평가해야하는데, 어떤 지표도 도움이되지 않습니다. 문제가있는 모든 코드 프로젝트에는 다음과 같은 특성이 있습니다.

• 열악한 데이터 구조. 모든 것이 문자열이거나 XML이 모든 곳으로 전달되어 모든 곳, 신 개체 또는 불필요하게 복잡하거나 일반적인 데이터 구조로 구문 분석됩니다 (도메인 모델 없음).
• 조직이나 구조가 부족하여 사소하지 않은 프로젝트는 논리를 분리하는 부분 또는 계층이 있어야합니다. 여기를 살펴보십시오 ...이 유형의 조직 또는 분리 (모든 곳에서 논리 혼합)가 보이지 않으면 시스템을 유지 관리하고 이해하기가 더 어려워집니다.
• 추상화 이상. 때로는 그 반대가 사실이고, 시스템은 추상화되었습니다. 모든 것이 인터페이스 및 추상 클래스이거나 많은 클래스 "래퍼"유형 클래스를 탐색해야하는 경우, 새로운 개발자가 오브젝트 팽창을 탐색 할 수 없기 때문에 품질이 떨어집니다.
• 코드를 이해하기 어렵습니다. 노련한 개발자이고 이해하기 어려운 코드를보고 있다면 품질 문제가있을 수 있습니다. 내 개인 측정 기준은 코드를보고 있고 열심히 따르거나 바보 같은 느낌을 주거나 논리를 알아 내기 위해 많은 두뇌주기를 낭비하고 있다고 생각하면 나쁜 코드입니다. 노련한 개발자가 다음과 같은 어려움을 겪고 있다면 새로운 개발자에게 어떤 모습 일지 상상해보십시오. 그들은 문제를 일으킬 것입니다.

내 조언은 코드에서 복잡성 분석을 실행하는 것입니다. 결과를 공유하지 말고 결과에 대한 후속 조치를 수행하여 독립적 인 조사를 수행하고 (코드를 살펴보십시오) 코드 기반의 전반적인 상태를 결정하십시오. 이것으로부터 행동 계획을 세우고 코드의 복잡한 부분을 개선해보십시오.

측정 항목의 슬픈 점은 측정 값의 결과 값을 향상시킬 수 있지만 측정하려는 품질은 아닙니다.

Visual Studio에는 컴파일러 경고를 오류로 처리하기위한 설정이 있습니다. 이제 일부 사람들은 경고를 이해하지 못하고 코드를 컴파일하려면 간단한 방법을 사용합니다 (예 : 'pragma disable warning'또는 'virtualal base의 비가 상 구성원을 숨기는 함수 / 프로퍼티에'new '키워드 추가) 수업).

소스 코드에 액세스 할 수 있으면 정적 코드 분석을 실행할 수 있습니다. .Net 프로젝트의 경우 FxCop 또는 ReSharper InspectCode 등을 사용할 수 있습니다. 개발 팀에서 올바르게 사용하면 도구를 사용하여 품질을 개선 할 수 있습니다. 그러나 물론 경고를 이해하지 않고 제거하기위한 일부 "수정"이 가능합니다.

자동화 된 테스트 / UnitTests를 볼 수 있습니다 : 코드 적용 범위는 어느 정도입니까? 그러나 적용 범위만으로도 테스트에서 실제로 코드를 확인했는지 아니면 한 번만 실행했는지 알 수 없습니다.

고품질을 위해 노력하는 것은 많은 도구와 해당 메트릭에서 지원할 수있는 태도이지만 개발자의 태도가없는 메트릭은 도움이되지 않습니다.

결함 주입과 같은 메트릭을 수집하는 것 외에도 결함의 원인을 파악하는 것이 중요합니다. 종종 사양과 관련이 있습니다.

기본적으로, 사양에서의 모호성, 구체화의 모호함은 임플란트가 결정에 남았거나 구현상의 버그입니까?

더 정성적인 접근 방법은 소프트웨어가 유용한가? 충분히 단단하면 모든 소프트웨어에서 결함을 찾을 수 있습니다. 그러나 돈을 벌 수있을만큼 잘 작동한다면 그렇게 나쁘지 않을 수 있습니다.

하단에는 알 방법이 없습니다.

원래의 질문에 대한 (철학적 대답 전) : 제품은 무엇을해야합니까? 결함 수 / 밀도로 측정하는 것만으로는 충분하지 않습니다. 이것이 라이브러리인지 응용 프로그램인지, 코드베이스의 크기, 문제의 도메인의 크기 또는 결함의 심각도를 알 수 없었습니다. 예를 들어, 123 개의 입력 형식 중 하나를 처리하지 않으면 형식이 올바르게 처리되지 않은 중요성에 따라 사소한 결함이나 쇼 스토퍼가 될 수 있습니다. 그리고 아무것도없는 것보다 높은 기준이 있습니다.

이 질문에 대한 가정 : 코드와 소프트웨어에는 차이가 있습니다. 소프트웨어를 클라이언트 / 사용자가 문제를 해결하기 위해 사용하는 것으로 정의하지만 코드는 소프트웨어의 건축 자재입니다.

소프트웨어는 주관적으로 만 측정 할 수 있습니다. 즉, 소프트웨어에 중요한 메트릭은 사람들이 소프트웨어를 사용하여 문제를 해결하는지 여부입니다. 이 지표는 다른 사람의 행동에 따라 달라 지므로 주관적으로 결정됩니다. 참고 : 일부 문제의 경우 일부 소프트웨어가 매우 유용 할 수 있으므로 고품질 (계산 용 Excel)로 간주되지만 다른 문제 (MP3 파일 재생 용 Excel)는 아닙니다.

코드는 일반적으로 경험적 지표로 측정 할 수 있습니다 . 그러나 품질에 대한 해석은 '예 / 아니오'가 아니거나 실제로 '0에서 N'까지입니다. 메트릭은 표준을 기준으로 측정합니다. 따라서 측정 항목은 표준에 의해 정의 된 관심 영역을 찾을 수 있지만 관심 영역이 없다고해서 이것이 품질 코드라는 증거는 아닙니다. 예를 들어, 유용한 메트릭 : 컴파일됩니까? 아니오-> 품질이 아닙니다. 예-> ???. 단위 테스트를 통과합니까? 아니? 아마도? (단위 테스트 품질 코드인가?), 예-> ???.

따라서 Godel의 불완전 성 증명이 수학의 공리에 대해 보여 주듯이 (즉, 유한 공리에 대해서는 사실 또는 거짓으로 입증 될 수없는 수학적 진술이 있음) 실제로 우리가 실제로 대답 할 수는 없다고 생각합니다. 암호?' 모든 코드 조각에 대해. 직관적으로, 품질에 응답하기위한 소프트웨어 메트릭과 사실 또는 거짓으로 대답하기위한 수학적 공리 사이에 매핑이있을 수 있습니다.

이 주장을하는 또 다른 방법은 자연 언어로 들어가는 것입니다. 윌리엄 셰익스피어, 루이스 캐롤, 마크 트웨인은 모두 저술가였으며 작문의 질 때문에 많은 사람들의 사랑을 받았습니다. 그러나 임의의 12 학년 학생들보다 일관되게 높은 문법, 어휘, 스타일 또는 음성 표준을 적용 할 수있는 표준은 무엇입니까? 이 세 가지에 대한 종합적인 척도를 만들 수는 있지만, 요한 복음 (JJV), JRR 톨킨, 호머, 세르반테스 등을 어떻게 평가할 수 있습니까? 그런 다음 Burroughs, Faulkner, Hemingway, Sylvia Plath 등을 던지십시오. 메트릭이 작동하지 않습니다.

프로세스를 감사하고 편차를 찾아서이를 측정합니다.

중앙 소스 제어, 중앙 빌드 시스템 및 릴리스 된 분기에 통합하기 전에 코드를 테스트하는 프로세스를 제공하는 프로세스의 증거를 찾고 있습니다.

또한 결함이 릴리스 프로세스를 통과 한 상황에 대응하여 프로세스가 어떻게 수정되었는지에 대한 증거를 찾고 있습니다.

이 수준의 감사를 통과 할 수없는 경우 일관되고 안정적인 릴리스를 제공 할 수 없습니다.

그들이이 감사를 통과하고 지속적으로 프로세스를 개선하고 있다면 시간의 흐름에 따라 결과의 일관성이 향상 될 것입니다.

이렇게해도 문제가 해결되지 않으면 현재 코드 기반을 확장하고 테스트하는 데 문제가있는 코드 아키텍처 문제 일 가능성이 높습니다.이 경우에는 좋은 옵션이 없습니다.

완전 자동화 된 측정을 원한다면 다음 사항을 권장합니다. Software Improvement Group

기본적으로 소스 코드에서 자동으로 추출 할 수있는 다양한 메트릭의 집계입니다 (예 : 단위 테스트 적용 범위, 함수 크기, 클래스 얽힘, 복제, LOC 등). 그런 다음이 값은 1-5 개의 별 등급으로 변환됩니다.

또한 실제로 유지 보수가 가능한 소프트웨어 구축 이라는 읽을 가치가있는 모든 지표를 설명하는 적절한 책을 보유하고 있습니다.