좋은 코드 리뷰는 어떻게 할까요? 코드 리뷰에 관한 블로그 글이 있어 내용 정리해서 간단한 생각과 함께 올려봅니다. 1️⃣ 오프라인으로 논의해도 될 건 오프라인으로 하기 상대방의 코드에 많은 피드백을 남겨야 한다면, 단순히 수십 개가 넘는 피드백을 코멘트에 남기지 말고 검토한 부분을 대화를 통해 작성자와 함께 확인하는 게 훨씬 효과있다고 합니다. 개인적으로 공감하고 좋은 방법이라고 생각하긴 하지만, 길게 보면 좋은 방법은 아닌듯 합니다. 예를들어, 한 명의 엔지니어가 5명이 넘는 코드 작성자를 한 명씩 만나서 한 시간씩 코드 검토한 점을 의논할 수 없습니다. 일대일 면담 외 가능한 방법: 1. 자주하는 코드 작성 관련 피드백은 템플렛화해서 동료에게 가르치기 2. 다른 사람에게 위임하기 (그 사람에게는 롤모델로 성장할 기회가 주어진다) 3. 웬만한 코드는 자동으로 검토해주는 개발 도구 이용하기 2️⃣ 리뷰하지 말아야 할 코드는 참견하지 말기 내가 잘모르는 코드베이스관련 코드 변경을 검토해달라고 요청했다면 거절할 줄도 알아야 합니다. 양날의 검과 같은 조언인데, 무조건 모른다고 거절하면 떠넘기기만 하게 됩니다. 모른다고 무조건 거절하는 게 아니라, 좀 더 디테일하게 설명하자면 중요한 코드를 검토해야 할 때, 최대한 검토해 줄 수 있는 부분은 해주되, 솔직하게 모르는 부분은 모른다고 하고 기대치를 설정하는 게 좋을 것 같습니다. 그래야 상대방이 기대치를 잘 이해하고 적합한 검토자를 다시 찾거나 또는 다른 조치를 취할 수 있을 것 같습니다. 3️⃣ 비판할 점은 그냥 비판만 하지 말고 정당한 이유도 같이 공유하기 예를 들어 "여기에는 이렇게 코드 작성하세요"라고만 말하지 말고 정당한 이유도 같이 공유하는 게 좋다고 합니다. 크게 공감하는 부분이에요. 단순하게 바꾸라고 말하면 상대방은 '왜' 그래야 하는지 모르고, 같은 실수를 반복할 수 있습니다. 반면에 이유를 확실하게 알면 같은 실수를 반복할 확률이 줄어들어요. 스택오버플로우나 정식 도큐먼트 또는 블로그 글 링크를 첨부하거나, 시간 있다면 자세하게 설명해 주세요. 그렇다고 모든 코멘트를 정당화하지 않아도 됩니다. 때에 따라서 코드 가독성을 높이거나, 오타 체크 또는 사소한 점은 간단하게 알려주기만 해도 괜찮아요. 4️⃣ 꼼꼼하게 살펴보기 원문에서 '코드 검토'할 때 어떤 점을 꼼꼼하게 봐야 하는지 자세하게 적은 PDF를 공유했습니다. 관심 있으신 분들은 확인 해보세요. 5️⃣ 다른 사람 코드 리뷰 살펴보기 시간 있다면 내 것만 보지 말고 다른 엔지니어가 어떻게 코드 리뷰하는지 살펴보세요. 마지막은 원문에 언급되지 않았지만, 개인적으로 유용했던 점입니다. 코드 검토할 줄 모르던 주니어 시절이나 코드 검토 퀄리티를 높이고 싶을 때 팀 또는 조직 내에 코드를 잘 검토하는 선임의 리뷰를 살펴보았습니다. 내가 검토해야 할 코드가 아니어도 다른 사람들이 검토하는 것을 보며 많은 것을 배울 수 있었습니다. 🪴 함께 읽으면 좋은 글: 코딩 외에 개발자에게 절대적으로 필요한 스킬 https://careerly.co.kr/comments/78115 신입, 경력직 회사 생활과 자기 계발에 필요한 것 https://careerly.co.kr/comments/77994 2월 멘토링 취업, 이력서 작성 관련 큐앤에이 모음 https://careerly.co.kr/comments/78748