코드 검토를 수행하는 가장 효과적인 방법은 무엇입니까? [닫은]

코드 검토를 수행하는 이상적인 방법을 찾지 못했지만 종종 고객이 요구합니다. 각 고객은 다른 방식으로 고객을 수행하는 것으로 보이며 고객 만족도를 느끼지 못했습니다.

코드 검토를 수행하는 가장 효과적인 방법은 무엇입니까?

예를 들면 다음과 같습니다.

• 한 사람이 품질의 문지기로 간주되어 코드를 검토합니까, 아니면 팀이 표준을 소유합니까?
• 프로젝터를 사용하여 팀 연습으로 코드를 검토합니까?
• 직접, 이메일 또는 도구를 사용하여 이루어 집니까?
• 코드 품질을 보장하기 위해 검토를 피하고 페어 프로그래밍 및 공동 코드 소유권과 같은 것을 사용합니까?

저의 작업에는 매우 간단한 규칙 이 있습니다 . 트렁크에 병합 또는 커밋하기 전에 최소한 한 명의 다른 개발자가 변경 사항을 검토해야합니다 . 우리의 경우 이것은 상대방이 귀하의 컴퓨터에서 귀하와 물리적으로 함께 있고 변경 목록을 통과한다는 것을 의미합니다. 이것은 완벽한 시스템은 아니지만 그럼에도 불구하고 코드 품질이 눈에 띄게 향상되었습니다.

코드를 검토한다는 것을 알고 있다면 먼저 코드를 살펴 봐야합니다. 그때 많은 문제들이 명백해집니다. Google 시스템에서는 검토 자에게 수행 한 작업을 설명해야하며, 이로 인해 이전에 놓친 문제를 다시 발견 할 수 있습니다. 또한 코드의 내용이 검토 자에게 즉시 명확하지 않은 경우 더 나은 이름, 주석 또는 리팩토링이 필요하다는 것을 나타냅니다. 물론 검토 자도 문제를 발견 할 수 있습니다. 또한 검토자는 변경 사항을 확인하는 것 외에도 인근 코드에 문제가 있음을 알 수 있습니다.

이 시스템에는 두 가지 주요 단점이 있습니다. 변경이 사소한 경우에는 검토하는 것이 의미가 없습니다. 그러나 변경 사항이 "사소한"것으로 선언되는 미끄러운 경사를 피하려면 규칙을 준수해야합니다. 반면에 이것은 시스템의 중요한 변경 사항이나 새로운 대형 구성 요소의 추가를 검토하는 좋은 방법이 아닙니다.

우리는 이전에 한 개발자가 다른 팀에게 검토 할 코드를 전자 메일로 보내면서 전체 팀이 모여 토론 할 때 공식적인 검토를 시도했습니다. 이 작업에는 많은 시간이 걸렸으며 결과적으로이 리뷰는 거의 없었으며 코드베이스의 일부만 검토되었습니다. "다른 사람이 커밋하기 전에 변경 사항을 검토합니다"는 우리에게 훨씬 더 효과적이었습니다.

코드 리뷰가 마음에 들지만 고통 스러울 수 있습니다. 내가 그들을 좋아하는 이유는 그들이 코드와 다른 관점에서 더 많은 눈을 갖기 때문입니다. 페어 프로그래밍을 사용하더라도 코드를 검토해야한다고 생각합니다. 같은 코드로 작업하는 두 사람이 다른 눈 세트를 놓칠 수없는 동일한 실수를 집단적으로 만드는 것은 쉽습니다.

프로젝터를 사용하여 그룹으로 수행 한 경우 회의 전에 실제로 개별적으로 검토해야합니다 . 그렇지 않으면, 그것은 단지 성가신 시간 낭비입니다.

이메일과 그룹을 통해서만 코드 검토를 수행했습니다. 일반적으로, 나는 그들이 직접해야한다고 생각하지 않습니다. 누군가 어깨 너머로보고 코드를 서두르는 것이 조금 더 압박감을 느낀다. 나는 코드 검토를 위해 설계된 도구가 평범한 측면 중 일부에 도움이 될 수 있기 때문에 좋은 자산이 될 것이라고 믿습니다. 문제가있는 코드를 쉽게 플래그 지정하면 전자 메일을 통해 이루어집니다.

한 사람이 모든 코드 검토를 수행하는 데 따른 문제점은 병목 현상이 발생할 수 있다는 것입니다. 잘 문서화되고 설계된 코딩 표준이 필요하지 않습니다. 환경 / 릴리스 일정에 따라 항상 대기 코드 검토 자로 누군가를 두는 것이 좋습니다.

본인은 코드를 이해하고 잠재적으로 게이트 키퍼 역할을 수행하기 위해 코드 소유권을 우선시 할 수 있으므로 코드 소유권이 좋은 아이디어라고 생각합니다.

에서 SmartBear 우리가 할뿐만 아니라, 코드 검토 도구를 , 우리는 또한 하루 기준으로 하루에 그것을 사용할 수 있습니다. 우리의 개발 과정에서 필수적인 부분입니다. 체크인되는 모든 변경 사항을 검토합니다.

여러 가지 이유로 단일 게이트 키퍼 코드 검토자를 갖는 것이 좋지 않다고 생각합니다. 그 사람은 병목 현상이 생겨서 실제로 효과를 발휘하기 위해서는 너무 많은 코드 검토 (프로젝트 이동을 유지하기 위해)를 수행해야합니다 (한 번에 60-90 분이 효과의 한계입니다). 코드 검토는 아이디어와 지식을 공유 할 수있는 좋은 방법입니다. 게이트 키퍼가 얼마나 많은 수퍼 스타인지에 관계없이 팀의 다른 사람들로부터 배울 수 있습니다. 또한 모든 사람이 코드 검토를 수행하도록하면 "집합적인 코드 소유권"환경이 만들어집니다. 여기서 사람들은 코드 품질 (QA 또는 게이트 키퍼 만이 아니라)을 소유하고 있다고 생각합니다.

" 피어 코드 검토를위한 모범 사례 "에 대한 무료 백서 가 있으며 코드 검토를 효과적으로 수행하기위한 11 가지 팁이 있습니다. 이것의 대부분은 요한이 더 증류 된 형태로 언급 한 책의 내용과 동일합니다.

변명하지. 페어 프로그래밍 연습. 최상의 코드 검토가 가능합니다. 다른 메커니즘은 비난 게임을 초래합니다. 페어 프로그래밍은 팀 정신과 공동 소유를 유도합니다. 또한 쌍과 아이디어를 토론하고, 신속하게 실패하며, 시정 조치를 취하며, 구성 관리 시스템 (CMS)에 투입되는 것은 코드화되고 검토 된 코드입니다. 행복한 페어 프로그래밍!

여러 사람이 코드 기반에 기여할 프로젝트를 진행하는 경우 표준을 설정해야합니다.

이 시점에서 내 경험에 따르면 한 사람이 원하는 경우 코드 검토의 "왕"으로 지정하는 것이 가장 좋습니다. 이와 관련하여, 한 사용자가 표준을 준수하지 않으면 왕이이를 처리 할 것입니다.

필자는 개발자로서 자신의 코드를 여러 번 검토하여 읽을 수 있고 현명하며 기타 모든 것을 읽습니다. 보통 우리는 코드로 주어진 언어로 javadoc 또는 이와 유사한 것을 사용하고 @author 태그를 사용하여 소유권을 함수, 클래스 등에 첨부합니다.

기능이 정확하지 않으면 클래스와 마찬가지로 소유자와 대화합니다.

내 회사에서 각 작업에는 작업을 테스트하는 테스터와 코드를 검토하는 코드 검토자가 할당됩니다.

제품이 이미 릴리스되어 있고 핸들 누수 또는 메모리 누수와 같은 잘못된 작업을 수행하지 않으려는 경우 코드 검토가 좋습니다. 제품을 출시하기 전에 초기 개발 과정에서 코드 검토가 너무 많은 것으로 생각합니다.

팀에 모든 수석 개발자가있는 경우 동료 검토가 여전히 유용합니다. 누구나 실수를합니다. 팀에 선배와 후배가있는 경우, 선임 개발자가 코드 검토를하도록하면서도 선임 코드에 대한 코드 검토도 유지하십시오.

코드 검토에서 한 가지 중요한 점은 오류가 발생할 수 있지만 테스트를 대신 할 수는 없다는 것입니다.

페어 프로그래밍을 수행하지 않는 경우 코드 검토를 사용하는 것이 좋습니다.

페어링과의 장단점을 주장하지는 않지만 (적어도) 다른 사람이 코드를 지속적으로 검토하게 만드는 긍정적 인 효과에 대해서는 이의를 제기하기가 어렵습니다. 이 코드는 (적어도) 두 명의 프로그래머가 작성하고 설계하기도합니다. 나는 "적어도"라고 말하고 있습니다. 왜냐하면, imo, 여러분은 코드를 다룰 때 모두가 기회를 갖도록 쌍 을 많이 바꿔야 합니다.

내가 참여한 코드 검토에서 수행하려는 작업 중 하나는 코드를 직접 검토 한 후 Findbugs, PMD, JavaNCCP 등과 같은 도구를 사용하여 코드를 정적으로 분석하고 이러한 도구에서 발견되는 모든 문제를 살펴 보는 것입니다. 검토 할 코드 특히 복잡성이 매우 높은 모든 항목을보고 해당 복잡성 수준이 필요한 이유 또는 제안 된 취약점이 중요하지 않은 이유를 설명하려고합니다.

YMMV

현재 작업중인 곳에서는 중요한 인프라에 들어가는 하드웨어 장치 및 이들과 상호 작용하는 소프트웨어를 생산합니다. 결과적으로 우리는 릴리스 품질에 매우 중점을 둡니다. 우리는 Fagan Inspection 의 변형을 사용하며 공식적인 검토 프로세스를 가지고 있습니다. 우리는 다른 인증 중에서도 ISO 9001 인증을 받았습니다.

중요한 인프라 산업은 안정성과 반복성에 매우 관심이 있습니다. :-)

우리 회사에는 주니어 프로그래머를위한 필수 코드 리뷰와 노인을위한 자발적인 리뷰가 있습니다. 지정된 코드 검토자가 없으며 검토 요청이 모든 개발자에게 전송됩니다.

이 시스템은 잘 작동합니다. 시간이 허락되면 검토가 이루어지며 여러 세트의 안구가 변경 사항을 검토 할 수 있습니다.

우수하고 무료 인 Review Board 도구는 우리에게 정말 효과적이며 리뷰를 전달하는 훌륭한 방법으로 판명되었습니다.

우리 회사에서는 중요한 프로덕션을 수정하지 않고 표준 QA 프로세스를 수행 할 시간이없는 한 체크인 전에 공식 코드 검토를 수행하지 않습니다.

코드 검토가 유용하다고 생각 될 때마다 수정 된 코드에 "// todo : code review by joe"주석을 추가합니다. 일반적으로 수정 된 코드를 소유하고 있기 때문에 Joe를 선택하지만이 선택 기준이 적용되지 않는 경우 (보통 적용되는 경우) 무작위로 다른 사람을 선택했습니다. 물론 Joe가 그 당시에 가능하다면, 우리는 좋은 오래된 검토 방법을 사용합니다.

리뷰어로서, 당신이해야 할 유일한 것은 "// todo : code review by me" 에 대한 전체 코드를 주기적으로 검색 하고, 변경 사항을 검토하고, "todo ..."주석없이 코드를 다시 확인하는 것입니다.

문제가있는 경우 기존의 통신 방법 (메일 / 채팅 등)으로 다시 전환합니다.

이 방법은 우리가 검토 시스템에서 추구하는 두 가지 주요 특성을 제공합니다.

• 매우 가벼운 오버 헤드
• 추적 성

우리는 코드 검토를 수행하는 가장 효과적인 방법은 github을 사용하여 지점의 차이점을 표시하는 일대일입니다.

• 한 사람이 품질의 문지기로 간주되어 코드를 검토합니까, 아니면 팀이 표준을 소유합니까?

  • 팀의 규모에 따라-3 명으로 구성된 팀에는 모범 사례를 잘 알고있는 1 명의 선임자가 있고, 12 명으로 구성된 팀에는 3 명 또는 4 명이 해당 역할을 수행 할 수 있습니다.

• 프로젝터를 사용하여 팀 연습으로 코드를 검토합니까?

  • 직접. 1 대 1은 덜 위협적입니다. 때로는 지식이 확산 되기는하지만 공동 영역에서 이루어집니다. 정확한 상황, 사람, 시간표 등에 따라 다릅니다.

• 직접, 이메일 또는 도구를 사용하여 이루어 집니까?

  • 직접. 우리는 git과 github을 사용하며 코드 검토를 쉽게하기 위해 훌륭한 코드 검토 및 diff 비교 도구를 가지고 있습니다.

• 코드 품질을 보장하기 위해 검토를 피하고 페어 프로그래밍 및 공동 코드 소유권과 같은 것을 사용합니까?

  • 우리는 적절하게 두 가지를 모두 시도합니다. 즉, 특히 어려운 문제에 빠지거나 핵심 인프라에서 작업하거나 휴가를 준비하거나 회사를 떠날 때 지식을 공유하고 전달하기 위해 페어링이 수행 될 수 있습니다. 외관상의 변화 이상의 것을 가진 대부분의 코드 나 코드는 마지막에 검토해야합니다.

모든 코딩 항목과 마찬가지로 정답은 다음을 고려해야합니다.

• 회사 유형 (예 : 스타트 업 대 대기업)
• 회사 규모
• 개발자 수
• 예산
• 기간
• 작업량
• 코드의 복잡성
• 검토 자 능력
• 검토 자의 가용성

나는 많은 회사에서 일했고 많은 과정을 보았습니다. 현재 팀은 내가 지금까지 본 최고의 것을 처리합니다.

우리는 민첩한 개발 프로세스를 사용하며 그 일부로 각 스토리를 거쳐야하는 게이트가 있습니다. 그 문 중 하나는 코드 검토입니다. 코드 검토가 완료 될 때까지 스토리는 테스트로 이동하지 않습니다.

또한 우리는 코드를 github.com에 저장합니다. 따라서 개발자가 변경을 마치면 스토리에 커밋에 대한 링크를 게시합니다.

그런 다음 동료 개발자에게 태그를 지정하여 검토합니다. Github에는 누군가가 해당 코드 줄에 바로 주석을 달 수있는 주석 시스템이 있습니다. 그런 다음 Github는 배포판에 전자 메일을 보내므로 때때로 다른 팀의 도움을받을 수도 있습니다.

이 과정은 우리에게 매우 효과적이었습니다. 우리는 커밋을 쉽게 게시하고 커뮤니케이션을 용이하게하는 민첩한 프로세스 도구를 사용합니다.

문제가 특히 끈적 거리면 우리는 앉아서 논의 할 것입니다. 이는 프로세스에 필수적이며 프로세스가 작동하는 방식에 대해 모든 사람들이 구매했기 때문에 작동합니다. 코드 검토 결과 재 작업이 필요한 경우 티켓을 다시 진행중인 상태로 옮길 수 있으며 변경 후 다시 검토 할 수 있습니다.

테스트에 문제가 발생하면 다시 진행 중이며 추가 변경 사항도 검토됩니다.