개발문화탐구: 코드리뷰
코드리뷰
개발문화 중 하나인 코드리뷰에 관해서 이야기를 해보려 합니다.
코드리뷰라 함은 간단히 말해, 내가 작성한 코드를 제3자가 검사하는 것입니다.
타인에 의해 예상치 못한 오류를 찾아내거나 코드를 더 좋게 개선할 수 있습니다.
자신의 발전과 팀의 발전 그리고 제품의 안정성을 위하여 꼭 도입되어야 하는 문화입니다.
허나 이런 중요성에도 불구하고 코드리뷰를 왜 하는지 가슴으로 느끼기는 참 힘듭니다.
이 포스트를 본다고 해서 직접 경험 해보지않는 이상 코드리뷰의 중요성을 100% 이해하기는 어렵겠습니다만 느낌이라도 살짝..
코드리뷰를 대하는 자세
직장 내의 서로 다른 개발자가 right way를 향해 발전하는 가장 좋은 문화가 바로 코드리뷰라고 생각합니다.
하지만 기본적으로 서로를 인정하고 리스펙하는 분위기가 형성되어 있어야지, 그렇지 않을 경우 단지 서비스 오류를 방지하기 위해(혹은 코드 Merge를 위해) 행하는 매우 귀찮은 검사단계 정도로 치부될 수 있습니다.
최악의 경우 이런걸 왜 하냐고 직장 동료들끼리 상사 뒷담화 할지도…? (아주 오래된 경험상...)
<내가 수정한 코드가 실서버에 배포되기에 충분할까?>
코드리뷰의 첫인상
코드리뷰를 처음 도입 혹은 처음 경험했을 때, 이게 생각만큼 마냥 유쾌하지만은 않습니다.
마치 숙제를 검사받는 기분이 들기도 하고, 익숙하지 않으면 살짝 부담스럽기도 합니다.
저도 처음에는 내 코드를 타인이 본다는 게 참 쑥스러웠으나 적응되고 나니 지적받고 싶어지기도…?
아무튼 리뷰어가 좀 더 쉽게 코드리뷰 할 수 있게 Commit 메시지를 더욱 디테일하게 작성하는 근본적인 이유가 생기며, 코드 자체도 경각심이 생겨서 좀 더 신경 써서 작성하게 됩니다.
고전적인 방식의 코드리뷰
이전 회사에서의 코드리뷰 방식은 고전적인 방식의 코드리뷰였습니다.
서비스의 릴리즈가 한 달 혹은 그 이상의 시간이 걸리기 때문에 그간의 변경 사항에 대한 프로세스 리뷰 및 특별히 적용한 알고리즘에 대해서 얘기를 했습니다.
변경사항이 많아서 각자 미리 해당 코드를 보고 와서 회의실에서 이야기하곤 했습니다. (물론 진짜 읽고 온지는 아직도 의문)
하지만
실제 업무를 하지 않던 윗단에서는 한 귀로 흘려들었으며, 개발자 간에도 서로 각자 담당 서비스가 있었기 때문에, 지금까지 손댄 적도 없고 앞으로도 손댈 일 없는 코드에 관심이 있을 리가 없었습니다.
결국 한 두번 해본 후, 코드리뷰는 소리소문없이 사라졌습니다.
이와 같은 방식의 코드리뷰를 Walkthrough 방식이라고 한다고 합니다.
하지만 제가 이번 포스트에서 말하고 싶었던 코드리뷰는 Github의 Pull Request를 이용한 방식입니다.
Github PR Code Review
예전과 다르게 지금은 대부분의 회사가 Agile 방식이나 좀 더 작은 단위의 개발 및 릴리즈를 선호하고 있습니다. (아마도...)
그런 흐름에 맞춰 대부분 A successful Git branching model에 기반한 git flow나 github flow와 같은 흐름으로 개발을 하고 있습니다.
이전에는 큰 목표를 설정하고 오랜 시간에 걸쳐 작업하기 때문에 매우 많은 코드의 변화가 생김으로써 코드리뷰가 너무 힘들었던 반면, 요즘은 위 flow와 같이 동시에 작은 단위 및 기능별로 개발을 하게 됩니다.
추가/변경되는 코드의 수가 이전보다 훨씬 적기 때문에 코드리뷰를 기능별로 더욱 명확하게 할 수 있습니다.
자세한 방식은 github flow 내용을 참고하시면 좋을 것 같습니다.
왜 코드리뷰를 하는 건가요?
간단하게 정리하면 아래와 같습니다.
- 코드의 정확성 및 품질향상
- 당면한 문제에 대해 다양한 관점에서 개선 및 해결책 제시
- 새로운 아이디어에 대한 의견공유
- 사내 Code Convention 정착
- 코드 작성자가 놓친 오류 방지. 더해서 깜박하고 안 지운 console.log도 :)
위와 같은 명백한 장점이 있으며, 이외에도 타인의 코드를 검토하면서 실력 상승이 된다거나 반복된 검토로 인해 코드 리딩 및 이해 속도가 향상되기도 합니다.
도입 시 주의사항
만약 코드리뷰를 도입한다면, 먼저 코드리뷰에 방해되는 고전적인 개발 문화들이 있는지 보고 좀 더 심사숙고 후 적용을 하셨으면 좋겠습니다.
물론 코드리뷰를 위해서 그렇게까지 해야 하나 싶을 수도 있지만 제 경험에 비춰볼 때 어설프게 적용하면 안 하느니만 못 한 느낌!
최악의 예를 들자면… 각 개발자가 서로 다른 서비스를 담당하고 있어 서로의 코드를 볼 일이 없는 와중에 갑자기 코드리뷰를 도입한다면, 원하는 결과를 끌어 낼 수 있을까요?
물론 간단한 조언이나 성능 개선을 위한 의견을 낼 수는 있겠지만, 코드리뷰 할 때 딴생각하고 넋 놓지만 않아도 다행일 것 같네요.
그리고 효과를 보기 위해서는 두 달 정도는 꾸준히 진행해야 그 효과를 체감할 수 있으며, 이를 위해서 팀 리더의 역할이 매우 중요하다고 생각합니다.
마치며
적은 스코프로 코드리뷰 요청을 해야하지만, 이 부분이 아직 저도 익숙하지 않아 어떨 때는 1000라인이 넘는 PR을 만들 때도 있는데 글을 작성하면서 이 부분은 고쳐야겠다고 반성 중입니다 ㅎㅎ!
몇 주 전 캠핑장 갔을 때 wifi도 안되는 곳이라 블로그 글이나 쓸까 하고 간단하게 작성한 글이었는데, 몇일 텀으로 읽을 때 마다 뭐가 부족한가 싶어서 계속 수정하다 보니 시간이 너무 오래 걸렸네요.
정말 오랜만에 올리는 포스트인 듯! 다시 기운 바짝 내서 올려야겠습니다.
뭐 쓸지 주제만 정해놓고 Backlog에 올려놓은 게 너무 많아서 약간 압박이…이글을 작성하는 중에 타이밍 좋게 현 회사 CTO 형님이 팀원들 공유 목적으로 관련 문서를 만들었는데 많은 도움이 됐습니다.