0️⃣ 서론
감사하게도 2023년 8월 31일에 한빛 미디어에서 주최한 세미나에 초대받아서, 코드 리뷰 세미나를 들으러 갔습니다.
사진 출처 : https://festa.io/events/3819
제가 들었던 강의는 3회차로, 코드 리뷰 세미나에 사람이 꽉 차있을 정도로 많은 인기가 있었던 세미나였던 것 같습니다.
발표자 분은 그 유명한 이루다 인공지능을 개발하시는 곳의 스케터랩 ML Engineering Lead로 활동하고 계신 홍승환님이셨습니다🤩
이루다 사진 출처 : https://team.luda.ai
생생한 현장에서의 코드 리뷰 방법 뿐만 아니라 '코드 리뷰를 받는 사람의 노력', '코드 리뷰를 하는 사람의 노력'을 위주로 코드 리뷰의 필요성과 코드 리뷰를 하기 위해서 여러 사람들을 독려하는 방법까지 다 들어볼 수 있었습니다~!
1️⃣ 본론 1
코드 리뷰가 도대체 어떠한 이점이 있길래 사람들이 많이 하는 걸까요??
💡 코드 리뷰의 필요성
✔️ 제품의 품질 전반적인 상승과 보존
- 코드 리뷰를 통해서, 오류를 사전에 방지하고 문제 발생시에도 코드의 이해도가 높아지므로 해결력도 상승하게 됩니다.
✔️ Bus Factor의 최소화
- Bus Factor는 프로젝트가 잘 진행되기 위해서 꼭 필요한 사람의 수입니다.
- 따라서, 프로젝트를 진행하다가 해당 코드를 작성한 사람이 휴가거나 자리를 비우게 되어도 다른 사람들이 해당 코드 리뷰를 통해서 이해를 하고 있기 때문에 해당 코드를 작성한 사람이 아니더라도 오류를 수정하거나 프로젝트를 원활하게 진행할 수 있습니다.
✔️ 엔지니어링 업무의 효율화
- 코드 리뷰를 통해서 코딩 컨벤션을 같이 정하면서 방식을 합의할 수 있습니다.
- 실제로도 아키텍처와 코딩에는 정답이 없기 때문에 방식을 합의함으로써, 코드를 작성한 사람의 의도를 쉽게 파악할 수 있습니다.
➡️ 이처럼 코드 리뷰는 코드 전체뿐만 아니라 프로젝트(제품)의 전체적인 품질과 팀, 시간 여러 방면에서 도움을 줍니다.
이렇게 여러 장점이 있는 코드 리뷰를 우리 팀에 정착시키기 위해서는 어떻게 해야 할까요?? 🏝️
🏝️ 코드 리뷰를 우리 팀에 정착시키기
한 사람의 노력으로 코드 리뷰는 정착될 수 없습니다.
따라서, 코드 리뷰를 '받는' 사람의 노력과 코드 리뷰를 '하는' 사람의 노력이 모두 필요합니다.
그러면 코드 리뷰를 받는 사람은 과연 어떠한 노력을 해야 할까요??
💪코드 리뷰를 받는 사람의 노력
✔️ Git을 제대로 사용하자 🐈⬛
- 팀 내의 Branch 관리 전략을 준수하자!
- "Hotfix"라는 Branch를 사용하면, 빠르게 리뷰해야합니다.
- Commit covention을 정하자!
- 하나의 작업에 하나의 commit convention 메시지를 작성하여 변경사항 예측을 가능하게 해야 합니다.
✔️ 리뷰 받을 준비가 된 Pull Request를 만들자 🐬
- CI 파이프 라인(Type Checker, Unit Test) 을 모두 통과하였는지?
- Pull Request가 리뷰가 가능한 크기인가?
- 리뷰가 가능하지 않을 정도로 큰 크기의 PR인 경우, 세세한 리뷰를 받을 수 없고 코드 리뷰를 하는 사람의 부담이 커지게 됩니다!
- Brach Protection Rule, Self Review를 도입해보자!
✔️ 리뷰어를 설정하자 👩🏫
- 리뷰어를 랜덤으로 원하는 수만큼 설정할 수도 있습니다.
- 그러면, 사람들이 균일하게 코드 리뷰할 시간이 배정되어 한 사람에게만 집중되지 않습니다.
이번에는 코드 리뷰를 하는 사람은 어떠한 노력을 해야 할까요??
💪코드 리뷰를 하는 사람의 노력
✔️ 모든 것이 리뷰의 대상이다 🐈⬛
- 로직 구성과 풀어야 할 문제 + 미래에 올 상황에 대한 고민을 해야 합니다.
- 따라서, 지식을 공유하고 책임을 분배할 수 있습니다.
✔️ 리뷰를 두려워하지 말자 🫨
- 솔직하게 이야기하고, 건강하게 충돌해야 합니다.
- 사람을 비판하지 말고, 코드와 현상을 비판해야 합니다.
✔️ 상대방을 존중하고, 좋은 부분은 칭찬하자. 🌸
- 코드 리뷰를 해야 한다고 해서, 무조건 잘못된 점을 찾는 것이 아니라 잘못된 부분이 없다면 좋은 부분을 칭찬해서 팀워크도 다지고 코드 리뷰도 할 수 있습니다.
2️⃣ 본론 2
발표자님께서 말씀해주신 방법을 저희 팀에서 적용하고 있는 예시도 같이 보여드리겠습니다~!
저희 팀은 Jira를 사용해서 프로젝트를 관리하고 있는데, 활성 스프린트의 보드에서 리뷰와 검토완료라는 칸을 따로 만든 만큼 코드 리뷰에 대한 관심이 정말 많습니다!
✔️ 팀 내의 Branch 관리 전략을 준수하자!
- 현재 저희 팀에서는 'Git Glow'를 적용해서 사용하고 있습니다!
- 위의 Git-flow에서 master(main), develop, hotfix, feat 브랜치를 사용하고 있습니다.
- main 브랜치 : 최소 출시될 코드가 있는 브랜치(운영 서버에 반영되는 브랜치)입니다.
- hotfix: master(main)에서 버그를 수정할 브랜치입니다.
- develop: 다음 출시를 위해 개발하는 브랜치(개발 서버에 반영되는 브랜치)입니다.
- feat: develop에서 나온 브랜치로, 기능을 개발하는 브랜치입니다.
✔️ Commit covention을 정하자
[지라이슈번호] 작업: 설명
[JT-1] feat: 기능 추가
[JT-1] fix: 버그 수정
[JT-1] refactor: 코드 리팩토링(파일 이동, 파일 이름 수정 등)
[JT-1] style: 코드 스타일(코드 컨벤션 추가) 수정
[JT-1] docs: 문서 작업
[JT-1] design: 프론트 CSS 수정
[JT-1] test: 테스트 코드 작성
[JT-1] chore: 프로젝트 설정 파일 수정
예시) [JT-1] feat: 로그인 기능 추가
커밋 메시지는 한글로 작성한다. (기술적인 영어 제외)
예시) [JT-1] feat: add 로그인 기능 (X) [JT-1] feat: 로그인 기능 추가 (O)
✔️ CI 파이프 라인(Type Checker, Unit Test)
위의 PR Test는 Unit 테스트를 실행한 모습입니다. 관련 글은 아래의 블로그에서 자세하게 살펴볼 수 있습니다.
✔️ Brach Protection Rule
- 저희 팀은 3명으로 구성되어 있기 때문에, 1명의 승인을 받으면 Branch로 merge할 수 있는 구조로 설정하였습니다.
✔️ Self Review
3️⃣ 결론
- Self Review는 세미나후부터 발표자분의 말씀에 공감하여 바로 프로젝트에 적용하였습니다!
- 셀프 리뷰를 통해서, 다른 사람들이 코드 리뷰를 할 때 더 빠르게 이해할 수 있고, 제가 더 설명하고 싶은 내용도 작성할 수 있게 되어 리뷰에 대한 품질도 높아진 느낌이 들었습니다!
- 이번 세미나는 저희 팀이 모두 참가하여 같이 들었는데, 끝나고 나서 코드 리뷰에 대한 반성과 앞으로 더 해야 할 점을 같이 이야기해서 더 좋았습니다🤩
🚘 해당 내용은 한빛 미디어의 세미나 내용을 토대로 작성되었습니다!
더 자세하고 많은 내용은 한빛 미디어에서 확인하실 수 있습니다^^
