검토에서 CL 탐색 

요약 

무엇을 찾아야 하는지 알게 되었으므로 여러 파일로 분산 된 검토를 관리하는 가장 효율적인 방법은 무엇입니까?

1. 변화가 의미가 있습니까? 좋은 설명이 있습니까?
2. 변경의 가장 중요한 부분을 먼저 보십시오. 전체적으로 잘 설계되어 있습니까?
3. CL의 나머지 부분을 적절한 순서로 보십시오.

https://google.github.io/eng-practices/review/reviewer/navigate.html 

1 단계 : 변화에 대한 광범위한 견해 

CL 설명과 CL이 일반적으로 하는 일을 보십시오. 이 변화가 의미가 있습니까? 이 변경이 처음에 발생하지 않은 경우 변경이 발생하지 않아야 하는 이유에 대한 설명으로 즉시 응답하십시오. 이와 같은 변경을 거부하면 개발자에게 대신 수행해야 할 작업을 제안하는 것이 좋습니다.

예를 들어 이렇게 말할 수 있습니다.“감사합니다! 그러나 실제로 수정하려는 FooWidget 시스템을 제거하는 방향으로 진행 중이므로 지금은 새로운 수정을 하고 싶지 않습니다. 대신 새로운 BarWidget 클래스를 리팩터링 하는 것은 어떻습니까?”

검토자는 현재 CL을 거부하고 다른 제안을 제공했을 뿐만 아니라 정중하게 수행했습니다. 우리가 동의하지 않더라도 서로 개발자를 존중한다는 것을 보여주고 싶기 때문에 이러한 예의는 중요합니다.

원하지 않는 변경 사항을 나타내는 CL이 여러 개있는 경우 CL의 작성 전에 의사 소통이 더 많이 이루어질 수 있도록 팀의 개발 프로세스 또는 외부 기고자에 대해 게시 된 프로세스를 재 작업하는 것을 고려해야 합니다. 사람들이 많은 일을 하기 전에“아니오”라고 말하는 것이 좋습니다.

2 단계 : CL의 주요 부분 검사 

이 CL의 "주"부분 인 파일을 찾으십시오. 논리적으로 가장 많은 수의 변경 사항이 있는 파일이 종종 있으며 이는 CL의 주요 부분입니다. 이 주요 부분을 먼저 보십시오. 이는 CL의 모든 작은 부분에 대한 컨텍스트를 제공하고 일반적으로 코드 검토를 가속화합니다. CL이 너무 커서 주요 부품이 어느 부품인지 알아낼 수 없는 경우 개발자에게 먼저 무엇을 봐야 하는지 문의하거나 CL을 여러 CL로 분할하도록 요청하십시오.

CL의이 부분에 중대한 디자인 문제가 있는 경우, 나머지 CL을 검토 할 시간이 없어도 즉시 해당 의견을 보내야 합니다. 실제로 CL의 나머지 부분을 검토하는 것은 시간 낭비 일 수 있습니다. 설계 문제가 충분히 심각하면 검토 중인 다른 많은 코드가 사라지고 어쨌든 중요하지 않기 때문입니다.

다음과 같은 주요 설계 의견을 즉시 보내야 하는 중요한 이유는 두 가지입니다.

• 개발자는 종종 CL을 우편으로 보낸 다음 검토를 기다리는 동안 해당 CL을 기반으로 즉시 새 작업을 시작합니다. 검토 중인 CL에 주요 디자인 문제가 있는 경우 나중에 CL을 다시 작업해야 합니다. 문제가 있는 디자인에 대해 너무 많은 추가 작업을 수행하기 전에 이를 파악하려고 합니다.
• 주요 디자인 변경은 작은 변경보다 시간이 오래 걸립니다. 개발자는 거의 모든 기한이 있습니다. 이러한 기한을 지키고 코드베이스에 품질 코드를 유지하려면 개발자는 가능한 빨리 CL의 주요 재 작업을 시작해야 합니다.

3 단계 : 나머지 CL을 적절한 순서로 살펴 봅니다. 

CL 전체에 중대한 디자인 문제가 없음을 확인한 후에는 파일을 검토 할 수 있는 논리적 순서를 파악하면서 파일 검토를 놓치지 않도록 하십시오. 일반적으로 주요 파일을 살펴본 후에는 코드 검토 도구가 제시하는 순서대로 각 파일을 살펴 보는 것이 가장 간단합니다. 때로는 메인 코드를 읽기 전에 먼저 테스트를 읽는 것이 도움이 됩니다. 변경 사항이 무엇인지 알고 있기 때문입니다.