팀 프로젝트에 대한 외부 조언을 원하는 개발자를 만났습니다. 회사 임원, 프로젝트 관리자 및 개발자를 위해 자동으로 메트릭을 계산하고 반복마다 그래프를 그릴 수있는 거대한 소프트웨어 제품군을 개발하고 있음을 알게되었습니다.
컴퓨터 과학을 전공 한 학생으로서 저는 메트릭스와 그 중요성에 대해 거의 알지 못하지만 제 질문은 다음과 같습니다.
이유가 확실하지 않지만 개발자 프로젝트가 흥미를 느끼고 더 알아야합니다. 만약 y
답변:
대학 도서관에있을 수있는 메트릭에 대한 일부 책에는 소프트웨어 품질 엔지니어링의 소프트웨어 메트릭 및 메트릭 및 모델 이 포함됩니다 . 그 2는 당신에게 출발지를 제공해야합니다. 산업계에서는 거의 모든 종류의 미터법 측정 프로그램을 보유한 회사가 거의 없습니다.
의미있는 측정 항목을 측정하기 위해 대부분의 회사에 어떤 방법이 있습니까? 우아한 프로그램 일 필요는 없습니까?
Visual Studio에는 시작할 수있는 코드 분석 도구가 포함되어 있습니다. 대부분의 회사는 가능한 최악의 측정 기준 인 코드 줄조차도 가지고 있지 않습니다. "그냥해라"는 업계에서 압도적 인 원동력 인 것으로 보이며, 유지 보수성에 대한 우려는 "올해 보너스를받을 수 있을까요?"라는 관리자의 우려에 매우 짧은 관심을받습니다. "내가 약속 한 시간에이 일을 할 것입니까?" 점진적으로 변경되는 해마다 제품이 출시 되더라도 이러한 두 가지 문제는 개발자의 유지 관리 성 및 버그 탐지 / 예방에 대한 우려를 뒤 떨어지게합니다.
단일 또는 결합 된 어떤 메트릭이 프로젝트 범위와 추정치를 좁히는 데 도움이됩니까?
나는 찾을 복잡성을 하고 커플 링이 어떻게 버그 또는 얼마나 어려운 코드가 될 것입니다 유지하는 강력한 지표입니다. 순환 복잡성이 약 20 인 경우 테스트하는 것이 거의 불가능하며 (코드를 통해 최대 2 ^ 20 경로를 가지므로) 더 작은 조각으로 분해되어야합니다. 복잡성을 제거 할 수는 없지만보다 관리하기 쉬운 덩어리로 분할 할 수 있습니다.
추정값을 찾고 있다면 기능 점 을 조사하고 싶을 것입니다 .
코드 범위 %는 각 반복을 크게 낮추고 있습니다. 개발자에게 문제를 경고합니까?
대부분의 관리자는 체크인 횟수와 수정되는 버그 수에 관심을 가지고 있습니다. 저의 현재 관리자는 단위 테스트에 반대하고 (시간 낭비라고 생각합니다) 이전의 관리자는 단위 테스트에 소요되는 시간이 처음에 작성해야했던 시간이라고 생각했습니다.
개발자가 사용하는 정식 논쟁은 무언가를 측정하면 얻을 수있는 것뿐이라는 것입니다. 이 주장은 유일한 메트릭이 코드 라인이라는 아이디어에서 비롯됩니다.
In the industrial world, very few companies have any sort of metric measurement program at all.CMMI 등급이 2 이상인 모든 회사에는 측정 / 메트릭 분석 프로그램이 있습니다. 측정 및 메트릭 수집은 성숙도 레벨 2 요구 사항입니다. CMMI Maturity Level 4는 측정 및 측정 항목을 기반으로 한 정량적 프로젝트 관리와 확인 된 문제에 대한 근본 원인 분석과 같은 것들을 요구합니다. CMMI 레벨 4 (또는 5) 등급으로 평가 된 많은 조직이 있습니다.
나는 스피커가 IMHO, 통찰력있는 포인트를 만들어 낸 소프트웨어 메트릭스에 대해 이야기했다. 이런 일들에 대한 경험이 거의 없지만, 나는 여전히 음모와 영감을 얻었지만 그것이 잘못되었는지 옳은지는 말할 수 없습니다.
주요 아이디어는 다음과 같습니다.
그래서 이것을 해결하려면 :
이런 식으로 티켓이 빠르게 수정되면 코드 품질이 저하되는지 확인할 수 있습니다. 또한 버그 데이터베이스에서 많은 일이 일어나지 않는 것처럼 보이면 리팩토링이 수행되면서 코드 품질이 향상 될 수 있습니다.
요약 : 중요한 것은 이러한 유형의 동적 동작 이며 원시 데이터 (단일 메트릭의 값)가 아닌 정보를 제공 하는 것입니다.
CI 연결 용암 램프 옆의 와이드 스크린 TV에이 구성표에 따라 몇 가지 그래프를 표시 할 계획입니다. ;)