코드 검토와 코드 검사의 차이점은 무엇입니까?

Question

두 가지의 차이점을 이해하려고합니다. 어떤 도움이라도 대단히 감사하겠습니다.

잠재적 중복 :https://stackoverflow.com/questions/52598/code-walkthrough-vs-code-review

Answer 1

내가 리뷰 구문 같은 사물을 보는, 조금 더 빨리 말할 것 - 주석 - 명명 규칙 - 모범 사례 같은 맥락으로

, 코드 검토 것 더 깊이있게 - 품질을 확인하고 일이 의도 한대로 작동하는지 확인하십시오.

Answer 2

코드/소프트웨어 검사는 피어 리뷰와 같습니다. 코더 그룹은 결함에 대해 소프트웨어를 검사하고 프로젝트에서 사용할 수있는 내용에 대한 합의에 도달합니다. 사용 된 주요 방법 중 하나는 Fagan inspection입니다.

코드 검토는 검사와 비슷하지만 기본적으로 검사관은 특정 코드 블록을보고 결함/버그를 수정합니다. 프로그래머가 의도 한대로 작동하지 않거나 프로젝트 요구 사항에 맞지 않는 코드 부분을 지적함으로써 신입 사원을 돕는 데 더 효과적입니다.

Answer 3

참고 : 이것은 엄밀히 말하면 산업 관점입니다.

나는이 두 용어가 투기와 토론 이외의 일을하기에 충분한 정의가 부족하다고 말할 것이다. 나는 둘 다 대기업과 중소기업에서 수없이 많이 사용되었다는 이야기를 들었습니다. 그리고 사람들이 근본적인 정의가 작업 기간이나 적용 범위와 어떻게 다른지 실제로 생각한 상황을 본 적이 없습니다. 그것은 단지 코드를 검사/검토하는 것입니다. 둘 다 코드가 뚜렷한 오류가 없는지 확인하고 결정된 모든 규칙을 따릅니다.

Answer 4

나는 검토를 더 형식적이고 더 나은 정의와 함께 검토의 하위 집합으로 생각합니다. "내 코드를 보러 올 수 있니?" "어떻게 보이나요?" 코드 검토로 이어지는 질문의 종류 - 쌍 프로그래밍은 코드 검토의 일종입니다. 코드 검사는 의제와 준비가 포함 된보다 공식적인 회의입니다. 나는 스티브 맥코넬의 코드 완성이 내가이 구별을 배웠던 곳이라고 믿는다.

Answer 5

이전 고용주는 본질적으로 3 가지 수준의 코드 검토 작업을 수행했습니다.

우리는 코드 (또는 디자인)의 연습을 수행하고 필자 이외의 참가자의 준비 작업을 본질적으로 포함하지 않았습니다. 연습의 주요 초점은 기능의 일부, 해결하려고 시도한 문제 및 작성자가 취한 접근 방식을 논의하는 것이 었습니다. 이는 팀 또는 팀의 하위 집합이 전체 시스템의 세그먼트 (수십 명의 개발 인력이있는 상당히 큰 시스템 이었음)를 인식하고 팀에서 많은 시간을 들이지 않고도 일부 문제를 해결하는 데 도움이되었습니다.

독자적으로 제품을보고 질문을하거나 제품에 대한 의견을 써서 저자에게 피드백을 제공하는 사람들로 구성된 코드/디자인 리뷰를 자체적으로 수행했습니다 화려 함과 정식 검사의 상황이없는 팀.

정식 검사에는 운영자와 서기 및 특정 역할을 맡은 N 검사원이있는 것과 같은 원숭이 비즈니스가 관여했습니다. 일부 관리자의 Excel 스프레드 시트에 대한 지표를 유지하고 회의에서 표시 할 차트를 만들었습니다. 나는이 사건의 상당 부분을 시간 낭비로 보았는데, 이는 일반적으로 내부 검토가 일반적으로 그랬던 것처럼 효과적 이었기 때문이다.우리는 결함에 대해 수정 된 사항에 대해 공식적인 승인을 받았으며 필요한 경우, 특히 중요한 오류의 수정은 우리가 작성한 소프트웨어의 특성으로 인해 발생했습니다.

연습을 통해 많은 결함을 발견 할 수는 없지만 일부는 발견 될 수 있으며 일반적으로 프로세스 초기에 발생할 수 있습니다.

리뷰는 사람들이 제품을 검토해야한다는 사실 때문에 더 많은 결함과 문제점을 찾는 경향이 있습니다. 적어도 콩 카운터의 관점에서 볼 때, 일정을 잡을 시간이 필요한 사람이 필요합니다. 실제로 우리는 일반적으로 코드를 볼 시간을 가질 수 있기 때문에 일정에 많은 영향을 미치지 않았습니다.

최소한 중요한 검사는 안전에 중요한 소프트웨어가 관련된 부분을 제외하고는 부분적으로 체크 박스 운동이었습니다. 그런 다음 소프트웨어가해야 할 일을하도록 보장하고 시스템을 이해해야하는 여러 사람이 무슨 일이 일어나는지 자세히 살펴볼 수있는 또 다른 기회였습니다. 나는 우리가 속한 환경이 헌신 수준에 영향을 미치고 검사의 효율성 수준에 영향을 미쳤다고 생각한다. 일정이 왕이되고 검사가 상자 검사 이벤트로 축소되는 경우가 많았다.

어쨌든, 저는 업계에 대해 잘 모릅니다. 그러나 그것이 우리가 일을 한 방법입니다.

Answer 6

없음. 두 경우 모두 더 나은 코드를 얻는 것이 목적입니다.

의미는 다를 수 있지만 목적은 동일합니다. BETTER CODE.

그게 전부입니다.

Answer 7

내 book about peer code review에 대해 썼습니다.

공통 언어로는 전혀 차이가 없으며, 이는 일반적으로 제공하는 대답입니다.

학술 문헌에서 "검사"는 일반적으로 중량이 많은 프로세스로 전체 문서 검토를 의미합니다. 이 과정에는 "독서"단계 (자체 검토 자)와 "검사"단계 (모두 함께 방에 있음)를 포함한 Fagan Inspection 부분의 전부는 아니더라도 일부가 포함됩니다. 각 사람은 특정 목표를 가진 역할 (예 : 중재자, 작성자, 독자, 검토 자)이 있습니다.

Fagan Inspection에서 직접 교육을 받았으므로 특히 Fagan 방법이 엄격하고 코드 인쇄물을 필요로한다고 말할 수 있습니다.

실제로는 명백한 시간 제약으로 인해 이러한 유형의 "검사"를 수행하는 사람은 거의 없습니다. 나는 "검토"를 성공적으로 수행 한 사람들이 경량 기법을 사용하는 경향이 있음을 발견했다.

가벼운 "코드 검토"기술은 코드를 버전 제어, 페어 프로그래밍, 코드 검토를 위해 특별히 만든 회사 중 하나 인 Code Collaborator, Atlassian 's Crucible 등을 사용하여 전자 메일을 자동으로 보내고, 오픈 소스 인 CodeStriker와 Review Board가 있습니다.

필자는 개인적으로 경량 기술이 공식 검사보다 80-90 % (데이터 및 연구용 책 참조) 효과적이라고 생각하지만, 시간이 조금 걸리는 것은 어렵지 않습니다 (2 시간 회의 4 명은 사람 - 하루의 시간). 따라서 효과가 절반이라고 생각하더라도 여전히 더 똑똑한 시간을 사용합니다.