필수 코드 검토를위한 좋은 지침 및 관행 [폐쇄]

우리는 두 가지 스프린트에 대해 각 커밋에 대해 필수 코드 검토를 시도하고 있습니다. 저자가 아닌 적어도 한 사람이 검증하지 않은 마스터에는 아무것도 없습니다. 우리는 개발자와 경영진 모두로부터 구매했으며 (이것은 놀라운 상황입니다) 우리는 다음과 같은 이점을 얻고 싶습니다.

• 명백한 버그 감소
• 프로젝트 주변에서 일어나는 변화에 대한 인식
• "누군가 이것을 보지 못해서 게으르지 않을 것"/ 카우보이 효과
• 프로젝트 내 / 전체의 일관성 향상

그러나 우리는 속도를 줄이는 것으로 알려진 것을 소개하고 있으며 , 잘못하면 커밋 파이프 라인에서 어리석은 관료적 단계를 만들어서 시간이 걸리지 않습니다. 내가 걱정하는 것들 :

• 그냥 따기 따기 리뷰
• (대체적으로) 사람들은 두 줄 커밋 검토의 일환으로 거대한 건축 문제를 제기합니다.
• 나는 다른 것들에 대한 대답을 편견하고 싶지 않습니다.

우리는 모두 합리적 인 사람이며 많은 자기 분석을 수행 할 것입니다. 검토 세션에서 어떤 종류의 일을 수행하여 검토를 실제로 수행 해야하는지에 대한 통찰력을 확실히 사용할 수 있습니다. . 작동하는 것으로 밝혀진 몇 가지 지침과 정책은 무엇입니까?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

우리는 체크리스트를 거의 좋아합니다.

• 작업 설명을 보여주세요.
• 결과를 안내하고 제대로 작동하는지 보여주세요. 다른 시나리오를 실행하십시오 (유효하지 않은 입력 등).
• 통과 테스트를 보여주세요. 테스트 범위는 어떻습니까?
• 코드를 보여주십시오-우리가 명백한 비 효율성을 찾고있는 곳입니다.

상당히 잘 작동합니다.

다른 사람을 지배하는 사람, 관리자 또는 중재자는 관련없는 의견을 잘라 내고 빠른 검토가 필요한 사항을 빠르게 검토하기에 충분하다고 생각합니다. 단일 의사 결정자.

이것의 마이너스는이 사람이 다른 일을 할 수있는 동안이 주요 업무로해야한다는 것입니다. 아마도이 경험이 많은 사람을 원할 것입니다.

두 번째는 가능한 한 자동화하는 것입니다!

• 공백 제어
• 스타일 제어 소프트웨어
• 코드 검토 전 자동 빌드
• 코드 검토 전 자동 테스트

그러한 것들은 사람들이 실제 필요없이 언급 할 수있는 것 중 적어도 일부를 제거 할 것입니다. 공백이 없거나 후행 공백이 있으면 검토하기에 충분하지 않으며이를 수정 한 후 다시 검토하십시오. 그것이 구축 중이 아니거나 테스트가 실패하면 충분하지 않다는 것이 분명합니다.

대부분 기술에 따라 다르지만 자동으로 더 잘 확인할 수있는 것을 찾으십시오.

우리는 아직이 전투에서 이기지 못했지만 그것이 우리가 유용하다고 생각한 것입니다.