1. 리뷰를 짧게 만드십시오.

   특히 코드 검토 중에는 오랫동안 집중하기가 어렵습니다. 또한, 긴 코드 검토는 코드에 대해 말할 것이 너무 많거나 (다음 두 요점 참조) 검토가 아키텍처와 같은 더 큰 문제에 대한 논의가됨을 나타낼 수 있습니다.

   또한 검토는 토론이 아닌 검토로 유지되어야합니다. 그렇다고 코드 작성자가 답장을 보낼 수는 없지만 긴 의견 교환으로 바뀌지 않아야합니다.

2. 너무 나쁜 코드는 검토하지 마십시오.

   품질이 낮은 코드를 검토하면 검토 자와 코드 작성자 모두에게 우울합니다. 코드 조각이 끔찍하면 코드 검토가 유용하지 않습니다. 대신, 작성자는 코드를 올바르게 다시 작성해야합니다.

3. 검토하기 전에 자동 체커를 사용하십시오.

   자동 체커는 ​​자동으로 발견 될 수있는 귀중한 시간 낭비를 피합니다. 예를 들어 C # 코드의 경우 StyleCop 실행, 코드 메트릭 및 특히 코드 분석은 검토 전에 일부 오류를 찾을 수있는 좋은 기회입니다. 그런 다음 코드 검토는 머신에서 수행하기 매우 어려운 포인트에 사용될 수 있습니다.

4. 검토하는 사람을 신중하게 선택하십시오.

   서로 견딜 수없는 두 사람은 다른 사람의 코드 중 하나를 잘 검토하지 않습니다. 한 사람이 다른 사람을 존중하지 않을 때도 같은 문제가 발생합니다 (심지어 리뷰어이든 저자이든 관계없이).

   또한 일부 사람들은 코드 검토를 볼 수 없으므로 비판을받지 않았으며 부정적인 것으로 보아서는 안된다는 것을 이해하기 위해 특정 교육과 준비가 필요합니다. 준비되지 않은 검토를하는 것은 도움이되지 않을 것입니다. 왜냐하면 항상 방어적일 것이며 그들의 코드에 대한 비평가들을 듣지 않을 것입니다 (비평으로 모든 제안을하는 것).

5. 비공식 및 공식 검토를 모두 수행하십시오.

   점검표를 작성하면 정확한 결함에 집중할 수 있으며 니트 피킹으로 전환하지 않아도됩니다. 이 점검 목록에는 다음과 같은 점이 포함될 수 있습니다.

   • SQL 인젝션,
   • 오류로 이어질 수있는 언어에 대한 잘못된 가정,
   • 운영자 우선 순위와 같은 오류로 이어질 수있는 특정 상황. 예를 들어 C #에서는 var a = b ?? 0 + c ?? 0;병합이 0 인 두 개의 nullable 숫자를 추가하려는 사람에게는 적합 할 수 있지만 그렇지 않습니다.
   • 메모리 할당 해제
   • 게으른 로딩 (두 가지 위험이 있습니다 : 동일한 것을 두 번 이상로드하고 전혀로드하지 않음),
   • 넘침,
   • 데이터 구조 (예 : 해시 세트 대신 단순 목록과 같은 오류가 있음)
   • 일반적으로 입력 검증 및 방어 프로그래밍
   • 나사산 안전
   • 기타

   나는 여기서 목록을 멈췄지만, 정확한 저자의 약점에 따라 체크리스트에 나타날 수있는 수백 점이 있습니다.

6. 점검표를 점진적으로 조정하십시오.

   시간이 지남에 따라 건설적이고 유용한 상태를 유지하려면 발견 된 실수에 따라 정식 검토에 사용되는 체크리스트를 시간이 지남에 따라 조정해야합니다. 예를 들어, 첫 번째 비공식 검토를 통해 SQL 주입의 특정 위험이 드러날 수 있습니다. SQL 주입 검사가 검사 목록에 포함됩니다. 몇 개월 후 작성자가 동적 쿼리와 매개 변수화 된 쿼리에 대해 매우주의를 기울이면 SQL 주입이 검사 목록에서 제거 될 수 있습니다.

답변