우리는 현재 민첩한 프로세스로 실행되는 4-5 명의 개발자로 구성된 팀입니다. 코드의 품질을 높이기 위해 엄격한 코드 검토 정책이 적용되었습니다. 다른 한 쌍의 눈으로 코드를 검토하지 않는 한 코드를 기본 분기로 푸시 할 수 없습니다.코드 검토로 인한 컨텍스트 전환 비용 피하기
매우 도움이되었지만 검토로 인한 상당한 오버 헤드가 있다고 생각합니다. 검토 할 시간은 문제가 아니므로 컨텍스트 전환이 더 큰 문제입니다. 작은 커밋을 사용하는 또 다른 최상의 방법과 함께 코드 작성자가 누군가의 코드를 검토하지 않고도 한 시간 이상 코드를 작성할 수없는 경우가 종종 있습니다. 컨텍스트 전환이 문제입니다.
코드 검토 단계를 실제 근무일의 늦은 시각에만 연기하는 것은 소리가 들릴만큼 매끄럽지 않습니다. 빌드 할 때까지 검토해야하는 코드에는 많은 종속성이 있습니다. 따라서이 시나리오는 또한 자주 코드를 검토하게됩니다.
유용한 코드 검토에 동의합니다. 그 이점은 꽤 좋다. documented, 코드 완성,
디자인 및 코드 검사의 평균 효과는 55 %와 60 %이다.
그러나 쉽게 만들 수있는 여러 가지 방법이 있습니다.
유지 리뷰 작은. 일반적으로 Frequency Reduces Difficultly이며 코드 리뷰의 경우 코드를 자주 검토하여 코드 검토가 너무 크게되지 않도록합니다. 복잡도가 일반적으로 선형 적이 지 않으면 파일이 많을수록 복잡성이 기하 급수적으로 증가합니다.
쌍 프로그래밍은 주파수의 원리를 극단적으로 어렵게 만듭니다 (어쩌면 왜 XP의 일부인지). 누군가와 페어 프로그래밍을하는 경우 코드 검토가 필요하지 않습니다. 다른 사람이 항상 보았던 것입니다. 프로그램을 페어링하면 리뷰어가 항상 당신과 함께 일하고 (그리고 종종 역할을 바꾸기 때문에) 컨텍스트 스위칭이 없습니다.
자동 및 단위 테스트는 코드 검토를 지시하고 쌍 프로그래밍을 용이하게합니다. 코드 조각의 의도가 무엇인지 정확하게 설명하고 이해를 돕는 데 도움이됩니다. 또한 리팩터링 및 기타 비 기능적 변경과 같은 제안 된 변경 사항에 대한 즉각적인 피드백과 확신을 얻을 수 있도록 도와줍니다.
.Net에서 FxCop, NDepends 및 Gendarme와 같은 정적 분석 도구와 같은 코딩 표준을 자동화하면 검토자가 필요로하는 것에 대한 부하를 줄일 수 있습니다. 필요한 경우 아키텍처 제약과 같은 규칙을 지원하도록 확장 될 수 있습니다. 레거시 코드 기반을 가지고 있다면, 이 이전 빌드보다 나쁘면 일 경우에만 오류를 표시하도록 설정하는 것이 좋습니다. 적어도 사태가 악화되는 것을 막아야합니다.
당신이해야하는 것처럼 당신이 소스 제어 시스템을 사용하지 않는다는 것이 나에게 들립니다. 소규모 커밋은 장려되며, 상황이 잘못 될 경우 대비할 수있는 좋은 시점과 가까운 시점을 찾는 데 도움이됩니다. 그러나, 당신은 메인 브랜치 (또는 트렁크 또는 무엇이든 그것을 호출)에 커밋/체크인하지 않습니다. 이 작은 커밋을 로컬 지사로 보내면 모든 것이 Main (트렁크)으로 푸시됩니다. 그러면 코드 검토를 수행하게됩니다. 이것이 우리가하는 방법이며, 1 ~ 2 일마다 코드 검토가 끝나기 때문에 나쁘지 않습니다.
이 경우 개인적인 체크인보다는 전체적으로 스토리를 검토하는 것이 좋습니다.일반적으로 우리의 이야기는 구현하는 데 2-3 일이 걸리고 전체 스택에 대한 동료 리뷰는 동료가 각 작업을 검토하는 것보다 더 많은 이슈를 찾는 경향이 있다는 것을 알았습니다 (어디서 코드를 검토할지보다 주변 코드 및 아키텍처).
그러면 기능 브랜치와 메인 라인 사이에 모든 코드가 테스트되고 피어 리뷰를 통과해야한다는 내용의 게이트가 있습니다.
Pair Programming을 Continuous Code Review로 취급하고 Pair Program을 사용하면 문제가 해결됩니다. 그것은 유일한 해결책은 아니지만 좋은 방법 일 수 있습니다. –
소규모 팀에서는 그렇지 않을 수 있습니다. 팀에서 그렇게 할 여유가 없습니다. –
프로그래머가 1 명 이상인 경우 쌍 프로그래밍이 가능합니다. –