저만의 생각입니다.
AI Code Review
코드 리뷰는 시간을 꽤 잡아먹는 행위입니다. AI가 적어도 적절치 못한 로직이나 문법은 잘 잡아냅니다. 커다란 문맥 안에서는 파악하지 못하더라도, 시간 절약을 위해 AI 코드 리뷰를 활용합니다.
리뷰어는 1~2명 정도
모두가 보면 베스트이긴 하나, 현실적으로 그건 굉장히 어렵다고 생각합니다. 따라서 1~2명 정도가 번갈아가면서 맡는 걸로 합의를 보면 좋지 않을까 생각합니다.
변화를 작게 유지하기
프로젝트 초기화 같은 경우에는 코드가 아니더라도 변경되는 코드 라인 수가 적지 않습니다. 좀 귀찮더라도, 프로젝트 초기화, 프로젝트 설정 등과 같이 세분화해서 PR을 생성하고 리뷰어가 적은 양의 코드 수를 리뷰할 수 있도록 유지하는게 가장 좋다고 생각합니다.
개발을 진행하다가도 많은 라인의 코드가 변경되면 유동적으로 브랜치를 더 잘게 나눠 팀과 협업하는 것 또한 매우 중요합니다.
리뷰를 자주 & 짧게 진행하기
리뷰는 마치 일기를 작성하는 것처럼 안 보려고 하면 퇴근할 때까지도 안 볼 수 있는 행위입니다. 그렇기에 코드 리뷰 양을 줄이고, 마치 잠깐 분위기 전환하는 것처럼 일하다가도 리뷰를 봐주는 의도적인 행동이 필요하다고 생각합니다.
PR 생성자는 충분한 정보를 제공할 것
제가 정글에서 PR 리뷰하면서 느끼는 것은, 코드 작성자가 자신의 의도대로 코드를 설명하지 않는다는 겁니다. 이건 당해봐야 아는건데, 직접 AI와 함께 작성하는 것과 리뷰를 진행하는 것은 느낌이 매우 다릅니다.
그렇기에 PR 생성자는 자신이 왜 그렇게 코드를 작성했는지, 왜 그래야만 하는지, 어떤 상황이었는지 등을 상세하게 설명할 필요가 있다고 생각합니다.
Continuous Integration 활용하기
CI를 활용하면 다음과 같은 체크가 가능합니다 :
•
포맷팅 검사
•
테스트 코드 실행
윗 두 가지만 하더라도 굉장한 시간을 절약 가능하며 코드 품질(스타일)을 일관성있게 유지하면서 머지할 수 있습니다. 따라서 PR에 CI 기능을 활용해서 PR을 진행해야한다고 봅니다.
P-N 룰
뱅크샐러드의 PR 문화에서 가져와서 제안합니다.
P1
꼭 반영해주세요 | Request Changes
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
P2
적극적으로 고려해주세요 | Request Changes
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.
P3
웬만하면 반영해주세요 | Comment
작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.
P4
반영해도 좋고 넘어가도 좋아요 | Approve
작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
P5
그냥 사소한 의견입니다 | Approve
작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
이런 느낌입니다
참고 자료
