코드리뷰에 대한 현직자들의 생각 모음

팀에 인원이 증가하면서 개인의 습관에서 비롯된 다양한 코드들이 등장했습니다. 기본적으로는 1. 변수를 선언할 때 규칙이 다르거나 2. 상대적으로 비효율적인 코드들이 보이기 시작했습니다. 혼자 개발하면서도 git flow를 유지하면서 개발 중이었는데, 새로 합류하시는 분들에게도 develop에 merge할 수 있는 권한이 있다보니 저희의 레포는 조금씩 일관성 없는 코드로 채워지기 시작했습니다. 지난 포스트에서 언급한 것 처럼 매주 사용자 피드백도 같이 받고 있던 상황이기 때문에 바쁘다는 핑계로 그냥 두다가, 앞으로 점점 개발팀이 커지면 문제가 될 수 있을 것 같아서 CTO님과 다른 개발자분들에게 코드리뷰를 제안했습니다. 1. 서로 코드를 봐주고 2. 이해가 안되는 부분은 질문하고 3. 고칠 수 있는 점들이 발견되면 제안하자 3가지 이유로 코드리뷰를 제안했습니다. 코드리뷰는 내가 작성한 코드를 다른사람에게 검사받는 시간이 아니라, 최선의 코드를 작성하기 위한 공동의 노력입니다. 코드리뷰를 통해서 다른 개발자들과 소통할 수 있고, 생각하지 못했던 방식들을 배울 수도 있고, 더 좋은 프로젝트를 만들 수 있습니다. 이 부분은 동의하지 않는 분들도 있겠지만, 코드리뷰를 하게되면 누군가에게 보여주는 코드가 되기 때문에, 더 좋은 코드를 작성하기 위해 노력해야 겠다는 심리적 효과가 있습니다. 위에 언급한 3가지 방식으로 코드리뷰를 하니, 비효율 적인 코드는 상당수 개선할 수 있었습니다. 하지만 변수를 선언할 때 규칙이 다르거나, package import순서가 다르다거나, 함수의 위치가 달라서 코드 파악이 어려운 문제는 아직 남아있었습니다. 그래서 컨벤션을 작성하기로 했습니다. 변수명이 뭐가 그렇게 중요하냐고 생각할 수 있지만, 일관성 있는 코드는 가독성에 유리합니다. 또한 내가 작성 한 코드에서 발생한 문제를 다른 개발자가 해결해야 하는 경우도 있는데, 이 경우에 코딩 컨벤션이 지켜진다면 시간을 아낄 수 있습니다. 백엔드는 당시 Django를 사용해서, 파이썬 변수명에 대한 코딩 컨벤션을 만들었습니다. PEP8규칙을 따르려고 노력했고, 노션으로 공유한 문서에 팀원들 피드백을 받아서 저희만의 파이썬 컨벤션을 작성했습니다. 엔드포인트에 다양한 method들을 작성할 수 있으면 Class-Based View를 사용하고, 하나의 method만 작성할 경우에 Function-Based View를 사용하기로 했습니다. 아! 그리고 저희는 파이썬 코드는 align합니다. 프런트엔드는 조금 복잡했습니다. React와 React Native를 사용중인데, 타입스크립트 컨벤션, 리액트 컨벤션, 그리고 eslint 규칙까지 정해야했습니다. 기본적으로는 airbnb에서 추천하는 방식을 따르고, 컴포넌트 내 함수와 hook들의 위치. import 순서, eslint 규칙들을 모든 프런트엔드 개발자들이 모여서 결정했습니다. 예전에 발표자료에서 보니 토스는 토스 린트가 있어서 컨벤션을 지켜주던데, 가능하다면 같은 기능을 하는 자체 모듈을 개발하고자 하는 목표가 있습니다. 기능만 잘 작동하면 되는데 왜 굳이 코드리뷰를 해서 시간을 낭비하느냐고 생각할 수도 있습니다. 리뷰를 하게되면 데드라인이 금요일까지라면 목요일까지는 완성해야 리뷰를 반영해서 해당 feature를 완성할 수 있습니다. 바쁜데 리뷰까지 하라고? 라는 생각을 하실수도 있겠네요. 하지만 코드리뷰는 시간을 낭비하는 것이 아니라 아끼는 방법입니다. 내가 놓쳤던 부분을 다른 개발자가 확인해서 에러를 미연에 방지할 수 있습니다. 코드 효율이 개선되면 사용자들의 시간을 아낄 수 있고, 컨벤션을 통해서 규칙적인 코드를 작성한다면, 내가 작성한 코드를 다른사람도 쉽게 이해할 수 있습니다. 지금은 슬랙 채널에 알림이 오면 가장 빨리 확인하는 2명이 리뷰를 하고, develop으로 merge하는 방식으로 코드리뷰를 하고 있습니다. 슬랙 채널 알림을 확인하지 못하는 경우가 종종 있어서 github workflow을 통해 랜덤으로 리뷰어를 배정하고 배정된 리뷰어에게 슬랙으로 DM을 보내는 방향을 고려중입니다. 위에서 언급한 것처럼 코드리뷰는 최선의 코드를 작성하기 위한 공동의 노력이기 때문에, 고칠 점은 안내하고, 잘 작성한 부분은 칭찬(?)하는 방식으로 리뷰를 진행하고 있습니다. 그리고 이해가 안되는 부분은 질문하고, PR author는 본인의 의도를 설명합니다. 그동안은 "주석 없이도 이해할 수 있는 코드가 좋은 코드다"라고 생각해서 주석은 제거하자는 생각이었는데, 팀이 커지고 프로젝트 규모가 커지면서 "주석도 잘 활용하면 좋겠다"는 생각이 듭니다. 저희가 코드리뷰 하는 방식을 스크린샷으로 조금 첨부했습니다. jasonkang14는 제 계정이고, 다른 분들의 이름과 계정은 가려보았습니다. 글과 예제를 보시고 저희의 코드리뷰 시스템에 조언해주실 수 있다면 댓글로 부탁 드립니다!

지난번에 코드리뷰에 관해 작성한 글에서 언급한 계획을 일부 실현했습니다. 지난 포스트는 아래 링크에서 확인하실 수 있습니다. https://careerly.co.kr/comments/69884?utm_campaign=self-share 1️⃣ 리뷰어 배정 자동화 그동안 저희는 아래 흐름으로 코드리뷰를 진행했습니다. PR 생성 ➡️ PR 링크를 슬랙 채널에 올림 ➡️가장 빨리 확인하는 2명이 리뷰 ➡️ develop으로 merge 하지만 기존의 방법에는 두 가지 문제가 있었습니다. 1. 채널에 알림을 설정하지 않은 개발자들의 경우 리뷰 요청 확인이 어렵고 2. 가장 빨리 확인하는 2명이라는 애매한 기준이 리뷰를 지연시키는 문제입니다. 저희 개발팀은 작은 단위의 PR로 작업하고 있기 때문에, PR이 merge 되지 않으면 다음 작업을 진행할 수 없는 문제가 발생하는 경우가 간혹 있습니다. 그래서 PR을 빠르게 확인하고 코드리뷰를 하는 것이 필요했습니다. 코드리뷰 속도를 향상하기 위해 PR이 생성되면 리뷰어 후보자들에게 알림을 보내기 위해 멘션을 해야 했습니다. 멘션 효율을 향상하기 위해 슬랙에 그룹을 생성하고, PR 링크와 함께 채널에서 멘션 하기로 했습니다. 그룹을 생성하기 전에는 5명을 태그 해야 했지만 이제 그룹 1개만 태그 하면 돼서 시간을 아꼈습니다. 이를 통해 "반응속도" 측면에서는 개선되었지만, PR 작성자가 슬랙에 링크를 복붙해야 한다는 불편함이 여전히 남아있었습니다. 슬랙에서 깃헙 레포를 구독하면(/github subscribe), PR이 생성될 때마다 알림이 옵니다. 그리고 개발자들이 슬랙 계정을 깃헙 계정과 연동하면, 깃헙 PR에서 개발자를 멘션 할 때, 슬랙 앱에서 알림을 받을 수 있습니다. 따라서 PR이 develop 방향으로 open 될 때 리뷰어를 자동으로 배정해 주면, 자동으로 멘션이 되면서 PR 링크를 슬랙으로 복붙하는 과정을 줄일 수 있을 것이라고 생각했습니다. 검색하던 중, 리뷰어 후보자들의 깃헙 계정을 리스트로 넘겨주면, 정해진 인원의 리뷰어를 배정하는 깃헙 액션을 발견했습니다. https://github.com/hkusu/review-assign-action 깃헙 액션을 사용해서 각 레포에 리뷰어 후보자들을 배정했습니다. 저희의 코드리뷰는 아래와 같이 개선됐습니다. 1. develop으로 PR이 생성될 때 리뷰어 후보자 중에 2명이 자동으로 리뷰어로 배정됩니다. 2. 배정된 리뷰어들은 깃헙↔️슬랙 연동을 통해 멘션이 되어서 알림을 받게 됩니다. 3. 리뷰어는 PR을 생성한 개발자에게 별도로 연락하지 않아도 됩니다. comment를 남기거나 change request를 하는 경우 PR에 개발자를 멘션 하면 슬랙으로 알림이 갑니다. 4. PR을 생성한 개발자도 리뷰 내역을 빠르게 파악하고, 수정사항을 반영할 수 있게 됐습니다. 2️⃣ 자동 merge 리뷰어 2명이 approve 해도, 본인이 처음 approve 한 리뷰어라고 생각하는 경우 해당 PR을 merge 시키지 않는 경우가 생겨났습니다. 그래서 approval이 2개인 경우 자동으로 merge를 시키는 기능을 추가하기로 했습니다. https://github.com/DavideViolante/pr-automerge-action 이번에도 깃헙 액션을 사용해서 매일 오전 9시에 develop을 향한 PR 중에 approval이 2개인경우, 자동으로 develop으로 merge 시키도록 했습니다. 지금까지 저희의 코드리뷰 2.0에 관해 작성했습니다. 위 2가지 과정을 통해 코드리뷰의 효율을 높였지만 새로운 문제를 발견했습니다. 저희는 유연근무제를 도입해서 아래 3가지 시간대를 선택해서 근무 중입니다. 1. 08:00 ~ 17:00 2. 09:00 ~ 18:00 3. 10:00 ~ 19:00 17:30에 생성된 PR이 17:00에 퇴근한 개발자에게 배정되면, 다음날 오전까지 코드리뷰를 기다려야 하는 문제가 발생했습니다. 그리고 휴가 중인 개발자가 리뷰어로 배정되는 경우도 있었습니다. 따라서 저희는 사이드 프로젝트를 진행해서 코드리뷰 3.0을 도입할 예정입니다. 1. 슬랙 앱을 개발해서 깃헙과 연동 2. 깃헙 레포에 리뷰어 리스트 추가 3. 슬랙의 근무상태(active / inactive / vacation)을 확인해서 active 한 개발자만 리뷰어 배정 4. 리뷰어로 배정된 PR을 리뷰하지 않은 경우 매일 오전 알림 전송 슬랙 앱을 개발해서 저희 팀에서 사용해 보고, 기능이 괜찮으면 오픈소스로 공개할 예정입니다. 조언이나 궁금한 사항이 있으시면 댓글 부탁드립니다!

동료 주니어 개발자 한 분과 3개월간 프로젝트 기반의 코드 리뷰를 통한 소통을 하고 난 후 후기를 두 편으로 나누어 나눠보려 합니다🤗 1️⃣ 코드리뷰를 받기 전 코드를 작성할 때 가장 큰 고민이 있다면? 고민이 코드 리뷰를 통해 해결이 되었나요? 사실 코드 리뷰를 받기 전에는 누군가에게 제 코드를 보여주고 피드백을 받는 경험이 없었기 때문에 코드 작성에 대한 고민보다 기능 구현에 대한 고민이 더 컸습니다. 객체와 객체 간의 의존관계를 전혀 고민하지 않고 작성했던 이전의 제 코드를 지금 와서 보면, 어떤 부분이 문제라기 보다 코드를 작성할 때 고민 없이 작성했던 것이 느껴지고 코드 한 줄을 작성해도 어떤 고민을 하면서 작성하냐보다 기능 구현에만 목적을 두었기 때문에 타인의 코드를 참고한 흔적들만이 보였습니다. 물론 코드 리뷰에서 어려운 기능을 요구하지 않았지만 스텝을 하나씩 밟아가며 코드 리뷰를 진행하다 보니 문득 “내가 이렇게 코드 한 줄을 작성할 때에도 고민하고 여러 가지를 고려했었나?”라는 생각이 들었습니다. 개발자라면 내가 작성한 코드에 목적과 의도가 명확해야 하지 않나라는 부분에 고민이 있었는데 코드 리뷰 후반부터 스스로 성장했음을 느끼면서 자신감도 생겼습니다.👍 그리고 질문에 대한 적극성도 큰 고민이었는데, 특히 저는 무엇을 어떻게 질문해야 할지조차 감이 오지 않았고 제가 하는 질문의 수준이 너무 낮은 건 아닐까 등의 걱정에 의해 코드 리뷰 초반에는 적극적인 질문을 하지 못했습니다. 질문에 적극적이지 못한 것은 개인마다 차이가 있을 수 있지만, 무엇을 어디서부터 어떻게 질문해야 할지조차 모르는 것은 신입부터 주니어 개발자라면 한 번쯤은 겪을만한 고민인 것 같습니다. 실제로 저는 코드 리뷰 중에 혼자 고군분투한 적이 있었는데, “여러분은 이런 경험을 하지 않도록 적극적으로 질문하세요😀” 같은 고리타분한 말보다는 고군분투해 보는 것도 나쁘지 않다고 말하고 싶습니다. 그러한 과정을 통해서 적극적인 질문의 중요성을 스스로 깨달았고 그 과정 자체가 뜻깊었기 때문에, 우여곡절이든 실수든 그를 통해서 무언가를 얻었다면 그게 진정한 자산이라고 생각합니다.😊 2️⃣ 리뷰어와의 소통 중 어떻게 질문을 했나요? 질문의 중요성에 대해서 어떻게 생각하시나요? 리뷰 초반의 저는 질문에 대해서는 조금 소극적인 편이었어서 PR에 고민이나 질문을 작성할 때 많이 어려웠습니다. 그래서 이슈와 PR을 나누는 단위부터 고민되는 네이밍까지 정말 사소하고 작은 것부터 질문을 하기 시작했는데, 질문에 대한 태도가 좀 더 적극적으로 변화해가면서부터는 실제로 제가 하고 있는 고민에 대해 피드백을 받는 등 좀 더 구체적인 질문도 하게 되었습니다. 특히 질문을 했을 때 리뷰어에게 지금 내가 하고 있는 고민이 무엇인지, 뭘 모르겠는지, 알고 싶은 게 뭔지에 대해서 좀 더 명확하게 전달하기 위해 리뷰어의 입장에서 생각해 보려고 노력했습니다. 사실 코드 리뷰도, 질문도, 결국 사람 간의 커뮤니케이션이기 때문에 스스로 충분히 서치해서 알아볼 수 있는 부분은 직접 서치해서 최대한 스스로 답변했고 추가적으로 궁금한 부분에 대해 질문하는 방식으로 진행했습니다.🤓 물론 코드 리뷰에서 가장 중요한 부분이 피드백이긴 하지만, 코드를 통한 피드백 말고 실제로 하고 있는 고민을 나누면서 피드백을 받아 가는 것 또한 코드 리뷰를 더 알차게 진행하는 방법 중 하나라고 생각합니다. 그리고 어떤 리뷰어에게, 어떻게 피드백을 받냐도 중요하지만, 코드 리뷰를 활용해서 경험과 지식을 쌓을 것은 능동적인 움직임에 따라 좌우되기 때문에 피드백과 질문 이 두 가지를 코드 리뷰에서 잘 활용해야 한다고 생각합니다!

동료 주니어 개발자 한 분과 3개월간 프로젝트 기반의 코드 리뷰를 통한 소통을 하고 난 후 후기를 두 편으로 나누어 나눠보려 합니다🤗 3️⃣ 코드리뷰 과정에서 중요하게 생각하는 부분이 있다면 뭘까요? (리뷰어와의 소통이라던지 PR작성이라던지) 코드 리뷰 과정에서 중요한 부분이 많지만 그중 꼽자면 리뷰어와의 소통이 가장 중요하다고 생각합니다! 코드 리뷰 과정을 거치다 보니 결국 저의 성장은 리뷰와의 소통이 조금씩 활발해진 시점부터 시작되었던 것 같습니다. 특히 코드를 작성하기 전부터 코드 작성을 하는 과정, 코드 작성 후 리뷰에 대해 수정하는 과정, 이 모든 과정이 결국 코드 작성 외에는 리뷰어와의 소통으로 이뤄져 있기 때문에 이 과정 속에서 리뷰어와 소통하는 방식을 많이 배우게 되었습니다. 소통이 결국 질답과 피드백 그 자체이기 때문에, 코드 리뷰 과정 중 저는 어떻게 질문을 해야 명확할지, 스스로 충분히 고민해 보고 하는 질문인지, 피드백에 대해 어떤 자세로 임하는지, 피드백을 얼마나 잘 받아들이고 수용했는지 등등 다양한 부분에 대해서 스스로 질문하고 답변하면서 “셀프 피드백”을 했습니다. 셀프 피드백을 통해서 내가 어떤 생각으로 코드 리뷰를 받고 있는지와 어떤 부분을 고쳐나가야 할지에 대해 충분히 생각하게 되었고, 이러한 과정 또한 적극적인 질문에 대한 필요성을 깨닫게 하는 데에 영향을 주었습니다. 그리고 피드백을 받았을 때에 무조건적인 수용만 하는 것이 아니라, 내가 충분히 고민하고 작성했던 코드라면 어떤 고민을 하면서 작성을 했는지 리뷰어에게 공유하는 과정도 중요하다고 생각합니다. 내가 했던 고민이 잘못된 방향이었을지라도 이를 공유하면서 리뷰어에게 피드백을 받으면 하나의 코멘트에서도 여러 가지 피드백으로 파생될 수가 있기 때문에, 하나의 코멘트도 어떻게 활용하는지에 따라 코드 리뷰의 활용도를 높일 수 있습니다. 코드 리뷰를 얼마나 적극 활용할 수 있는지는 하기 나름이기 때문에 코드 리뷰를 “받는다”라는 느낌보다 “활용한다”라는 마음가짐으로 임하는 게 좋다고 생각합니다.🙂 4️⃣ 코드리뷰를 받기 힘든 상황이라면 어떤 부분을 공부하면 도움이 될까요? 저는 첫 입사 전까지 제대로 된 코드 리뷰를 받아보지 못했기 때문에 제가 해왔던 방법을 공유해 드리기보다는, 수단과 방법을 가리지 않으면 코드 리뷰를 받기 힘든 상황은 극복할 수 있다는 것을 알려드리고 싶습니다. 물론 정해져 있는 커리큘럼에 따라 진행하면서 리뷰어에게 주기적으로 리뷰를 받는 정도는 아니겠지만, 개발자 온라인 커뮤니티도 충분히 활성화되어 있고 공부를 하다 보면 우리가 자주 볼 수 있는 개발자분들이 속한 커뮤니티를 활용하는 방법도 있다고 생각했습니다.🤔 사실 저 또한 이런 방법들을 적극적으로 찾아보지 않았던 사람이었는데, 한 개발자분의 경험담으로 지난날의 저를 돌아보게 되었습니다. 그분은 당시 간절하게 멘토가 필요했기 때문에 업계에서 유명한 개발자분에게 직접 연락하며 멘토의 역할을 부탁드렸다고 들었습니다. 그리고 가장 울림이 있었던 말로, 정말 간절하면 내가 움직이고 찾아 나설 수밖에 없다고 하셨는데 너무 현실적이고 맞는 말이라서 지난날에 대해 반성하게 되었습니다. 만약 다시 돌아간다면 간절한 만큼 “수단과 방법을 가리지 않는 노력”을 했을 것이라고 생각합니다.

우선 먼저 말씀드리고 싶은건 타인의 코드 읽는다는게 쉽지는 않다는 것입니다. 더구나 코드를 한꺼번에 이슈를 쪼개지 않고 올리게 되면 무엇을 위한 수정인지 더욱 의도를 파악하기 힘들어집니다. 그리고. 일이 바쁘다고, 리뷰하지 않고 미루다보면 어느새 PR(Pull Request)들이 쌓이게 됩니다 😂 저도 그런적이 많아서 반성을 합니다. 대충 짐작하시겠지만, 리뷰가 잘되지 않으면, 수정, 추가된 소스에서 불필요한, 비효율적인 요소들과 버그들이 그대로 머지가 되기도, 리뷰 지연으로 실제 반영까지 딜레이가 발생하기도합니다. 우아한 형제들에서 이를 방지하기 위해서 많은 고민을 한것 같습니다.

구글과 마이크로소프트에서는 코드 리뷰를 매우 중요하게 여기며, 이를 위해 다양한 방법을 사용하고 있습니다. 구글은 코드 리뷰 개발자 가이드(https://google.github.io/eng-practices/review/)를 통해 코딩 스타일을 비롯한 주요 원칙을 공개하고 있으며, Microsoft는 Codeflow를 통해 코드 리뷰를 진행하고 있습니다. 이외에도, 구글은 Tricorder라는 정적 분석 도구와 Rosie라는 코드 정리 시스템을 활용해 사용하지 않는 코드는 없애고, 리팩토링이 필요한 경우에는 수정된 코드를 개발자들에게 리뷰 요청하는 것으로 알려져 있습니다. Microsoft에서는 팀별로 자유롭게 자동화된 검토 도구를 활용할 수 있고, 프로세스도 자율적으로 구성할 수 있다는 점이 다르며, 최근에는 Microsoft에서 GitHub를 인수했기 때문에, Git에 대한 활용이 광범위하게 확대되고 있다고 합니다. 이외에도, Microsoft에서는 개발자들 간에 코드 리뷰의 코멘트를 명확히 이해하고 전달할 수 있도록 이모지를 활용하기도 합니다. 이모지를 통해서 텍스트만으로 전달하면서 발생할 수 있는 감정적인 싸움이 예방될 수 있다는 것입니다. 예시) 👍: 대단하다! 누구한테 보여줘야 하는거 아니야? ❓: 질문이 있어 🙃: 이건 트집 잡기야. 이런 걸로 진행을 막으면 안되지. 💭: 꼭 바꿔야 하는 건 아니지만, 내 생각을 꼭 나누고 싶어 ‘테스트 없는 코드는 없고, 리뷰는 당연하다’는 인식이 일반화되어가는 지금, 우리 회사의 코드 리뷰 방식에서 장점은 취하고, 특성은 살리는 우리만의 방식을 찾아가는 과정이 되어야 할 것 같습니다.

안녕하세요! 오랜만에 인사드립니다. 2월엔 이런저런 신경쓸게 너무 많아서 글 업로드를 못했는데요.. (뭔 얼마나 바빴길래 글도 못썼냐라고 생각하시면 맞습니다.. 핑계 같네요..ㅎㅎ) 오랜만에 쓰는 글은 코드리뷰에 관한 글을 가져왔습니다. 아래는 카카오 테크에서 작년 이맘때쯤 기고된 코드리뷰에 관한 글인데요. 글 자체는 아래를 읽어보시고 아래 글은 좀 이제 시니어가 교육생한테 어떻게 리뷰하면 좋은지에 대해 초점이 맞춰져 있어 저는 이 글을 같이 일하는 동료, 팀원분들과 하는 코드리뷰에 관한 관점에서 글을 다시 바라보려고 합니다. 글에서는 5가지 규칙에 대해 이야기하고 있는데요! 이에 대해 제 해석을 다시 살펴보시죠. 1. 왜 개선이 필요한지 이유를 충분한 설명해 주세요. 이 규칙에 대해선 다른 관점이 필요도 없이 온전히 공감합니다. 섹션에 마지막에 있는 개선의 필요성에 대한 설명했다기 보단 팀원들 간의 코드리뷰에선 본인이 코드리뷰를 달면서 어떤 생각으로 이런 리뷰를 달았는지 의도를 명확히 전달하는게 좋다고 생각합니다. 2. 답을 알려주기보다는 스스로 고민하고 개선 방법을 선택할 수 있게 해주세요. 이 규칙은 말을 '코드에 정답은 없으므로 다양한 관점을 가지고 본인의 생각에 대해 이야기하고 제안하자.' 정도로 바꾸고 싶네요! 코드에 정답은 없지만 여러 모범 답안이 있을 수 있습니다. 언제나 더 나은 방법이 있을 수 있으니 작업자와 이런 저런 의견을 주고 받는 것은 아주 건설적인 논의라고 생각하고 그를 통해 서로 발전도 할 수 있다고 생각합니다. 해당 의견을 채택할지 말지는 작업자의 몫이고 채택되지 않더라도 좋은 논의가 있었다면 그 자체로도 만족스럽습니다. 3. 코드를 클린 하게 유지하고, 일관되게 구현하도록 안내해 주세요. 이 규칙도 안내라는 말만 좀 바꾼다면 그대로 가져가고 싶네요. 코드리뷰에 여러 관점이 있지만 팀의 컨벤션과 코드 내의 일관성은 중요합니다. 혹시나 클린하게 유지라는 말이 무슨 말일까 고민된다면 클린 코드라는 책을 읽어보신다면 클린하게 라는 의미에 대해 조금 더 이해하실 수 있지 않을까 싶네요. 4. 리뷰 과정이 숙제검사가 아닌 학습과정으로 느낄 수 있게 리뷰해 주세요. 이 말은 해당 섹션은 첫번째 문장인 '코드 리뷰를 하는 목적은 서로 생각을 공유하고 좀 더 깔끔한 코드를 작성하기 위함입니다.' 로 대체하고 싶습니다. 글에서는 리뷰를 받는 사람이 숙제 같이 느껴지지 않게 해라고 말했지만 필드에서 저는 서로 숙제같이 느껴지지 않는 것이 중요하다고 생각합니다. 무슨 말이냐하면 현업에 종사하시는 여러분! 코드 리뷰를 받는거 보단 하는 것이 숙제처럼 느껴지고 리뷰해야하는데.. 하면서 좀 미루신 경험 없으신가요!? (저만 그런가요 크흠흠.. 그럼 반성을..) 리뷰어든 리뷰이든 더 나은 프로덕트를 위해 코드리뷰는 반드시 필요합니다. 출근하면 앞에 30분은 코드 리뷰 같은 룰이라던지 데브옵스의 도움을 받는다던지 등 그라운드 룰이 있어도 좋을거 같다는 생각이 드네요! 5. 리뷰를 위한 리뷰를 하지 마세요. 피드백 할 게 없으면 칭찬해 주세요. 이 규칙도 아주 공감합니다. 코드에 고칠거나 제안할 내용이 없더라도 고생한 동료분들을 위해 수고하셨다라는 내용이라던지 최소한 LGTM이라도 남겨주시면 어떨까요?