코드 검토의 목적은 무엇입니까

76

코드 검토의 가치에 따라 조직을 판매하려고합니다. 나는 그들이 고용 된 여러 곳에서 일했다. 나는 그것들이 스타일 선택과 기능적 결정을 nitpick하는 데 사용되는 것을 보았고, 위험한 것이 구현되지 않았는지 확인하기 위해 직감 검사로 사용 된 것을 보았습니다. 내 직감은 가장 효과적인 목적이 두 옵션 사이에 있다는 것입니다.

그렇다면 Code Review의 목적은 무엇입니까?

code-reviews theory

— 소이 렌트 그레이
소스

16

관련 (스택 오버플로) : 코드 검토의 목적

— yannis

16

-읽기 쉽고 유지 관리가 쉬운 코드를 작성했는지 어떻게 알 수 있습니까? -코드를 검토 한 후 동료가 알려줍니다. '역설 : 코드 자체가 말하는 것보다 저자에 대해 더 많이 알고 있기 때문에 스스로 결정할 수는 없습니다. 그림이 예술인지 아닌지를 알 수없는 것과 같은 이유로 컴퓨터는 말할 수 없습니다. 따라서 소프트웨어를 유지 관리 할 수있는 다른 사람이 필요하므로 작성한 내용을보고 의견을 제시해야합니다. 해당 프로세스의 공식 이름은 "Peer Review" 입니다. '

— gnat

3

"코드 검토의 목적은 무엇입니까?" 개발자가 terribad 코드 를 작성하지 못하도록 하고 올바른 방향으로 조정합니다.

— zzzzBov September

7

보인다 코드 검토는 단지 코드 검토의 목적은 매우 분명 :)되고,이 질문과 답변에 검색 ...이 질문에 대한 간접적 인 대답이있을 수 있습니다

— 마티유 Guindon

3

프로그래머가 검토하는 동안 코드를 설명하는 간단한 프로세스를 통해 자신의 코드에서 버그를 발견 한 횟수가 몇 개인 지 궁금합니다.

— 도끼 비활성

75

코드 검토를 수행하려는 여러 가지 이유가 있습니다.

다른 개발자의 교육. 모든 사람이 결함 수정 또는 개선과 관련된 수정 사항을보고 나머지 소프트웨어를 이해할 수 있도록하십시오. 이는 사람들이 특정 모듈을 보지 않고 오랫동안 갈 수있는 복잡한 시스템이나 통합이 필요한 구성 요소를 작업 할 때 특히 유용합니다.
결함 또는 개선 기회 찾기. 제공 가능한 코드와 테스트 코드 및 데이터를 모두 검사하여 약점을 찾을 수 있습니다. 이를 통해 테스트 코드가 강력하고 유효하며 설계 및 구현이 응용 프로그램 전체에서 일관되게됩니다. 추가 변경이 필요한 경우 진입 점에 더 가까운 기회를 잡습니다.

검토를 수행하기위한 몇 가지 비즈니스 사례가 있습니다.

사출에 가까운 재 작업이 필요한 결함 또는 문제 찾기 이것은 더 싸다.
시스템과 교차 훈련에 대한 이해. 개발자가 신속하게 변경을 수행 할 수있는 시간이 줄어 듭니다.
시스템의 가능한 개선 사항 식별.
테스터가 적절한 범위를 제공 할 수 있도록 구현을 엽니 다. 테스트 관점에서 블랙 박스를 회색 박스 또는 화이트 박스로 바꿉니다.

동료 검토의 이점과 구현 전략에 대한 포괄적 인 토론을 원한다면 소프트웨어의 Peer Reviews : Karl Wiegers의 실용 가이드를 참조하십시오 .

— 토마스 오웬스
소스

7

+1, 올바른 우선 순위로 주요 요점을 잘 발견했다고 생각합니다. 매우 창의적인 "WTF"솔루션을 지속적으로 찾는 동료를 처리 할 때 디자인을 일관되게 유지하려면 정기적 인 코드 검토만으로 달성 할 수 있습니다.

— Doc Brown

우리는 JavaScript 코드에서 코드 검토를 수행합니다. 주로 개발자가 모듈을 설계 할 때 설정된 패턴을 사용하고 제공된 구성 요소를 사용하고 이미 해결책이있는 문제에 대해 닌자 코딩 (의도적이든 아니든)을 시작하지 않도록 개요 표준을 고수하도록합니다. 에 대한. 또한 실수로 this상황을 덮어 쓰는 사람 .hasOwnProperty을 찾아 내야합니다. 상황에 따라 등을 사용하지 않아야합니다. 주로 표준에 사용됩니다. C #과 같은 관리되는 언어에서는 동적 언어에 비해 몇 가지 적은 이유가 있습니다.

— Nope

1

지금까지 귀하의 답변은 코드의 정확성 개선에 대해서만 언급합니다. 코드의 가독성 / 유지 보수성을 다루지 못하며 개발 개발자가 정확하게 수치화 할 수는 없습니다.

— ArTs

51

코드 검토는 지식 이전을 위한 도구입니다 .

개발자가 서로의 코드를 검토하면 시스템의 모든 영역에서 친숙해집니다. 이는 프로젝트의 버스 요소를 줄이고 개발자가 작성하지 않은 시스템의 일부에서 유지 관리를 수행해야 할 때 개발자의 효율성을 높입니다.
주니어 프로그래머가 시니어 코드를 검토 할 때, 주니어 프로그래머는 경험을 통해서만 배운 트릭을 선택할 수 있습니다. 이것은 지나치게 복잡한 코드에 대한 교정으로도 작동 할 수 있습니다.

철저한 코드 검토를 위해서는 다양한 문서를 자주 점검해야합니다. 언어 나 API를 배우는 좋은 방법입니다.
선임 프로그래머가 주니어 코드를 검토 할 때 기술 부채로 해석 되기 전에 문제를 해결하는 기회 입니다. 주니어 프로그래머에게 멘토링을하기 위해서는 코드 검토가 좋은 환경이 될 수 있습니다.

코드 리뷰는 다음에 관한 것이 아닙니다.

… 버그 찾기. 그것이 바로 테스트의 대상입니다. 코드 검토에서 문제가 발견되는 경우가 종종 있습니다.
… 스타일 문제에 대한 nitpicking – 하나의 스타일에 정착하고 자동 포맷터를 사용하여이를 시행합니다. 그러나 자동화 된 도구로는 확인할 수없는 것이 많습니다. 코드 검토는 코드가 충분히 문서화되거나 자체 문서화되도록하기에 좋은 장소입니다.

— 아몬
소스

2

전적으로 동의하지 않는 nitpicking 스타일 문제에 대한 마지막 요점-우리는 주니어 개발자의 코드를 검토하는 경험이 많았습니다. 시행 .... 엣지 케이스 등에 대한 if 문이 너무 많음; 그렇습니다. 어떤 경우에는 컴퓨터가 찾도록 만들 수 있지만 대부분은 일반적으로 스크립트로 찾을 가치가있는 문제가 아닙니다. 30 초 동안 읽는 데 걸리고, 30 초는 개발자에게 설명하고 문제를 수정하기 위해 30 초가 더 걸립니다. 아직도 충격 : /

— 평화주의

7

@pacifist 응답자가 묘사하는 스타일이 아닙니다. 스타일은 버팀대의 위치, 들여 쓰기 등입니다. 주니어 개발자가 너무 많은 if 문을 사용하는 경우 스타일과 완전히 다른 문제가 있습니다. STYLE 코딩의 일반적인 특성은 성능에 영향을 미치지 않는다는 것입니다. 그리고 상당한 양의 if 문이 성능에 영향을 줄 것이라고 생각합니다.

— Pimgd

12

리뷰를 할 때, 나는 종종 "이것이 버그처럼 보인다"고 생각되는 것을 발견 한 다음, 특정 테스트 케이스를 작성하여 그것이 버그임을 증명합니다. 따라서 코드 검토의 많은 목표 중 하나는 버그를 찾는 것입니다. 그렇기 때문에 "코드 검토 또는 테스트"라는 관점이 너무 단조 롭다고 생각합니다.

— Doc Brown

2

@DocBrown 외에도 데이터 레이스, 일부 교착 상태, 라이브 록, 정의되지 않은 동작 / 값 (주로 C / C ++이지만 해시 테이블의 요소 순서는 정의되지 않음) 또는 리소스 파와 같이 쉽게 테스트 할 수없는 경우가 있습니다. (루프에서 파일을 여는 것은 GC조차도 나쁜 생각 일 수 있습니다). 이러한 것들 중 일부는 충분히 똑똑한 컴파일러 정적 분석 으로 감지 할 수 있습니다 .

— Maciej Piechotka

2

@pacifist 특정 예제는 코드 검토에서 완전히 폭파됩니다. 또한 정적 코드 분석기 (Cyclomatic complex 17!)에 대한 위험 신호이기도합니다. 코드 검토는이 기능을 시맨틱 스타일 (또는 알고리즘!)의 문제점으로 신속하게 식별합니다. 하나. 이런 종류의 문제는 단순한 "스타일"문제가 아닙니다. 그렇게 취급하면 곧 저장소에 불쾌한 코드가 생길 것입니다. 결국 "스타일"입니다.

— Pimgd September

12

내가 코드 검토에서 개인적으로 얻는 가장 중요한 것은 코드가 다른 사람에게 명확 하다는 확신입니다 . 변수의 이름이 명확합니까? 각 코드 덩어리의 목적이 합리적으로 명백합니까? 코멘트로 모호한 것이 있습니까? 매개 변수에 대한 대소 문자와 유효한 값이 주석에 설명되어 있고 코드에서 확인 되었습니까?

2

이것은 이전의 4 가지 답변보다 실질적인 것을 제공하지 않는 것 같습니다

— gnat

2

@ gnat : 다른 답변은 지식 이전 및 발견 버그를 해결합니다. 이것들은 중요하지만 코드 검토에 더 많은 것이 있습니다.

1

내가 알 수있는 한, 이 답변 에는 더 많은 부분이 합리적으로 설명되어 있습니다 . "동료 리뷰의 이점과 구현 전략에 대한 포괄적 인 논의를 원한다면 소프트웨어에서 피어 리뷰를 확인하는 것이 좋습니다. Karl Wiegers의 실용 가이드. " 이 답변 은 또한 다음과 같은 내용을 다룹니다. "매우 복잡한 코드에 대한 교정"

— gnat

2

@gnat 다른 답변에서 제기 된 요점의 다른 측면을 강조합니다. 6 개월 전에 작성한 자신의 코드에 당황한 적이 있습니까? 코드 검토를 통해 해당 프로세스를 가속화 할 수 있습니다. 동료가 코드에 의아해하는 경우에도 문제가 여전히 기억에 남는 동안 명확하게 확인할 수 있습니다.

— 200_suc.

1

아마 @ 200_success. 그러나이 시점이 실제로 존재한다면 실제로는 제대로 보이지 않습니다. 귀하의 의견조차도이 "답변"보다 더 나은 의견을 전달할 수 있습니다. 말할 것도없이 관련 질문에서 이것을 설명하는 정식 답변을 언급 하는 이전 의견 에서 지적 된 내용을 반복한다는 점은 말할 것도 없습니다

— gnat

7

다른 훌륭한 답변으로 다루지 않는 두 가지 영역을 추가하고 싶습니다.

코드 검토의 가장 큰 이유 중 하나 는 우리의 경우 다음과 같이 해석되는 호손 효과 입니다.

또 다른 중요한 이유는보다 안전한 개발 방법입니다. 안전한 개발 라이프 사이클에서 적절한 코드 검토의 중요성을 이해하려면 Apple의 goto fail (실수로 중복 된 코드 라인) 또는 Heartbleed 버그 (입력 유효성 검사의 기본 실패 ) 만 살펴 봐야 합니다.

— 크리스 나이트
소스