1) 구글에서의 코드 리뷰
http://sv-story.blogspot.kr/2013/04/blog-post_28.html
2) 카카오스톨팀의 코드 리뷰 도입 사례
http://tech.kakao.com/2016/02/04/code-review/
위의 글을 읽고 몇가지 배울 점과 적용해 볼 점을 나의 상황에 맞게 정리해 보았다. 너무 많으면 어차피 까먹을 테니, 4가지만 정리해서 기억하기로 했다.
나의 경우는 인도 개발자와 원거리 협업을 하므로, 메일로 코드 리뷰 요청을 받는데 이 경우 자꾸 뒤로 미루는 경향이 있다. 그런데 이때 더 큰 문제는 우리 회사는 코드 리뷰를 꼭 받아야 메인라인에 수정사항을 반영할 수 있기 때문에, 코드 리뷰를 미루다 보면 인도 개발자가 메인라인에 수정사항을 반영하는 일이 계속 딜레이된다.
1. 코드 리뷰 요청을 받으면, 요청받은 당일에 반드시 코드 리뷰를 한다.
2. Minor change의 경우 인도 개발자들끼리 코드 리뷰를 수행하도록 하고, major change나 SW release에 가까워서 발생한 문제에 대한 수정사항은 나에게 코드 리뷰를 요청하도록 한다.
그런데 사실 2번 사항은, 아직 해야 하나 말아야 하나 고민 중이다. 최종적으로는 인도 개발자들끼리 코드 리뷰를 하도록 해야 하지만 지금은 아직 아닌 것 같다는 생각이 든다.
왜냐하면 인도 개발자들끼리 진행하는 코드 리뷰가 진정 의미 있는 코드 리뷰가 될지 아직은 의문이기 때문이다. 나는 사실 아직 인도 개발자들이 믿음이 안간다. 그래서 요즘 항상 어떻게 하면 인도 개발자들을 서로 코드 리뷰를 할 수 있는 수준까지 끌어올릴 수 있을까 고민 중이다. (나도 잘 모르는데, 남을 걱정하는 내 모습이 웃프다.)
3. 코드 리뷰 시, 코드에 대한 전체적인 디자인을 본다. 더 단순한 구조, 이해하기 쉬운 구조, 확장성, 테스트가 쉬운 구조인지 생각해본다.
4. 코드 리뷰 시, 내가 생각하는 구조나 디자인에 대해서 너무 강요하지 않는다.
![]() |
<나랑 생각이 다르구만! 내 코드랑 안 맞아!> |
그리고 바로 앞 글 '코드 리뷰, 그 냉정과 열정 사이(1)'을 쓰는 동안은 코드 리뷰의 진정한 목적이 잠재적인 버그 찾기라고 생각했다. 그런데 코드 리뷰를 잘하는 방법에 대한 글들을 찾다보니 버그 찾기는 코드 리뷰의 목적 중 일부분에 불과하다는 글들이 많더라. 그래서 코드 리뷰의 진정한 목적이 무엇인지 요즘 또 고민중이다.
0 개의 댓글:
댓글 쓰기