iOS 개발자로서 나는 동료들로부터 수천 줄의 코드를 검토했습니다. 프로그래밍과 마찬가지로 코드를 검토하면 똑똑하거나 완전히 바보 같은 느낌이 듭니다.

이는 코드 검토의 주요 문제 때문입니다.
1. 사람들은 자신이 코드를 검토하는 이유를 정말로 모릅니다.
2. 사람들은 올바른 것을 검토하지 않습니다.
3. 풀 요청은 검토할 수 없습니다.

이 기사에서는 코드를 검토하는 이유 에 중점을 둡니다.

몇 가지 이유

나는 면접에서 많은 지원자들에게 이 질문을 했고, 매우 다양한 대답을 들었다. 사람들은 종종 코드가 실제로 좋은 방법 인 이유에 대한 심화 없이 잘 알려진 좋은 방법이기 때문에 코드를 검토합니다 .

우리가 코드를 검토하는 이유를 살펴보기 위해 스스로에게 물어볼 수 있는 가장 좋은 질문은 다음과 같습니다. 왜 다른 사람이 우리 코드를 검토하기를 원할까요?

몇 가지 이유는 다음과 같습니다.

• 우리가 아닌 다른 사람이 코드를 이해할 수 있는지 알고 싶습니다.
• 변수 이름, 클래스, 메서드 등과 같은 다른 혼란스러운 영역을 식별하려고 합니다.
• 우리는 무언가를 잊어버렸을 때(즉, 마지막 순간에 변수 이름을 변경했고 일부 디자인 결함이 명백해진 경우) 상기시켜 줄 수 있는 또 다른 쌍의 눈을 원합니다.
• 동일한 문제를 해결하기 위해 더 나은 접근 방식을 취할 수 있는지 동료로부터 배우고 싶습니다.
• 오타를 내어 `tomato` 대신 `tmoato`라는 변수를 호출하여 이제 야채 수를 세던 클래스가 대신 마야 신을 소환하는 것 같습니다.

목록을 주의 깊게 살펴보면 목록에 실제로 더 많은 사람이 필요한 항목이 두 개뿐이라는 것을 알 수 있습니다.

이것은 코드 리뷰의 특수성입니다. 대부분의 경우 풀 리퀘스트를 생성할 때 검토할 수 있는 가장 좋은 사람은 본인입니다. 당신은 오타와 당신이 잊은 거의 모든 것을 발견할 것입니다.

개발자는 혼자가 아닙니다. 작가들도 마찬가지다.

Stephen King은 출판사에 소설을 보내기 전에 세 번의 초고를 거친 것으로 알려져 있습니다. 1차 초안부터 2차 초안까지 피드백도 요구하지 않고 직접 검토한다.

친숙하게 들리나요?

시도 해봐.

다음에 풀 리퀘스트를 만들 때는 먼저 직접 검토하세요. 그런 다음 다른 사람에게 검토를 요청하십시오. API를 설계할 때 이해하기 어려운 영역이나 잘못된 결정과 같은 귀중한 피드백을 강조할 것입니다.

이유 이해

자신의 코드를 검토할 때 대부분의 오타, 누락된 테스트 또는 기본적인 실수를 쉽게 식별할 수 있습니다. 그러나 "Chief"라는 단어가 "chef"라고 쓰여 있다고 믿는다면 여전히 리더에 대해 이야기하고 싶을 때 요리사에 대해 이야기할 것입니다. 다른 한 쌍의 눈은 코드를 다듬는 마지막 세부 정보를 찾는 데 도움이 될 수 있습니다.

즉, 코드를 검토할 때 다른 사람이 스스로 검토할 수 있는 영역에 대해서만 언급한다면 요점을 놓치고 있는 것일 수 있습니다.

코드 검토는 피드백을 받고 명확성을 확인하고 이해한 내용을 다른 사람이 이해할 수 있는지 확인하는 것입니다.

무엇 향후 계획?

이제 우리가 코드를 검토하는 이유를 알았으니 무엇을 검토해야 하고 어떻게 수행해야 하는지 더 잘 이해해야 합니다 . 이 기사에서 일부 답변을 제공했지만 구체적인 예를 제공하면서 더 깊이 파고들 것입니다.

다음 기사를 사용할 수 있는 시기에 대한 업데이트를 받으려면 볼보 자동차 엔지니어링을 팔로우할 수 있습니다 . 이를 통해 많은 엔지니어가 통찰력과 학습 내용을 공유하도록 지원할 수도 있습니다.