제가요?
처음 코드 리뷰를 할 때 든 생각이다.
나보다 잘하는 사람의 코드를 보고 무슨 의견을 남기란 말인가?
입사 직후에는 로직을 따라가는 것도 바빴기 때문에 크게 의견을 남기지 못했다.
‘잘 하시는 분이니까 잘 짜셨겠지’
‘뭔소린지 모르겠는건 내가 부족해서겠지’
‘뭔가 깊은 뜻이 있겠지’
‘내가 도메인 지식이 부족해서 그렇겠지’
라고 생각하면서 ‘고생하셨습니다!’ 라고 남기고 approve 누르기 바빴다.
어차피 잘 짜셨을테니 빨리 처리하는게 좋을테니까.
완벽한 사람은 없다
그런데 내가 코드 리뷰한 곳에서 버그가 터지는게 아닌가?!
PR로 올라왔던 버그가 해결되지 않은 경우도 있고
버그는 고쳤지만 새로운 버그가 생긴 경우도 있었다.
가만 생각해보면 너무 당연한 이야기다.
세상에 버그 없이 코드를 짜는 사람이 있을까?
리누스 토발즈도 그렇겐 못할거다.
자소서를 하나 써도 첨삭이 필요하듯 코드도 그렇다.
내가 생각하는 코드 리뷰 잘하는 방법 (Jr)
1. 아무도 믿지 말자
적어도 PR을 처리할 때는 아무도 믿지 마라.
혹시 같이 코드 리뷰를 담당한 동료 직원을 믿고 있나?
잘 해줄 수도 있지만 버그를 놓칠 수 있다. 그도 사람이다.테스트 코드를 믿는가?
테스트 코드가 제대로 작성되지 않았을 수 있다.
또한 FE의 경우 여러가지 현실적인 이유로 100% coverage로 작성하지 않는 경우가 많다.QA 직원을 믿는가?
QA 담당이 있다니 부럽다…
나밖에 없다는 마음으로 코드 리뷰를 해야한다.
내가 놓치면 그냥 버그가 있는 상태로 배포 되는거다.
2. 이해가 안되면 이해가 안된다고 말해보자
내 경험상 이해 못하고 그냥 넘기면 꼭 거기서 버그가 생겼다.
모른다고 말하는게 정말 어렵다는걸 잘안다.
특히 입사한지 얼마 안됐을 때는
- 코드가 별로여서 이해가 안되는 건지
- 도메인을 몰라서 이해가 안되는 건지
- 내가 바보여서 모르는 건지
구별이 잘 안가는데.. 그냥 말하자. 아무것도 모른다고.
민망하면 approve 누르면서라도 물어보자. 이거 모르겠다고.
정 안되겠으면 어느정도 친해지고라도 꼭 말해보자.
잘 모르겠어요! 😫
3. pull 받아서 직접 테스트 해보자
코드 리뷰 시스템 상에서 코드만 보고 버그를 잡고 있는가?
내가 부족해서 그런지 몰라도 읽기만 해서는 제대로 찾기 힘들었다.
생각보다 직접 이것저것 눌러보는 것이 효과적이다!
꼭 pull 받아서 간단하게라도 이것저것 테스트해보자.
4. 웬만하면 버그 하나는 찾는다는 마음으로 임하자
간단한 수정이 아니라면 버그 하나는 찾는다는 각오로 리뷰하자.
버그를 찾을 때까지 테스트하다보면 생각보다 많은 시간이 소요된다.
평소에 몇 시에 어떤 일을 해놨는지 기록하고 있는데
코드리뷰 로드가 심할 때는 총 근무시간의 15%를 차지한적도 있다(한 달 기준).
이렇게 하면 개발 시간이 늦어져서 팀원들이 싫어할까?
적어도 우리 회사 팀원들은 다들 좋아했다.
말 뿐만이 아니라 인사 평가(동료 평가 포함)에서 가장 많이 받은 칭찬이 꼼꼼함이었다.
개발 속도를 중요시 하는 회사라면 당연히 느슨하게 해도 좋다.
빡세게 -> 느슨하게로 바꾸는건 정말 쉬울 것이다.
5. 일정한 시간에 코드 리뷰 해보자
개인적으로 출근 직후 시간을 추천한다.
근무 중간에 코드 리뷰를 하려면 업무 -> 코드 리뷰 -> 업무 식으로 context switching이 두 번 발생한다.
코드 리뷰는 생각보다 어려운 일이다!
오전에 한다면 한 번의 context switching으로 끝낼 수 있다.
만약 이걸로 부족하다면 출근 직후, 퇴근 직전으로 나눠서 하는 것을 추천한다.
6. 개선점을 발견했을 때 부드럽게 의견 남기기
이거 이러저러하게 하는게 좋으니까 이러저러하게 고쳐주세요 - X
이러저러하는게 더 좋을 수도 있을 것 같은데 xx님 생각은 어떠세요? - O
저어어얼대로 상대방이 지적 받는다는 느낌을 들게하지 말자.
잘하는 분에게 배울때 조차 얼굴이 빨개지며 민망한 경우가 있는데
나의 실수를 남이 알아본다고 생각해봐라!
지적하는게 아니라 의견을 구한다는 느낌으로 글을 적자.
또 하나 첨언하자면 다보다 요로 끝나는게 훨씬 부드러워 보인다.
이러저러하게 부탁드립니다 - ?
이러저러하게 부탁드려요! - O
7. 멋진 코드/방법을 봤다면 리액션 코멘트 남기기
개발자는 의외로 칭찬에 약하다!
멋진 코드를 보고 배웠다면 아낌없이 따봉을 눌러주자.
코드 리뷰 기능으로 멋지다는 코멘트를 남기는 방법도 추천한다.
8. 위 내용을 팀원들에게 강요하지 않기
팀원들에게 위 내용을 강요하지 말자. (부드럽게 의견남기기 정도는 말해도 될 것 같다)
특히 pull 받아서 테스트 하는 것과 버그를 찾을 때까지 코드 리뷰하는 것은 부담감을 가지기 쉽다.
이는 코드 리뷰가 점점 늦어지는 원인이 될 것이다.
그냥 나혼자 이렇게 한다고 생각하자.
다른 사람을 바꾸는 것은 생각보다 훨씬 어려운 일이다.
커뮤니케이션을 잘 해보자
개발자에게 커뮤니케이션 능력은 생각보다 중요하다.
매일 함께 일하는 동료들과 좋은 관계를 유지하는 것이 생산성에도 도움이 되기 때문이다.
코드 리뷰는 개발자가 매일 하는 커뮤니케이션이니 이를 잘 이용해서 HAPPY CODING 해보자!
If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. If the images used in the blog infringe your copyright, please contact the author to delete them. Thank you !