코드 리뷰를 받는 입장에서 해야 하는 입장이 되었는데 다른 분들은 리뷰를 어떤 식으로 하는지 궁금합니다.

요약 1. 저는 로직을 이해하기 쉽도록 구현했는지를 위주로 코드리뷰하고, 코드 스타일은 린터/포매터를 십분 활용합니다. 2. 코드 작성자는 확신이 없는 부분에 대해서 사전에 설명하는 코멘트를 남겨두면 좋습니다. 3. 코드 리뷰어는 자신의 코멘트가 필수적으로 반영되어야 하는지, 선택적으로 반영하면 좋은 것인지 명시하면 좋습니다. 4. 구글 등 다른 코드리뷰 문화도 참고하시면 좋습니다. 경험상 사람마다 코드리뷰에서 주로 보는 부분이 다르겠지만, 저는 로직을 주로 봅니다. 구현하고자 하는 것에 비해서 복잡하게 되어있지는 않은지, 맥락을 알아야지만 이해할 수 있도록 구현되어 있지는 않은지 점검하는 편이에요. 그래서 사실 코드를 읽다가 이해하기 어렵다 싶으면 그때부터 로직에 개선점이 있는지 주의 깊게 봅니다. 코드 스타일 등 린터나 포매터로 자동화할 수 있는 부분은 크게 신경 쓰지 않는 편이에요(대부분 CI에서 잡히고, 새로운 린터 규칙이 필요하면 추가하면 됩니다). 한편, 코드리뷰를 하다 보면, 리뷰가 올라오기까지의 시간과, 리뷰를 반영했을 때 그걸 확인하고 승인하는데 까지 걸리는 시간이 오래 걸리기 마련입니다. 일종의 핑퐁이지요. 이 핑퐁을 줄이기 위한 방법으로 저는 선제적 코멘트를 사용했습니다. 로직을 최대한 이해하기 쉽게 짜려고 노력했지만, 더 이상 개선할 수 없었을 때, 그렇다고 주석을 남기기도 애매할 때는 github, bitbucket의 코드 인라인 코멘트로 왜 이렇게 짰는지, 무엇을 고민하고 있는지에 대해 적어둡니다. 그러면 리뷰어가 왜 이렇게 짜셨나요? 라고 묻고, 그에 대해 답하면서 생기는 핑퐁이 줄어듭니다. 마지막으로, 코드 작성자의 입장에서는 리뷰어의 코멘트가 필수적으로 반영되어야 하는지, 아니면 반영되면 좋은 것인지 구분이 애매할 수 있습니다. 그래서 리뷰어가 필수/선택 여부를 명확하게 표시해주는 게 좋다고 생각합니다. https://google.github.io/eng-practices/review/ 구글의 코드리뷰 가이드 문서와 거 문서에 링크된 다른 글을 읽어보셔도 도움이 될 거 같습니다.

리뷰는 원래 서로 하는거 아닌가여 받았을때 어떤 코멘트들이 달렸는지 생각해보면되겠져 거기에 자신이 추구하는 스타일을 새로간 회사 가이드라인에 적절히 적용해서

어떠한 일정한 패턴이 있고 그 가이드대로 준수를 하면 코드가 나아지게 되는거는 개선이 가능하지만 다른 방식으로 생각해서 코드의 분량을 줄이는 거는 리뷰를 해도 습득이 되지는 않더군요. 노하우의 전수가 가능한지 여부도 리뷰 할때 고려 사항인듯 합니다.

축하드립니다! 테크리드로서의 새로운 역할에는 많은 책임감이 따르는데요, 그 중 하나가 바로 코드 리뷰입니다. 좋은 코드 리뷰를 위한 몇 가지 방법을 제안드립니다: 1. 공감하는 마음 가짐: 코드 리뷰를 할 때, 작성자의 입장에서 생각해보세요. 당신의 피드백이 어떻게 받아들여질지 고려하면서, 충분히 공감하고 지원하는 방식으로 접근하세요. 2. 명확한 커뮤니케이션: 코드에 문제가 있다면, 문제가 무엇인지 명확하게 지적하세요. 그러나 그 문제를 어떻게 수정하면 좋을지 구체적인 해결책을 제안하는 것도 중요합니다. 3. 존중과 예의: 모든 의견은 존중받아야 하며, 감정을 상하게 할 수 있는 언어 사용은 피해야 합니다. 코드 리뷰는 작성자의 개인적인 능력을 비판하는 것이 아니라, 코드의 품질을 향상시키는 것을 목표로 해야 합니다. 4. 지속적인 학습: 리뷰 과정은 팀 전체가 함께 성장하는 데 도움이 되어야 합니다. 코드 리뷰가 단순한 문제 해결만이 아니라, 더 나은 코드 작성 방법을 배우는 기회로 활용되어야 합니다. 5. 시간을 효과적으로 활용: 모든 코드를 리뷰하는 것은 시간이 많이 소요될 수 있습니다. 중요도에 따라 리뷰해야 할 부분을 선정하고, 시간을 효과적으로 활용하세요. 팀이나 개인의 성장에 기여하는 코드 리뷰는 효과적인 팀워크와 함께 전체 팀의 생산성을 높이는 역할을 합니다. 이에 따라 적절한 코드 리뷰 문화를 형성하는 것은 매우 중요합니다.