코드 커밋 전후에 검토하는 것이 더 낫습니까?

전통적으로 커밋 전에 코드 검토를 수행했는데, 오늘 커밋 후 코드 검토를 선호하는 동료와 논쟁이있었습니다.

먼저, 여기 몇 가지 배경이 있습니다.

1. 숙련 된 개발자가 있으며 프로그래밍 경험이 거의없는 신입 사원도 있습니다.
2. 제품을 출시하기 위해 빠르고 짧은 반복을 수행하려고합니다.
3. 모든 팀원이 같은 사이트에 있습니다.

커밋하기 전에 코드 검토의 장점 :

1. 멘토 신입 사원
2. 개발주기 초기에 오류, 고장, 불량 설계 방지
3. 다른 사람들로부터 배우십시오
4. 누군가가 종료하면 지식 백업

그러나 나는 또한 나쁜 경험을했습니다.

1. 효율성이 낮고 일부 변경 사항은 며칠 동안 검토 될 수 있습니다
2. 특히 초보자를 위해 속도와 품질의 균형을 맞추기 어렵습니다.
3. 한 팀원이 불신을 느꼈다

커밋 후 검토와 관련하여 나는 이것에 대해 거의 알지 못하지만 가장 걱정되는 것은 검토 부족으로 통제력을 잃을 위험이 있습니다. 의견이 있습니까?

최신 정보:

1. VCS에 Perforce를 사용하고 있습니다
2. 동일한 브랜치 (트렁크 또는 버그 수정 브랜치)에서 코딩 및 커밋
3. 효율성을 높이기 위해 코드를 작은 변화로 나누려고 노력했습니다. 우리는 또한 실시간 대화 검토를 시도했지만 모든 사람들이 규칙을 따르지는 않았습니다. 그러나 이것은 또 다른 문제입니다.

마찬가지로 사이먼 화이트 헤드는 그의 의견에 언급 , 당신 분기 전략에 따라 달라집니다.

개발자가 개발을 위해 자체 전용 브랜치를 가지고 있다면 (대부분의 상황에서 권장합니다) 트렁크 또는 기본 리포지토리와 병합하기 전에 코드 검토를 수행합니다. 이를 통해 개발자는 개발 / 테스트주기 동안 원하는만큼 자주 체크인 할 수 있지만 제공되는 코드가 포함 된 분기로 코드가 이동하면 검토됩니다.

일반적으로 코드 검토에 대한 나쁜 경험은 솔루션이있는 검토 프로세스의 문제와 비슷합니다. 더 작은 개별 청크로 코드를 검토하면 시간이 오래 걸리지 않도록 할 수 있습니다. 한 번에 150 줄의 코드를 검토 할 수 있지만 프로그래밍 언어, 개발중인 시스템 또는 시스템의 중요도에 익숙하지 않은 사용자의 경우 속도가 느려집니다 (안전에 더 많은 시간이 필요함). 이 정보는 효율성을 개선하고 코드 검토에 참여할 사람을 결정하는 데 유용 할 수 있습니다.

: 아직 아무도 인용 한 것 같다 만트라가 초기에 자주 체크인은 :

소스 컨트롤에 아무 것도 검사하지 않고 오랜 기간 (그리고 하루 종일) 일하는 개발자들은 심각한 통합 문제를 겪고 있습니다. 데이먼 풀은 동의한다 .

개발자들은 종종 체크인을 시작합니다. 다른 사람들에게 너무 일찍 영향을 미치고 싶지 않아서 빌드를 깨뜨린 것에 대해 비난을 받고 싶지 않기 때문에 시작했습니다. 그러나 이로 인해 작업 손실 또는 이전 버전으로 돌아 가지 못하는 등의 다른 문제가 발생합니다.

제 경험에 따르면 "초기 체크인"이 자주 사용되지만 개인 버전 관리에 액세스 할 수 있다는 경고가 있습니다. 체크인이 다른 사용자에게 즉시 보이는 경우, 변경 사항이 미성숙하거나 빌드가 중단 될 위험이 있습니다.

나는 동료들이 무엇을 쓰고 있는지 전혀 모른 채 오랜 시간을 보내는 것보다 정기적으로 작은 조각을 체크인하고 싶습니다. 내가 아는 한, 코드가 소스 제어로 체크인되지 않으면 존재하지 않습니다 . 나는 이것이 또 다른 형태의 Do n't Go Dark 라고 가정 한다. 코드는 어떤 형태로 저장소에 존재할 때까지 보이지 않습니다.

... 초기 체크인과 자주 체크인을 배우는 경우 피드백, 통합 및 검토를위한 충분한 시간이 있습니다 ...

나는 이것에 대해 다른 접근법을 가진 두 회사에서 일했습니다. 컴파일을 방해하지 않는 한 허용했습니다. 버그를 전혀 체크하지 않으면 다른 하나는 놀라게 될 것입니다. 전자가 훨씬 선호됩니다. 당신은 당신이 아직 진행중인 것들에 대해 다른 사람들과 협력하고 그것이 나중에 테스트 될 것이라는 것을 이해하면서 일종의 환경에서 개발해야합니다.

Jeff Atwood의 진술도 있습니다 : 물건을 깰 것을 두려워하지 마십시오 .

소프트웨어 개발자로서 개선 할 수있는 가장 직접적인 방법은 코드를 변경할 때 전혀 두려움이없는 것입니다. 코드가 깨지는 것을 두려워하는 개발자는 전문가가 될 수없는 개발자입니다.

또한 동료 리뷰를 위해 누군가가 무언가를 변경하기를 원한다면 원본 버전의 원본을 소스로 사용하는 것이 매우 유용한 학습 도구입니다.

나는 최근에 내가 참여한 프로젝트에서 사전 커밋 검토를 시작했으며 그것이 얼마나 문제가 없는지 유쾌하게 놀랐습니다.

내가 본 커밋 후 리뷰의 가장 큰 단점은 종종 한 사람 만의 사건이라는 것입니다. 누군가 코드의 정확성을 검토하지만 심각한 실수가 없다면 저자 는 관여하지 않습니다. 작은 문제, 제안 또는 힌트는 대개 저자에게 도달하지 않습니다.

이것은 또한 코드 검토의 인식 된 결과를 변경합니다. 모든 사람 (검토 자와 코드 작성자)이 매번 새로운 것을 배울 수있는 것과는 대조적으로, 추가 작업 만 생성하는 것으로 간주됩니다.

사전 커밋 코드 검토가 너무 자연스럽게 보이지만 커밋 후 검토가 의도적으로 수행 될 수는 없었습니다. 지속적인 통합 관점에서 코드가 완성되면 코드를 커밋하려고합니다.

어쩌면 우리 팀에서 항상했던 방식은 비동기식, 제어 중심의 문서 기반 검토가 아닌 원래 개발자가 시작한 라이브 대화이기 때문일 수 있습니다.

오늘날 대부분의 리포지토리는 2 단계 커밋 또는 셸 프셋 (개인 브랜치, 풀 요청, 패치 제출 또는 호출하려는 대상)을 지원하므로 작업을 메인 라인으로 가져 오기 전에 검사 / 검토 할 수 있습니다. 이러한 도구를 활용하면 항상 사전 커밋 검토를 수행 할 수 있습니다.

또한 내장 코드 검토를 제공하는 또 다른 방법으로 페어 코딩 (주니어와 주니어 페어)을 고려할 수 있습니다. 자동차가 굴러 간 후가 아니라 조립 라인에서 품질 검사로 간주하십시오.

둘 다 :

• 사전 커밋-재사용이 가능한 코드 조각 또는 주요 디자인 결정과 같이 매우 중요 할 때 이러한 종류의 검토를 수행하십시오.
• 포스트 커밋-개선 될 수있는 코드에 대한 의견을 얻고 싶을 때 이런 종류의 리뷰를하십시오.

구성 제어하에있는 소스 파일에 대해 공식적인 검토를 수행해야하며 검토 기록에 파일의 개정이 명확하게 명시되어 있습니다.

"최신 파일을 얻지 못했습니다"형식 인수를 피하고 모든 사람이 동일한 소스 코드 사본을 검토하도록합니다.

또한 검토 후 수정이 필요한 경우 해당 사실을 기록에 주석을 달 수 있습니다.

코드 검토 자체의 경우, 내 투표는 커밋 중에 '투표'하는 것입니다.

gerrit 또는 clover (제 생각에)와 같은 시스템은 변경 사항을 준비 한 다음 검토자가 소스 컨트롤에 커밋 (git in git) 할 수 있습니다. 그것은 두 세계의 최고입니다.

그것이 실용적이지 않다면, 커밋 이후가 최선의 타협이라고 생각합니다. 디자인이 좋으면, 저급 개발자들만 나쁜 일을 겪어야합니다. (사전 커밋을 검토하십시오).

코드를 검토 할 때 (또는 고객 배포시 문제를 위해) 디자인 검토를 수행 할 수 있지만 실제로 코드를 작성하기 전에 그보다 먼저 설계 문제를 찾아야합니다.

동료 검토를 통해 통제력을 잃을 위험이 최소화됩니다. 항상 두 사람이 같은 코드에 대해 알고 있습니다. 때때로 전환해야하므로 코드를 추적하려면 항상주의를 기울여야합니다.

숙련 된 개발자와 초보자가 함께 작업하는 것이 좋습니다. 언뜻보기에 이것은 비효율적 인 것처럼 보이지만 그렇지 않습니다. 실제로 버그가 적으며이를 해결하는 데 시간이 덜 걸립니다. 게다가, 초보자들은 훨씬 빨리 배울 것입니다.

나쁜 디자인을 방지하기 위해 코딩하기 전에 수행해야합니다. 상당한 변경 / 개선 / 새로운 디자인이 있다면 코딩을 시작하기 전에 검토해야합니다. 디자인이 완전히 개발되면 할 일이 많지 않습니다. 코드를 검토하는 것이 더 쉽고 시간이 덜 걸립니다.

본인은 기술을 이미 입증 한 숙련 된 개발자가 코드를 작성한 경우에만 커밋하기 전에 코드를 검토 할 필요는 없다는 데 동의합니다. 그러나 초보자가있는 경우 커밋하기 전에 코드를 검토해야합니다. 검토자는 개발자 옆에 앉아 모든 변경 사항이나 개선 사항을 설명해야합니다.

검토는 사전 커밋과 사후 커밋 모두에서 이점을 얻습니다.

사전 검토 커밋

• 검토자가 작성자의 최신 개정을 검토하고 있다고 확신합니다.
• 모든 사람이 동일한 코드를 검토하도록합니다.
• 검토 항목으로 작성된 개정이 완료되면 비교를위한 참조를 제공합니다.

검토 중에 실행중인 커밋 없음

Atlassian 도구를 사용했으며 검토 중에 실행 커밋이 발생하는 것을 보았습니다. 이것은 검토 자에게 혼란을 주므로 반대 의견을 추천합니다.

검토 후 수정

검토자가 구두 또는 서면으로 피드백을 완료 한 후 중재자는 작성자가 요청한 변경을 수행하도록해야합니다. 때때로 검토 자 또는 저자는 검토 항목을 결함, 제안 또는 조사로 지정할지 여부에 대해 동의하지 않을 수 있습니다. 의견 불일치를 해결하고 조사 항목이 올바르게 지워지도록 검토 팀은 중재자의 판단에 의존합니다.

약 100 개의 코드 검사에 대한 나의 경험은 검토자가 명확한 코딩 표준을 참조 할 수 있고 대부분의 논리 및 기타 프로그래밍 오류에 대해 검토 결과가 일반적으로 명확하다는 것입니다. 때때로 nit-picking에 대한 논쟁이 있거나 스타일이 논쟁으로 변질 될 수 있습니다. 그러나 중재자에게 의사 결정 권한을 부여하면 교착 상태를 피할 수 있습니다.

검토 후 커밋

• 중재자와 다른 검토 자에게 사전 검토 커밋과 비교할 데이터 요소를 제공합니다.
• 결함 제거 및 코드 개선시 검토의 가치와 성공을 판단 할 수있는 메트릭을 제공합니다.

팀 구성에 따라 다릅니다. 작고 빈번한 커밋에 대해 상대적으로 경험이 풍부한 팀의 경우 코드에 대한 두 번째 눈을 얻기 위해 커밋 후 검토가 좋습니다. 규모가 크고 복잡한 커밋 및 / 또는 경험이 적은 개발자의 경우 사전 커밋 검토를 통해 문제가 발생하기 전에 문제를 해결하십시오.

이러한 라인들과 함께, 좋은 CI 프로세스 및 / 또는 게이트 체크인은 커밋 전에 검토의 필요성을 줄입니다.

저와 제 동료들은 최근이 주제에 대한 과학적 연구를했기 때문에 다소 오래된 질문이기는하지만 통찰력을 추가하고 싶습니다. 우리는 민첩한 Kanban 개발 프로세스 / 팀의 시뮬레이션 모델을 구축하고 많은 다른 상황 (다른 팀원, 다른 기술 수준 등)에 대한 사전 커밋 및 사후 커밋 검토를 비교했습니다. 3 년간 (시뮬레이션 된) 개발 시간 후 결과를보고 효율성 (완성 된 스토리 포인트), 품질 (고객이 발견 한 버그) 및주기 시간 (사용자 스토리의 시작부터 배달까지의 시간)과 관련된 차이점을 살펴 보았습니다. . 우리의 발견은 다음과 같습니다.

• 효율성과 품질의 차이는 많은 경우 무시할 수 있습니다. 그렇지 않은 경우, 커밋 후 검토에는 품질과 관련하여 몇 가지 이점이 있습니다 (다른 개발자는 "베타 테스터"역할을합니다). 효율성을 높이기 위해 사후 커밋은 소규모 팀에게는 이점이 있고 프리 커밋은 대규모 또는 미숙 한 팀에게는 이점이 있습니다.
• 사전 커밋 검토는 종속 작업 시작이 검토에 의해 지연되는 상황에서주기 시간이 길어질 수 있습니다.

이를 통해 다음과 같은 휴리스틱 규칙을 도출했습니다.

• 확립 된 코드 검토 프로세스가있는 경우 변경하지 않아도됩니다. 아마도 노력할 가치가 없습니다.
  • 사이클 시간에 문제가 없다면 => 포스트로 전환
  • 또는 미끄러운 문제로 인해 개발자가 너무 자주 방해를 받음 => 사전 전환
• 아직 리뷰를 작성하지 않은 경우
  • 이러한 혜택 중 하나가 귀하에게 해당되는 경우 사전 커밋을 사용하십시오.
    • 사전 커밋 검토를 통해 커밋 권한이없는 외부인이 오픈 소스 프로젝트에 참여할 수 있습니다.
    • 도구 기반의 사전 커밋 검토는 느슨하게 프로세스를 준수하지 않는 팀에서 일부 검토 규칙을 시행합니다.
    • 사전 커밋 검토를 통해 검토되지 않은 변경 사항을 쉽게 전달할 수 없으므로 지속적인 배포 / 매우 짧은 릴리스주기가 필요합니다.
  • 팀 규모가 크고주기 시간에 문제를 해결하거나 회피 할 수있는 경우 사전 커밋을 사용하십시오.
  • 그렇지 않은 경우 (예 : 소규모의 숙련 된 산업 팀) 사후 커밋 사용
• 두 세계의 이점을 제공하는 조합을 찾으십시오 (공식적으로 연구하지는 않았습니다).

전체 연구 논문은 http://dx.doi.org/10.1145/2904354.2904362 또는 내 웹 사이트에서 사용할 수 있습니다 : http://tobias-baum.de

내 의견으로는, 커밋 후 코드 피어 검토가 가장 효과적입니다.

분기 전략을 조정하는 것이 좋습니다. 개발자 브랜치 또는 피처 브랜치를 사용하면 많은 이점이 있습니다. 그 중 최소는 커밋 후 코드 검토를 용이하게하지 않습니다.

Crucible과 같은 도구는 검토 프로세스를 원활하게하고 자동화합니다. 검토에 포함 할 하나 이상의 커밋 된 변경 집합을 선택할 수 있습니다. Crucible은 선택된 변경 세트에서 어떤 파일이 터치되었는지 표시하고, 각 검토자가 이미 읽은 파일을 추적하고 (전체 % 완료를 표시) 검토자가 쉽게 주석을 작성할 수 있도록합니다.

http://www.atlassian.com/software/crucible/overview

사용자 / 기능 지점의 다른 이점 :

• 개발자는 다른 사람을 위해 시스템을 중단 할 염려없이 버전 제어 (백업 변경, 히스토리에서 복원, 변경 변경)의 이점을 얻을 수 있습니다.
• 결함이 발생하거나 정시에 완료되지 않은 변경 사항은 필요에 따라 철회, 우선 순위 지정 또는 보류 할 수 있습니다.

경험이 부족한 개발자에게는 멘토 및 / 또는 페어 프로그래밍과의 정기적 인 상담이 좋은 생각이지만 이것을 "코드 검토"로 간주하지는 않을 것입니다.

양자 모두. (거의.)

커밋하기 전에 자신의 코드를 요약해서 검토해야합니다. Git에서는 준비 영역이 훌륭하다고 생각합니다. 변경 사항을 준비한 후 준비된 git diff --cached모든 내용을 확인합니다. 나는 이것을 포함하지 않는 파일 (빌드 아티팩트, 로그 등)을 체크인하지 않고 거기에 디버그 코드가 없거나 주석 처리 된 중요한 코드가 없는지 확인하는 기회로 사용합니다 아웃. (체크인하고 싶지 않은 것을하고있는 경우, 스테이징 중에 인식 할 수 있도록 모든 캡에 주석을 남깁니다.)

말했듯이, 피어 ​​브랜치 검토는 일반적으로 토픽 브랜치에서 작업하고 있다고 가정하고 커밋 한 후에 수행해야합니다. 이것은 다른 모든 사람들이 올바른 것을 검토하고 있는지 확인하는 가장 쉬운 방법이며, 중대한 문제가있는 경우 지점에서 문제를 해결하거나 삭제 한 후 다시 시작하는 것은 그리 중요하지 않습니다. 코드 검토를 비동기 적으로 수행하는 경우 (예 : Google 코드 또는 Atlassian Crucible 사용) 현재 며칠 동안 검토중인 모든 다른 패치 / diff를 별도로 추적하지 않고도 분기를 쉽게 전환하고 다른 작업을 수행 할 수 있습니다.

당신이 주제 분기에 작동하지 않는 경우, 당신은해야한다 . 스트레스와 번거 로움을 줄이고 릴리스 계획을 훨씬 덜 스트레스하고 복잡하게 만듭니다.

편집 : 또한 테스트 후 코드 검토를 수행해야한다고 덧붙여 야합니다. 이는 코드를 먼저 커밋하는 데 유리한 또 다른 주장입니다. 테스트 그룹이 모든 프로그래머의 수십 가지 패치 / 차이점을 다루지 않고 잘못된 패치를 잘못된 위치에 적용했기 때문에 버그를 신고하지 않기를 바랍니다.

많은 소규모 커밋과 모든 커밋을 기반으로하는 CI 시스템 (가능한 경우 단위, 통합 및 기능을 포함한 자동화 된 테스트 포함)과 100 % 페어링 된 프로그래밍 (어떻게 생각하든 상관없이). 크거나 위험한 변경에 대한 커밋 후 검토 게이트 / 커밋 전 검토가 필요한 경우 Gerrit가 작동합니다.

체크인 (버디 체크)시 코드 검토의 이점은 큰 코드 조각이 완료되기 전에 즉각적인 피드백입니다.

체크인시 코드 검토의 단점은 긴 코드가 완성 될 때까지 사람들이 체크인하지 못하게 할 수 있다는 것입니다. 이 경우 이점을 완전히 무효화합니다.

이것을 어렵게 만드는 것은 모든 개발자가 같은 것은 아닙니다. 간단한 솔루션이 모든 프로그래머에게 적용되는 것은 아닙니다 . 간단한 해결책은 다음과 같습니다.

• 친구가 바로 옆에 있기 때문에 자주 체크인을 할 수있는 필수 쌍 프로그래밍. 이것은 쌍 프로그래밍이 모든 사람에게 항상 작동하는 것은 아니라는 것을 무시합니다. 올바르게 수행하면 페어 프로그래밍도 지칠 수 있으므로 하루 종일 할 필요는 없습니다.

• 개발자 브랜치, 코드는 메인 브랜치에서만 완료되고 검토됩니다. 일부 개발자는 비밀리에 작업하기 쉬우 며, 일주일 후에는 이전에 발견되었을 수있는 근본적인 문제로 인해 검토를 통과하거나 통과하지 못할 수있는 일부 코드가 나타납니다.

• 체크인 할 때마다 검토하면 잦은 검토가 보장됩니다. 일부 개발자는 잊어 버리고 매우 자주 체크인을하므로 15 분마다 코드 검토를 수행해야합니다.

• 체크인 후 지정되지 않은 시간에 검토하십시오. 마감 시한이있을 때 리뷰가 더 나옵니다. 이미 커밋되었지만 아직 검토되지 않은 코드에 의존하는 코드가 커밋됩니다. 리뷰는 이슈를 표시하고 이슈는 "나중에"수정되도록 백 로그에 기록됩니다. 좋아, 나는 거짓말했다 : 이것은 간단한 해결책이 아니며 전혀 해결책이 아니다. 체크인이 완료된 후 지정된 시간에 검토하지만 지정된 시간을 결정해야하기 때문에 덜 간단합니다.

실제로이 작업을보다 단순하고 복잡하게 만들어이 작업을 수행 할 수 있습니다. 간단한 지침을 설정하고 각 개발 팀이이 지침을 따르기 위해해야 ​​할 일을 팀으로 파악하게합니다. 이러한 지침의 예는 다음과 같습니다.

• 하루도 걸리지 않는 작업으로 작업이 분류됩니다.
• 코드 (있는 경우)가 체크인되지 않은 경우 작업이 완료되지 않습니다.
• 코드 (있는 경우)를 검토하지 않으면 작업이 완료되지 않습니다.

그러한 지침의 많은 대안적인 형태가 가능하다. 실제로 원하는 것 (피어 검토 코드, 관찰 가능한 작업 진행률, 책임)에 중점을두고 팀이 원하는 것을 줄 수있는 방법을 파악하도록합니다.

실제로 LedgerSMB에서 하이브리드를 수행합니다. 커미터는 검토 후 변경 사항을 커밋합니다. 비커 미터는 변경 사항을 커미터에 제출하여 이전에 검토합니다. 이것은 두 가지 계층의 검토를 의미하는 경향이 있습니다. 먼저 멘토가 귀하를 검토하고 멘토링하게합니다. 그런 다음 해당 멘토는 서명 한 후 코드를 다시 검토하여 피드백을 순환시킵니다. 새로운 커미터는 일반적으로 처음에 다른 사람들의 커밋을 검토하는 데 많은 시간을 소비합니다.

꽤 잘 작동합니다. 검토 후의 내용은 일반적으로 이전의 검토보다 더 거칠기 때문에 검토 후 자신이 입증 된 사람들을 위해 예약되도록하십시오. 그러나 새로운 사람들에 대한 2 계층 검토가 있다면 문제가 더 많이 포착되어 토론을 할 가능성이 높습니다.

커밋 어디? 내가 일을하기 위해 만든 지점이 있습니다. 기분이들 때마다 그 지점에 헌신합니다. 아무도 사업이 아닙니다. 그런 다음 지점이 개발 지점에 통합됩니다. 그리고 그 사이 어딘가에 코드 검토가 있습니다.

검토자는 지점에 커밋 한 후에 분명히 검토 합니다. 그는 내 책상에 앉아 아니에요, 그래서 커밋하기 전에 그는 그것을 검토 할 수 없습니다 내 지점입니다. 그리고 그는 합병 전에 검토 하고 개발 지점에 전념합니다.

코드 리뷰를 전혀하지 마십시오. 개발자가 좋은 코드를 작성할 수 있다고 생각하거나 제거해야합니다. 자동화 된 테스트에서 논리 오류를 포착해야합니다. 오류는 보푸라기 및 정적 분석 도구에 의해 스타일이 포착되어야합니다.

인간이 자동 프로세스에 관여하게하는 것은 낭비입니다.