[Seminar] 한빛N MSA - 우리 팀의 코드 품질 향상을 위한 Code Review

다나·2023년 9월 6일
0

다담다 프로젝트

목록 보기
10/28

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 TestUnit 테스트를 실행한 모습입니다. 관련 글은 아래의 블로그에서 자세하게 살펴볼 수 있습니다.

✔️ Brach Protection Rule

  • 저희 팀은 3명으로 구성되어 있기 때문에, 1명의 승인을 받으면 Branch로 merge할 수 있는 구조로 설정하였습니다.

✔️ Self Review


3️⃣ 결론

  • Self Review는 세미나후부터 발표자분의 말씀에 공감하여 바로 프로젝트에 적용하였습니다!
  • 셀프 리뷰를 통해서, 다른 사람들이 코드 리뷰를 할 때 더 빠르게 이해할 수 있고, 제가 더 설명하고 싶은 내용도 작성할 수 있게 되어 리뷰에 대한 품질도 높아진 느낌이 들었습니다!
  • 이번 세미나는 저희 팀이 모두 참가하여 같이 들었는데, 끝나고 나서 코드 리뷰에 대한 반성과 앞으로 더 해야 할 점을 같이 이야기해서 더 좋았습니다🤩

🚘 해당 내용은 한빛 미디어의 세미나 내용을 토대로 작성되었습니다!
더 자세하고 많은 내용은 한빛 미디어에서 확인하실 수 있습니다^^

profile
컴퓨터공학과 학생이며, 백엔드 개발자입니다🐰

0개의 댓글