코드 검토 프로세스의 효과를 확인하는 방법은 무엇입니까?

조직 내에서 코드 검토 프로세스를 도입했으며 제대로 작동하는 것 같습니다. 그러나 시간이 지남에 따라 프로세스의 효과를 측정 할 수 있기를 원합니다. 즉, 코드가 깨끗하거나 사람들이 버그를 찾지 않기 때문에 버그를 찾지 못하고 있습니까?

현재 효과적인 완전 자동화 테스트 프로세스가 없습니다. 우리는 주로 수동 테스트를 사용하므로이 단계에서 발견 된 결함에 의존하여 코드 검토 프로세스가 작동하는지 확인할 수 없습니다.

코드 검토를 측정하는 데 무엇이 효과적입니까?

코드 검토에서 수집 할 수있는 여러 가지 메트릭이 있으며 일부는 프로젝트 수명주기 내내 확장 될 수도 있습니다.

수집을 권장하는 첫 번째 메트릭은 결함 제거 효과 (DRE) 입니다. 모든 결함에 대해 결함이 도입 된 단계와 제거 된 단계를 식별합니다. 사용하는 다양한 결함 감지 기술은 모두 동시에 평가되므로 요구 사항 검토, 설계 검토, 코드 검토, 단위 테스트에 동일하게 적용됩니다. , 등등. 코드 단계에서 발견 된 결함 수에 특히 관심이있을 것입니다. 이는 코드 검토뿐 아니라 단위 테스트를 포함하기 때문입니다. 코드 단계의 많은 결함이 통합 테스트 단계 또는 현장까지이를 해결하는 경우 코딩 후 사례를 평가해야합니다.

다양한 회의 측정 항목도 관련이 있습니다. 여기에는 준비 시간, 회의 시간, 코드 라인 읽기, 검토에서 발견 된 결함 등이 포함됩니다. 이 데이터에서 일부 관찰이 가능합니다. 예를 들어, 검토자가 검토를 위해 코드를 읽는 데 많은 시간을 소비하지만 문제가 거의없는 경우가 있습니다. DRE 데이터와 함께 통합 테스트 또는 현장에서 결함을 테스트하는 경우 팀은 문제를 찾기 위해 검토 기술에 집중해야한다는 결론을 내릴 수 있습니다. 또 다른 흥미로운 메모는 회의 시간과 비교하여 회의에서 읽은 코드 라인 (또는 다른 크기 측정)입니다. 연구에 따르면 일반적인 코드 검토 속도는 시간당 150 줄입니다.

이러한 메트릭 중 하나를 사용하면 프로세스에 미치는 영향을 이해하는 것이 중요합니다. why-because , Five Whys 또는 Ishikawa 다이어그램 과 같은 기술을 사용한 근본 원인 분석을 사용하여 코드 검토 (또는 기타 품질 개선 기술)가 효과적인 이유를 식별 할 수 있습니다.

또한 Ganssle Group의 검사 및 결함 가능성 및 DRE에 대한 Crosstalk의 Capers Jones 기사에 대한이 기사에 관심 이 있을 수 있습니다 .

크게 있지만 사실입니다 코드 검토가 오히려 시험 또는 캐치하지 않을 수도 있음을 잠재하고 있습니다 문제를 데리러 것입니다. 그러나 내 의견으로는 당신은 정말로 안정적인 (실제로 버그가없는) 코드를 가지고 있지만 여전히 읽을 수 없거나 유지 보수가 불가능한 방식으로 작성되었습니다. 이 코드 리뷰는 수 할 수 있도록 NOT 코드에서 실제로 진짜 문제가없는 경우 버그를 찾을 수 있습니다.

그런 말을 한 후에 왜 코드 검토를 원할까요? 중요한 이유는 코드를보다 읽기 쉽고 유지 보수 가능하며 발전시킬 수 있도록 개선해야하기 때문입니다. 많은 사람들이 더 깨끗한 코드를 읽고 이해할 수 있어야합니다. 그런 의미에서 코드 검토 프로세스의 가장 간단한 목표는 깨끗한 코드를 생성하는 것입니다. 따라서 효과의 척도는 현재 코드가 얼마나 깨끗한 지입니다.

측정 가능한 효과를 원했던 것처럼 여기에 내가 제안하는 것이 있습니다.

1. 재 작업량 관련 메트릭-동일한 모듈 / 개체 / 작업 항목에 동일한 재 작업이 적용되는 시간은 해당 코드가 유지 관리 성 측면에서 얼마나 열악한 지를 측정 한 것입니다 . 효과적인 코드 검토가 적용되면 동일한 모듈에서 재 작업 요청을 얼마나 자주 줄일 수 있습니까?

2. 모든 변경 요청이 발생하는 변경 양과 관련된 메트릭입니다. 변경 요청이 발생할 때마다 팩토링 이 잘못된 코드는 항상 더 많은 수의 모듈에 영향을 미칩니다. 법안은 코드 검토 후 과거에 유사한 변경 요청에 대한 그러한 변경 확산 이 감소했음을 나타냅니다 .

3. 변경 요청에 응답 할 수있는 평균 속도와 관련된 메트릭입니다. 코드가 더 깨끗하고 빠를 때는 필요한 변경에 응답하는 것이 좋습니다. 검토 과정에서 코드를 정리 한 후 비슷한 크기의 요청에 응답하면 속도가 빨라집니다.

정확한 측정 단위를 사용하지는 않습니다.이 방법을 사용하면 이에 대한보다 정확한 측정을 수행 할 수 있습니다. 이에 대한 위의 접근법에는 더 많은 확장 형식이있을 수 있습니다.

기본적으로 필자의 요점은 코드 검토 프로세스가 식별하는 버그의 수를 보는 대신입니다. 우리는 코드 검토가 코드를보다 깨끗하고 간결하며 유지하기 쉬운 상태로 만들 수 있는지 여부에 대한 효과를 측정해야합니다. 따라서 향후 유사한 변경 요청이보다 효율적으로 대응할 수 있다면 효율성을 측정 할 수 있습니다.