코드 검토에 할당 된 시간


14

코드 검토를 수행중인 경우

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

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

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


2
이 세 가지 질문에 대한 나의 대답은 "없음", "없음"및 "더 많을 것"입니다. :-)
Carson63000 5

4
좋은 질문입니다, 저는 제 작업에 코드 리뷰를 도입하기 위해 개인 십자군을 시작하는 과정에 있습니다. 이에 대한 답변이 도움이 될 수 있습니다.
Kevin D

다음 질문은 "왜"입니다. 대부분은 품질에 대해 생각하지만, 코드의 교육적 가치가 품질 가치를 초과한다는 것을 이해하면 큰 이득을 얻게됩니다.
mattnz

답변:


7

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

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

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


1
얼마나 걸리는지 아십니까?
peterchen

5

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


방금이 책을 주문했습니다. 희망적으로 흥미로운 읽을 거리가되어야합니다.
Kevin D

3
그것도 주문했다. 인터넷을 통해 소프트웨어를 판매하는 회사로부터 20 일 동안 " 무료 "책 을 기다리는 것은 이상합니다.
peterchen

그 책은 몇 년 동안 제 직장에서 일을했습니다. 우리의 사본은 잘 읽혀지고 몇 가지 postit의 주요 요점으로 가득 차 있습니다. 작지만 (한 시간에 읽을 수 있음) 훌륭한 정보가 담겨 있습니다. 분명한 목적은 코드 검토를하도록 설득 한 다음 도구를 사용하도록 설득 한 다음 도구를 구입하도록 설득하는 것입니다.
mattnz

4

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

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

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

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

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


2

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

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


고마워요-땀이 나지 않아요. "얼마나 많은"질문에 대한 숫자를 보게되어 감사합니다!
peterchen

0

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

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


실용적인 데이터를 찾고 있으므로 예상 범위에 대한 아이디어를 얻습니다 .
peterchen
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.