안녕하세요 
백엔드 개발 파트에서 공비서를 담당하고 있는 소니입니다.
오늘은 헤렌 개발팀의 개발 문화 중의 하나인 코드 리뷰에 대해서 간단히 소개하려고 합니다. 코드 리뷰를 도입하게 된 계기와 현재 어떻게 하고 있는지 또 코드 리뷰를 통해 어떤 걸 얻었는지를 정리해보겠습니다.
코드 리뷰를 시작하게 된 계기
저희 팀은 작년 초에 신규 서비스 개발을 하면서 코드 리뷰를 진행했었는데 바쁜 일정과 리뷰에 대한 규칙을 정하지 않아 제대로 하지 못하였습니다.
리뷰를 진행하지 않고 각자 개발하다보니 코드 컨벤션 변경 사항 전파 중복 코드 예상치 못한 사이드이펙트 등의 문제들이 있었습니다. 이후 개발을 완료하고 과거의 문제들을 반복하지 않기 위해 코드 리뷰를 다시 해보기로 하였고 팀원분께서 정리해주신 개발 프로세스를 바탕으로 본격적으로 코드 리뷰를 시작하게 되었습니다.
개발 프로세스
정리된 개발 프로세스에 대해서 간단히 설명하자면 이렇습니다.
1. develop 브랜치 기준으로 feature 브랜치 분기
2. 개발 완료 후 테스트를 위해 feature 브랜치 기준으로 dev 서버에 배포
3. 코드 리뷰
4. develop 브랜치에 feature 병합
Plain Text
복사
이때 코드 리뷰를 받기 위해서 리뷰를 받는 사람 (리뷰이)는 PR을 작성하고 리뷰를 요청할 사람 (리뷰어)를 선정해야 합니다.
리뷰이 : PR 작성
리뷰이는 PR을 작은 단위로 쪼개 리뷰어가 리뷰하는 코드의 양을 줄여 빠르고 정확한 리뷰를 할 수 있도록 합니다. 리뷰 내용은 PR Template에 작성하고 리뷰어가 코드의 문맥을 빠르게 파악할 수 있도록 이러한 내용들이 들어가도록 합니다.
1. 어떤 코드를 변경했는지
2. 어떤 이슈가 발생했는지
3. 어떤 부분을 집중적으로 보면 좋을지
4. 관련 스크린샷
5. 지라 티켓 링크 혹은 참고 자료
Plain Text
복사
PR은 개발 브랜치 대상으로 작성하고 리뷰어가 승인을 해야 병합할 수 있도록 Branch protection rules을 적용하였습니다.
Branch protection rules
Review required
PR Template
## 개요
## 작업사항
## 변경로직
### 변경전
### 변경후
## 사용방법
## 기타
## 참고
* [지라티켓 키-번호](링크)
* 기타 참고자료 링크/첨부
Markdown
복사
PULL_REQUEST_TEMPLATE.md
리뷰어 : 코드 리뷰에 임하는 자세
리뷰어는 객관적으로 피드백하고 가능한 한 완곡하고 부드럽게 표현합니다. 또한 수정에 대한 최종 결정은 리뷰이의 몫이므로 리뷰어는 의견만 제시하도록 하고 이러한 내용들을 토대로 검토하고 제시합니다.
1. 일관된 아키텍처를 유지하고 있는지
2. 다른 해결 방법에 대한 의견 제시
3. 버그가 발생할 가능성 제시
4. 기술적인 지식, 노하우 공유
5. 히스토리 전달
Plain Text
복사
코드 리뷰를 통해 얻은 것들
가끔 코드 리뷰로 인해 병목이 생기는 경우가 있었지만, 현재 코드 퀄리티가 훨씬 좋아졌고 내가 작업한 게 아니더라도 리뷰를 통해 공유받으니 도메인에 대한 이해도 깊어지고 팀원들과 같이 성장하는 느낌이 있어 좋은 경험이었습니다
1. 버그 발견
2. 도메인 지식 전파
3. 일관된 아키텍처, 코드 컨벤션
4. 다른 사람의 코드를 보고 학습
5. 자신의 코드를 되돌아보는 계기
Plain Text
복사
코드 리뷰를 하면서 이러한 점들이 얻을 수 있었다
실제로는 어떻게 하고 있을까?
GitHub과 슬랙을 연동하여 PR에 리뷰가 추가되면 아래와 같이 알림이 오도록 하였습니다.
기능 개선에 대한 리뷰
버그 리뷰, 어떤식으로 해결하면 좋을지 리뷰를 통해 논의
동료들의 소감
안녕하세요 헤렌 공비서 백엔드파트 소속 워니입니다. 입사후 얼마 되지 않아 코드 리뷰를 받았던 시간이 떠오르는데요. 경험이 적은 상태에서 참여한 코드 리뷰는 처음에는 어려운 과제같이 느껴졌었습니다. 그리고 제 어설픈 코드가 평가를 받는다는 것도 낯설었는데요. 지금은 많이 익숙해졌고 어떤 코멘트가 달릴까 궁금해집니다. 코드 리뷰에 참여하면서 들었던 생각들, 느꼈던 부분을 공유하고자 짧게나마 몇 자 적어봅니다.
파트원분들과 약속한 커밋 메시지, Pull Request 작성 등 템플릿 또는 약속된 포맷을 따라 작성하면서 리뷰해 주시는 분 입장에서 조금 더 이해하기 쉽도록 작성하는 데에 도움이 되었던 것 같습니다. 게다가 포맷을 두고 작성하다 보니 제가 작업한 내용들을 한 번 더 정리하는 차원에서 확인할 수 있어서 좋았습니다. 시간이 흐른 후에 작업 내용을 복기해야 하는 때에도 시간 절약에 도움이 되었다고 생각합니다.
실제 리뷰를 받다 보면 버그가 예상되는 부분이나 개선이 필요해 보이는 부분들이 많았습니다. 다른 분의 객관적인 시각이 필요하기 때문에 피드백 받고 수정하는 과정을 거치고 있습니다. 개인 업무 시간을 할애해서 리뷰해주시면서도 꼼꼼히 봐주셔서 감사하게도 운영으로 가기 전에 리스크를 줄일 수 있었고 이런 장치들이 있어서 자연스럽게 코드 리뷰의 장점과 중요성을 체감할 수 있었습니다. 더 나은, 개선된 개발을 위해 아이디어를 나누기도 하지만 서비스의 완성도, 안정성을 위해서 코드 리뷰는 꼭 필요하다는 생각이 들었습니다.
현재도 저희 백엔드 파트에서는 활발하게 리뷰가 이뤄지고 있고 실제로 서비스 개발과 개인 역량 강화에도 많은 도움이 되고 있습니다. 앞으로 저도 더 발전된 리뷰로 기여할 수 있기를 바라며 이만 줄이겠습니다. :-)
안녕하세요 백엔드 개발 파트에서 공비서를 담당하고 있는 주니어 개발자 혀니입니다.
백엔드 개발 파트에서 공비서를 담당하고 있는 주니어 개발자 혀니입니다.회사에 입사하기 전에는 코드 리뷰를 경험하지 못했기 때문에 코드 리뷰 문화가 있다는 것을 알게 됐을 때 어떤 식으로 진행하는지 무척 궁금했습니다. 화면에 내가 작성한 코드를 띄워놓고 회사의 모든 개발자들이 모여서 마구 질문을 쏟아내는 식일까 봐 걱정했는데 다행히도 그건 아니었습니다. 현재 github의 PR을 이용하여 코드 리뷰를 하고 있는데, 초반에 코드 리뷰를 받았을 때는 팀원분이 작성해 주신 리뷰를 이해하지 못했을 때도 있었고, 내가 작성한 코드에 질문이 들어왔을 때 대답하지 못하는 어려움도 있었습니다. 그럴 때는 구글링하거나 직접 여쭤보기도 하면서 해결하기 위해 노력했던 것 같습니다.
코드 리뷰를 받고 나서 우리 팀이 정한 코드 컨벤션을 지키려고 하고 있고, 내가 몰랐던 더 효율적인 방식을 제안해 주시기 때문에 코드 퀄리티가 전보다 좋아졌습니다. 또한 작성한 코드를 다시 한번 검토하는 것이므로 생각하지 못했던 사이드 이펙트를 발견할 수 있어서 버그를 줄일 수 있었습니다.
코드 리뷰를 하는 입장일 때는 거의 로컬에 브랜치를 받아서 코드를 확인하고 있는 데 PR을 보고도 확인할 수 있지만 전체적인 흐름을 파악할 때는 intelliJ에서 코드를 확인하는 게 효과적이라고 생각합니다. 처음에는 나보다 훨씬 잘하는 팀원의 코드를 리뷰한다는 자체가 부담이 됐었지만, 다른 분이 작성하신 코드를 보고 배울 수 있는 좋은 기회라고 생각하면서 리뷰어 역할에도 점점 익숙해지고 있습니다.
물론 아직 부족한 점이 많지만 좋은 코드란 무엇인지 고민하는 팀원들 덕분에 오늘도 성장하고 있고 함께 좋은 서비스를 만들어간다는 생각으로 코드 리뷰에 임하고 있습니다. 항상 시간을 들여서 꼼꼼하게 리뷰해 주시는 우리 팀원분들께 감사하며 이만 마치겠습니다.
