대규모 개발 조직에서 코드 검토는 승인 문서와 유사합니다.

코드 리뷰와 승인 문서를 비교하는 글은 많지 않습니다. 코드 리뷰는 특별한 것으로 설명됩니다. 정말 다른가요?

기간 비교

코드 검토 및 승인 문서와 관련된 용어를 살펴보겠습니다.

차이점이 뭐야?

승인에는 명확한 계층 관계가 있지만 코드 검토는 계층 관계의 영향을 상대적으로 덜 받습니다. 승인은 부하직원이 상급자에게 요청하는 단방향이지만, 코드 리뷰는 팀원이 다른 팀원이나 팀장에게 리뷰를 요청하고 팀장이 개발팀원에게 리뷰를 요청하는 양방향이다. 물론 코드 리뷰에도 계층적 효과가 있습니다. 팀원은 CTO 또는 팀 리더의 더 많은 리뷰를 반영합니다. 지금까지 코드 검토는 승인 문서와 다릅니다.

개발 조직의 관료화 및 코드 검토 승인 문서화

개발 조직의 규모가 커질수록 관료주의적이 됩니다. 관료주의는 나쁜 것이 아닙니다. 대규모 조직에 필수적입니다. 관료적이 될수록 코드 검토는 승인 문서에 가까워집니다. 코드 오류로 인한 실패의 책임은 개발팀 담당자가 져야 하기 때문이다. 담당자는 승인에 신중을 기할 수밖에 없으며 담당자의 승인 없이는 코드 반영이 불가능합니다. 담당자가 대부분 상사이므로 결재서류 처리방식과 동일합니다.

대규모 개발 조직에서의 코드 검토 = 승인 문서

소규모 개발 조직에서는 상호 검토가 주된 형태이므로 작성자의 판단에 따라 일부 검토가 반영되거나 반영되지 않을 수 있습니다. 그러나 대규모 개발 조직에서는 승인 문서로 생각하는 것이 좋습니다. 팀장의 리뷰는 필수! 반영해야 한다 팀장의 검토에 치명적인 오류가 있는 경우 당연히 보고해야 한다. 그렇지 않고 결과에 큰 차이가 없다면 바로 반영하는 것이 좋습니다. 팀장은 많은 회의로 바쁘다. 안건이 논의되고 결과에 차이가 없으면 승인이 늦어지고 다음 작업까지 대기 시간만 늘어납니다. 또한 팀장 입장에서는 팀원들이 자신의 평가를 무시하고 평판이 나빠질 수 있다고 느낀다. 중요하다면 논의하고 그렇지 않다면 빨리 반영하라.

잡지나 신문의 편집장

개발자는 프로그래밍 언어로 작성하는 것과 같습니다. 응용 프로그램이든 프로그램이든 최종 제품은 여러 사람이 작성합니다. 그런 면에서 제품의 품질을 전체적으로 관리하고 책임지는 사람이 필요하다. 잡지나 신문의 편집자처럼요. 공동 작업의 최종 승인자는 팀장이라고 이해하면 편리합니다. 잡지에 실렸지만 편집장의 승인을 받지 않은 기사는 잡지에 실릴 수 없습니다. 코드를 작성하지만 승인을 받지 못하면 애플리케이션에 포함되지 않습니다.