주: 이 내용은 최초로 제 블로그Beyond The Loop에 발표되었습니다.
만약 당신이 좋아한다면 그곳에 가거나 트위터 () 의 블로그에 관심을 가지고 더 많은 것을 알 수 있습니다!

This is a very long post, but it's worth reading! If you're in a hurry, I'll leave the condensed version of the list at the end.

코드 심사는 엔지니어의 기본 기능이다.
일련의 변화를 읽고 유용한 견해와 건설적인 피드백을 얻을 수 있다면 당신은 동료로서 값을 매길 수 없을 것이다.그 밖에 더 좋은 코드가 생길 것이다!
그러나 처음에는 매우 무서웠을 수도 있다.당신의 첫 번째 요청을 보고 어디서부터 시작해야 할지 모르겠습니다. 이것은 정상입니다.
나는 처음에 이 문제가 있었기 때문에 줄곧 나에게 효과적인 일을 했다.
나는 나의 베테랑 동료에게 그들의 사고 과정을 물었다.그들은 어떻게 코드 심사를 진행합니까?그들은 무엇을 찾고 있습니까?그들은 어떤 문제를 묻습니까?
이 모든 답안을 고려하여 나는 자신의 명세서를 작성했다.복습 과정에서 나는 일련의 문제로 나의 생각을 인도할 수 있다.
명확하고 반복할 수 있는 과정이 있어서 나는 복습하는 과정을 더욱 작은 부분으로 분해하여 그다지 이해하기 어렵지 않게 할 수 있다.
요 몇 년 동안 이 명단은 나에게 매우 귀중하다.나는 그것이 너에게도 가치가 있기를 바란다.

1단계: 설명 읽기

Reviewing code is the act of finding out how well it solves a problem.

어떤 코드를 작성하기 전에 몇 가지 질문에 대답해야 한다.코드를 읽기 전에 이렇게 하는 것은 매우 중요하다. 왜냐하면 코드 스타일과 미시적 최적화의 본질을 잃기 쉬우므로 이런 변화가 어떻게 전체 국면에 영향을 미치는지 생각하는 것을 잊어버리기 때문이다.
사실 코드 심사의 대부분 가치는 코드를 읽는 것이 아니라 이런 질문에 대답하는 것이다.
이 변화는 어떤 문제를 해결하려고 시도합니까?
이것은 매우 중요한 문제다.모든 공관은 반드시 하나의 문제를 해결해야 한다.
문제는 "이 기능이 필요하지만 부족합니다"혹은 "버그가 있습니다. 복구해야 합니다."입니다.
PR 검토는 문제 해결의 효과를 발견하는 과정입니다.따라서 이 문제를 깊이 있게 이해하는 것이 중요하다.
질문, 표현 방법, 사용자에게 어떻게 영향을 미치는지 확인하십시오.
나는'문제'라는 단어를 자주 사용하지만, 그것은 매우 중요하기 때문이다.
당신은 이 문제를 어떻게 해결할 것입니까?
작가가 이 문제를 어떻게 해결하는지 배우기 전에 당신이 그것을 어떻게 해결할 것인지를 생각해 보세요.
그것은 반드시 완전한 해결 방안이 아니라, 단지 무엇처럼 보이는 일반적인 생각일 뿐이다.너는 네가 이렇게 신속하게 그것의 전체 구조를 찾을 수 있다는 것을 놀라게 될 것이다.
이것은 매우 유용하다. 두 가지 이유가 있다.

이 문제를 진정으로 이해하는지 알려줄 것이다.만약 해결 방안을 생각해 내지 못한다면, 상하문을 놓쳤을 가능성이 높으며, 변경과 관련된 코드 라이브러리 부분을 더 많이 알아야 한다.

이 문제에 대해 새로운 생각을 가지면 완전히 다른, 더 좋은 해결 방안을 초래할 수 있다!그렇다면 다행이다!저자와 이야기를 나누며 새로운 해결 방안을 토론하다.

해결 방안에 대한 생각이 생기면 다음 질문은 다음과 같습니다.
저자는 이 변화 속에서 어떤 해결 방안을 제기했습니까?
이것은 제목과 묘사에서 명확해야 한다.기억해라, 우리는 심지어 코드를 본 적이 없다.해결 방안과 그 모든 부분을 이해하고 동의해야 합니다.
이 질문을 하면 종종 우리로 하여금 깨닫게 한다.

Dell은 솔루션의 일부분에 대해 잘 알지 못합니다. 만약 이러한 상황이 발생한다면 당신이 이해하지 못하는 정확한 내용을 찾아내고 기존 코드와 문서를 읽어야 합니다!

우리는 이 해결 방안에 동의하지 않는다. 만약 그렇다면 평론을 멈추고 작가와 이 문제를 토론하는 데 집중해야 한다.당신의 우려를 제기하고 대체 방안을 추가하며 당신과 저자 모두를 만족시키는 해결 방안을 찾습니다!

당신은 이 해결 방안의 효과에 동의합니까?
대다수의 공사 문제에는 모두 균형이 존재한다.더 복잡한 해결 방안은 더 빨리 실행될 수 있지만 유지하기가 더욱 어렵다.그것은 비교적 느린 해결 방안에 더 많은 메모리가 필요할 수도 있다.다른 한편, 더 간단한 해결 방안은 더 느릴 수도 있지만 유지하기 쉬우며 성능의 관건이 아닐 수도 있다.
코드를 작성하기 전에, 우리는 균형이 무엇인지, 그리고 이것이 정확한 균형이라는 것에 동의해야 한다.

성공했어!

만약 당신이 이 점을 해냈다면, 이것은 당신이 지금 이 문제에 대해 깊은 이해를 가지고, 해결 방안이 정확하다는 것을 동의한다는 것을 의미한다.
너무 좋아요.
이 사고방식만으로도 당신의 평론은 믿을 수 없는 영향력을 갖게 될 것이다. 왜냐하면 당신은 먼저 중대한 문제를 식별하고 세부 사항을 잃지 않기 때문이다.
이제 이런 깊은 이해가 생겨서 우리는 코드를 깊이 연구하려고 한다.
숨을 깊이 들이쉬고 실질로 들어가자!

2단계: 코드 읽기...몇 번

... we're going to go through the changes multiple times, answering a different question each time.

코드로 들어가자!
지금우리 어디서부터 시작할까?
복습 페이지에 뛰어들어 읽기 시작하면 무섭다.너무 좋아요!어디 봐요?
이곳의 주요 문제는 우리가 모든 것을 동시에 고려하려고 하는 것이다.나는 너의 상황을 모르지만, 나는 할 수 없다.
우리가 코드를 심사할 때, 우리는 많은 것을 찾아야 한다.

코드는 설명에 기술된 해결 방안을 실제로 실현했습니까?

성능 문제가 있습니까?

코드는 양호한 테스트를 거쳤습니까?

코드가 형식과 스타일 표준에 부합됩니까?

이것은 많은 고려가 필요하다!따라서 우리는 이런 변화를 처음 볼 때 모든 질문에 대답하려고 하지 않고 이런 변화를 여러 차례 겪으며 매번 다른 질문에 대답하려고 한다.
이것은 우리가 생각하는 범위를 한 문제로 축소시킬 것이다.
예를 들어 다음과 같은 질문에 어떻게 대답하는지 봅시다. "코드가 좋은 테스트를 거쳤습니까?"
좋아, 명확한 진로가 있다. 우리는 테스트를 시작해서 우리가 포함해야 한다고 생각하는 모든 사례를 포함했는지 확인해야 한다는 것을 안다.이것은 절대로 그렇게 무섭지 않다!
비결은 모든 문제를 똑같이 처리하는 것이다.

질문 하나를 선택합니다.

이 문제를 검증하기 위해 코드 변경을 검사합니다.

에 평론을 남기다.

1로 이동합니다.

우리는 성능을 검사해야 합니까?만약 우리가 관련된 부분을 이해한다면, 우리는 어떤 부분이 속도가 느리고 민감한지 잘 알아야 한다. (왜냐하면 그들은 자주 운행하기 때문이다.)우리는 우선 이런 것에 관심을 가져야 한다.
형식과 이름을 검사해야 합니까?우리는 코드의 작용을 잊어버리고 문자와 기호만 읽을 수 있다.
자신의 질문 목록을 만들어서 코드를 물어봐야 하지만, 제 질문은 다음과 같습니다.

코드는 상기 해결 방안을 실현했습니까?

의식적으로 성능 평가를 하는가?

무의식적인 실적 저효과가 존재하는가?

명명 및 스타일 안내서에 해당합니까?

양호한 테스트를 거쳤습니까?

이해하기 어려운 부분이 있나요?그들은 반드시 거기에 있어야 합니까?만약 그렇다면, 그것들은 적당히 격리되고 기록됩니까?

다시 한 번

나는 너에게 간단명료한 명세서를 달라고 약속했었다.나는 그것을 무료 정보 도표로 만들 계획을 하고 있다. 출력할 수 있기 때문에 메일 리스트를 구독해서 이런 상황이 발생할 때 통지를 받을 수 있다.

**Before Reading Code**
These should be checked by reading the description and existing code, not the changes themselves!
- [ ] I understand the problem this change is trying to solve.
  - [ ] I understand and agree with why we need this feature or bug solved.
  - [ ] I understand all the pieces involved in causing the problem.
- [ ] I have a general idea of how I'd solve the problem.
- [ ] I agree with the solution proposed.
  - [ ] I agree with the performance tradeoffs presented in the solution (if the change is perf-sensitive).
  - [ ] If not, I have talked with the author until we've reached consensus.

**When Reading the Code**
We should make one pass for each of these questions.
- [ ] The code implements what's actually described as the solution.
- [ ] The code doesn't have unintentional inefficiencies.
- [ ] The code conforms to naming and code style guidelines.
- [ ] There are no unnecessary hard-to-understand parts.
  - [ ] The ones that are there are properly isolated and document.
- [ ] The code is well-tested.

이 모든 내용을 돌이켜보면 더 좋은 코드를 만드는 데는 값을 매길 수 없다!

끝내다

그렇습니다!
코드 심사 목록: 완성!
물론 이것은 매우 시간을 소모하는 과정이다.하지만 당신의 다섯 번째 복습은 올바른 복습에 관한 것입니다.코드 심사는 하나의 기술이다. 사람들은 약간의 시간을 필요로 한다.
좋은 소식은 네가 요령을 익히면 더욱 빨라진다는 것이다.
이런 평론을 한 후, 당신은 무의식적으로 하나하나 질문을 하기 시작했고, 어디서부터 시작해야 하는지에 대한 직감을 형성하기 시작했다.
수십 차례의 심사를 거쳐서, 나는 명세서에서 한 걸음 한 걸음 걷는 일이 매우 드물지만, 나는 내가 이런 까다로운 심사를 하게 되어 매우 기쁘다.
당신의 명세서에는 무엇이 있습니까?트위터나 email를 통해 알고 싶습니다.
주: 이 내용은 최초로 제 블로그Beyond The Loop에 발표되었습니다.
만약 당신이 좋아한다면 그곳에 가거나 트위터 () 의 블로그에 관심을 가지고 더 많은 것을 알 수 있습니다!