코드 검토에 할당 된 시간

코드 검토를 수행중인 경우

• 구현에 비해 코드 검토에 얼마나 많은 시간을 소비합니까?
• 얼마나 많은 변경이 코드 검토를 받습니까?
• 당신은 그것이 더 많은 것이어야한다고 생각합니까?

효과에 대한 연구가 있습니까?

[편집] 모든 답변에 감사드립니다. 그런 질문에 대해 "우승자"를 선택하기는 어렵습니다. 다른 답변에도 귀중한 정보가 많이 있습니다.

저의 작업에는 다음과 같은 코드 검토 절차 가 있습니다. 그것은 지금까지 우리에게 잘 작동했으며, 우리는 특히 시간으로 매우 시간 효율적이라는 것을 알았습니다. 리뷰에 할당 된 특정 시간이 없습니다. 트렁크에 대한 모든 커밋 또는 병합을 검토해야하며 검토자가 확인하기까지 시간이 걸립니다.

편집 : 물론 걸리는 시간은 변화의 규모에 달려 있습니다. 작은 기능과 버그 수정에는 몇 분이 걸립니다. 시스템의 많은 부분에 영향을 미치는 대규모의 새로운 기능, 리팩토링 또는 변경 사항은 검토하는 데 반나절이 걸리고 결과적으로 발생하는 모든 문제를 해결하는 데 하루가 걸릴 수 있습니다.

이 시스템이 작동하려면 트렁크에 자주 커밋하여 변경 사항을 관리 할 수 ​​있도록하는 것이 중요합니다. 1 년 동안 누군가의 코드를 검토해야 할 상황을 원하지 않습니다.

연구와 관련하여 Smart Bear 소프트웨어는 Peer Code Review의 Best Kept Secrets 라는 작은 책 을 무료로 보내드립니다 . 여기에는 코드 검토의 다양한 측면에 대한 많은 기사가 포함되어 있습니다. 여기에는 시간과 소요 시간에 대한 연구가 포함됩니다.

프로젝트에서 시스템에 대한 모든 중요한 변경 사항은 팀 리더 또는 새로운 모듈의 주요 "소비자"가 될 다른 개발자와 함께 검토합니다. 스카이프에 대해 이야기하고 Emacs에서 Rudel (협업 편집 용 플러그인, 기본적으로 여러 사용자가 동일한 파일을 실시간으로 편집 할 수 있음) 또는 TypeWith.me (Piratepad)를 사용하거나 우리 중 한 사람이 스카이프에서 자신의 화면을 공유합니다.

새로운 조회수, 페이지 등의 일상적인 변경 사항은 검토되지 않기 때문에이를 정량화하기는 어렵습니다. 새로운 모듈, 주요 업데이트 및 리팩토링을 검토합니다. 큰 변화에 대해서는 코드 검토에 10 ~ 30 %의 시간이 걸릴 수 있지만 그만한 가치가 있습니다.

나는 두 명의 프로그래머가 같은 컴퓨터에 앉아있는 것이 아니라 같은 파일을 동시에 편집 할 때 페어 프로그래밍이라고 말할 수있다. 어깨 뒤에 앉아있는 일반적인 사무실 관행보다 훨씬 낫다.

명명 규칙 및 범위 오류와 같은 간단한 작업을 위해 자체 또는 오픈 소스 자동 도구 (jslint, pylint, pyflakes, pep8)를 사용합니다. 우리는 커밋과 푸시를 제한하지 않습니다 : 우리는 분기와 병합이 매우 쉬운 Mercurial을 사용합니다 (Git보다 쉽습니다). 버그는 코드 검토 문제가 아닙니다.

우리는 변화와 새로운 것들이 발표되는 팀 회의를하지만 모든 사람들이 실제로주의를 기울이지는 않습니다. 아마도 우리는 좀 더 코드를 검토해야 할 것입니다.

이것에 대한 옳고 그른 대답은 없습니다. 그러나 나보다 많은 사람들이 제안한 것처럼 – 외부 팀 구성원이 권장하는 방법으로 코드 검토를 수행하는 경우 개발 노력의 약 30 % ~ 35 % 에이를 수 있습니다. 그러나 이것이 개발 팀의 일원 인 내부 프로젝트 팀원에 의해 수행되면 [권장되지 않음] 이것은 개발 노력에 소요되는 시간의 약 20 % 이내에 완료 될 수 있습니다 .

참고 : 다른 것을 검색 할 때이 스레드를 발견했으며 여기에 값을 추가 할 수 있다고 생각했습니다. Btw, 위의 모든 노력 견적은 여러 프로젝트에서 참여 관리자로서의 업무 경험을 기반으로합니다. 도움이 되길 바랍니다.

모든 조직과 코드 기반이 다르기 때문에 업계 전체의 가치를 얻는 것이 어렵습니다.
정말로 진지한 경우 메트릭 수집을 시작해야합니다. 즉, 재 작업을 포함하여 만족스럽게 완료 될 때까지 코드 검토를 수행하십시오. 데이터베이스 (LOC, 코드 복잡성, 프로그래밍 언어, 시간 등)에서 수집을 시작하십시오. 그런 다음 테스트 중에 결함 비율에 대한 메트릭을 수집하십시오. 이 코드를 줄일 수있는 한 자체적으로 비용을 지불해야합니다. 결함이 테스트에서 돌아온 경우 결함 수정에 소요 된 시간에 대한 메트릭을 수집하십시오. 조직에서 이러한 데이터를 작성하고 기준을 작성하면 매우 정확하게 예측할 수 있습니다. 추가 학습을위한 용어는 Quality of Quality와 Cost of Poor Quality입니다.

유일한 경고는 이것이 관료적이되기 시작하고 조직 문화에 달려 있다는 것입니다.