# 코드리뷰 #github # 문화 혹시 코드리뷰를 하고 계신 개발자 분이신가요?.. 저는 가끔 이런 생각을 한 적이 있어요. 내가 "신"도 아니고, "바이블"도 아닌데, 내가 하는 코멘트가 맞는 말일까. 오로지 내 주관이지 않을까 라는 생각도 했었는데요, 이번에 뱅크샐러드의 한 좋은 글을 보고 깊게 감명받아서 이번엔 "코드리뷰" 에 대한 이 회사의 글에서 추가적으로 제 사견을 좀 첨가한 코드리뷰 이야기를 전해드릴까합니다 🐥 코드리뷰를 "왜 누가 언제 어디서 무엇을 어떻게 " 라는 5w1h 관점에서 생각해보자구요. (사실 무엇을은 .. 코드리뷰 인 것 같아서 무엇은 ban 했습니다. 혹시 "무엇"에 관해서도 생각나는 코멘트가 있으면 이야기 해주세요) 1. 우린 코드리뷰를 왜할까? * 일관된 아키텍처를 유지하고 있는지 * 다른 해결 방법에 대한 의견 제시 * 버그가 발생할 수 있는 가능성 제시 * 기술적인 지식, 노하우 공유 * 히스토리 전달 이 글에서 코드리뷰는 위와 같은 5가지를 위해 한다고 해요, 그렇다면, 코드리뷰어는 자연스럽게 "같이 아키텍처를 이해하는 자", 혹은 "같은 지식, 기술을 행하는자" 라는 "누가" 가 자연스럽게 이어지게 되죠?! 그렇다면, 이 기세를 몰아 "누가" 로 가보겠습니다. 2. 누가 리뷰어가 되야하고,해당 pr 승인은 어떻게 되야할까? - 위에서 "왜"에서 다뤘듯이, "같이 아키텍처를 이해하는 자", 혹은 "같은 지식, 기술을 행하는자"가 됩니다. 어떻게 보면, 기술 아키텍처, 혹은 비즈니스 아키텍처를 이해한 자가 될 수 있겠네요 - 그렇다면, 내가 1명이 아닌, 복수 명을 리뷰어로 선택했을 때, 이제 선출방식이 필요합니다. 가. 다 승인 나. 메인 리뷰어의 승인 다. 한명만 아묻따 승인시 이건 케바케이기 때문에, 해당 팀에게 골을 넘기겠습니다. 3. 언제? = 우리는 코드리뷰를 언제까지 해야할까 = d-n 룰 - 리뷰의 우선순위 판단을 돕는 d-n 룰 이라 하는데요, pr 을 날린 사람이 d-day 를 라벨로 미리 지정해 놓는 것입니다. d-0 이라면, 재빨리 리뷰해야겠죠? - 대기업의 경우, 평균 코드 리뷰 시간이 15일 정도 된다는 통계를 어디서 본 것 같은데, 이런 룰로 우선순위를 가리면 좋을 것같아요. 4. 어디서? = 보통 깃허브 Pr 내에서라고 생각하는데, 여기서 추가해서 250줄 이상 인 복잡한 리뷰의 경우, 직접 설명을 요청할 수 있게 해야할 것 같습니다. 5. 어떻게? 해당 글에서는 Pn룰 이라는 것을 적용하자고 하는데요, - P1: 꼭 반영해주세요 (Request changes) - P2: 적극적으로 고려해주세요 (Request changes) - P3: 웬만하면 반영해 주세요 (Comment) - P4: 반영해도 좋고 넘어가도 좋습니다 (Approve) - P5: 그냥 사소한 의견입니다 (Approve) 이렇게 리뷰에 등급을 매겨서 코멘트를 남긴다면, 제 주관이 담긴 리뷰에도 커뮤니케이션 코스트가 줄어들 것 같아요 이렇게 멋진 문화가 있다니! 그리고 이해가 쏙쏙가게 글을 쓰시다니! 여러 충격과 함께 제게 큰 감명을 주었던 글을 첨부하겠습니다.