코드 리뷰를 하다보면 같은 얘기를 반복해서 적게 된다.
리뷰어 입장
같은 얘기를 약간씩 다른 코드에 적게 된다. 리뷰를 하는 리뷰어 입장에서는 처음에는 길게 친절히 적더라도 시간이 지날수록 간략하게 또는 대충 적게 된다. 이미 자신은 다 알고 있는 상황을 적는 것이고, 상대방도 같은 팀 구성원이라면 당연히 알아야 한다고 가정하고 적기 때문이다(참조: 지식의 저주). 예를 들면 "n+1 이슈 있는지 확인 부탁드려요."라는 리뷰가 있다. 리뷰어 입장에서는 꽤 친절하게 적었다고 생각할 수도 있다. 어느 부분이 문제인지 코드 영역을 표시했고, 핵심만 간단히 적었으며, 어떠한 감정도 실지 않았으니까. 하지만 코드 작성자가 n+1 이슈가 무엇인지 모른다면 어떻게 될까.
코드 작성자 입장
코드 작성자는 당혹스러운 경우가 생긴다. 코딩 가이드를 제대로 받지 못한 상황에서, 코드 작성자는 최대한 기존 관습(컨벤션convention)에 맞게 작성하기 위해서 노력하게 된다. 자신이 맡아서 개발하게 된 부분의 주변 코드를 유심히 살펴보고 최대한 비슷하게 개발한다. 그런데 풀리퀘스트(Pull Request(PR): 코드 반영 요청, 작업 브랜치의 코드를 다른 브랜치에 합치는 것을 요청하는 것) 때 코드 리뷰를 받으면 리뷰가 많이 달린다. 리뷰review는 사실 지적이나 틀렸다고 빨간펜을 그어 놓은 것과 큰 차이가 없다. 글쓰기 수업 때 제출한 과제가 빨간펜이 쭉쭉 그어진 상태로 돌려받았을 때 느낌을 생각해 보면 된다. 그리 기분이 좋지는 않다. 충분히 살펴보고 비슷하게 개발했는데 리뷰가 많이 달리니 당혹스럽다.
기존 코드는 최신 컨벤션을 반영하지 못한다
팀 이력이 오래된 경우 주변 코드도 오래되었을 수 있다. 그 사이 팀이 성장해서 과거의 코드가 현재의 관습을 반영하지 못하고 있는 것이다. 따라서 과거의 코드와 비슷하게 작성해도 리뷰는 피할 수 없다. 특히 새로 팀에 합류한 사람이 이런 문제를 많이 겪게 된다. 새로 들어온 사람이 현재의 관습을 바로 정확히 파악하기는 불가능하다. 결국 리뷰를 받으면서 현재의 관습을 파악하게 된다. 리뷰를 하는 리뷰어도, 리뷰를 받는 코드 작성자도 서로 피곤한 시간을 보낼 수밖에 없다. 그나마 피곤함을 줄이는 방법은 코드 작성자가 코드가 아니라 최근 코드 리뷰를 쭉 살펴보는 것이다. 최근 코드 리뷰를 살펴봐야 가장 정확하게 최근의 코딩 관습을 파악할 수 있기 때문이다.
원인은 무엇일까
가장 큰 원인은 가이드가 없다는 것이다. 내 경우 가이드를 받은 적이 없었는데, 파이썬 import를 파이참 import 최적화 기능을 사용하지 않고 수동으로 적었다고 리뷰를 받은 적이 있다. 리뷰어는 같은 일이 반복되니 약간 짜증이 났는지 "아직도 자동 import 기능 사용 안 하고 수동으로 하는 사람이 있는 거 같은데..."라고 개발팀 슬랙 채널에도 메시지를 적었다. 리뷰어 입장에서는 충분히 짜증날 거 같다. '도대체 몇 번을 말해야 알아듣는 걸까'라고 생각할 거 같다. 하지만 나는 처음 들었다. 그 누구도 나한테 가이드를 해준 적이 없었다. '아직도'란 단어가 내포한 감정을 읽었기 때문에 그 메시지를 보자마자 또 같은 리뷰를 받지 않도록 사내 위키에 import 최적화 방법을 찾아서 자세히 정리했다. 내 사례에서 가이드가 처음부터 있었고, 가이드가 신규 입사자한테 잘 전달되었다면 어땠을까. '아직도'로 시작하는 슬랙 메시지를 쓸 필요도, 리뷰로 지적을 받을 일도 생기지 않았을 것이다. 서로 피곤한 상황을 최소화할 수 있었을 것이다.
가이드 작성법
가이드는 최대한 이해하기 쉽게 작성해야 한다. 지식의 저주에서 벗어나서 상대방 입장에서 작성해야 한다. 그래야 상대방이 쉽게 이해하고 질문이 줄어 들게 되기 때문이다. 일단 처음에는 이해하기 쉽게 작성하고, 질문을 받으면 해당 내용을 보충해서 수정하는 식으로 작성하자. 코드 작성자 입장에서 이해하기 쉽게 X O 예시가 있는 가이드를 작성하자.
가이드 예
앞에서 일화로 소개한 import 최적화를 예로 든다면
파이참 import 최적화 적용
X 잘못된 예
파이참 import 최적화 미적용되어 내장 모듈 os, sys 부터 import되지 않았고, 알파벳 순으로 정렬이 안 되어 있음.
from dotenv import load_dotenv
import sys
import os
O 좋은 예
파이참 import 최적화가 적용되어 내장 모듈, 외부 팩키지 순이며 내장 모듈과 외부 팩키지가 새 줄로 구분되어 있으며 알파벳 순으로 정렬되어 있음(최적화 적용 방법은 위키 참조).
import os
import sys
from dotenv import load_dotenv
이라고 위키에 작성할 수 있을 거 같다. 그리고 코드 리뷰를 하다가 파이참 import 최적화 미적용된 경우를 보게 되면 "파이참 import 최적화 적용 코딩 가이드 참고해서 수정 부탁드립니다."라고 짧게 적고 밑줄 그은 부분에 링크를 연결하는 것이다. 이렇게 하면 자세한 설명을 매번 적을 필요가 없다. 자세한 설명은 가이드에 적혀 있으니까. 코드 작성자도 가이드의 자세한 설명을 보고 쉽게 이해하고 수정할 수 있다.
효과
1. 리뷰 건수가 준다. 리뷰가 적은 게 당연히 좋은 거다. 팀원 전체가 코딩 관습을 숙지해서 지적할 것이 줄었다는 의미이니까.
2. 리뷰 시간이 줄어든다. 리뷰 건수가 줄어드니 당연히 리뷰 시간이 줄어든다. 리뷰를 하더라도 가이드 링크로 대신하니 리뷰 작성 시간도 줄어든다.
3. 신규 팀원이 빨리 적응한다. 가이드를 미리 숙지할 수 있으므로 기존 팀원과 비슷한 코드를 작성하기까지 걸리는 시간이 줄어든다.
4. 개발할 시간이 증가한다. 코드 리뷰 시간이 줄어드니 당연히 개발할 시간이 늘어난다.
5. 전체 개발 속도가 빨라진다. 코드 리뷰가 개발 문화로 있는 개발팀에서는 사실 코드 리뷰가 가장 큰 병목이다. 리뷰를 받은 뒤, 리뷰를 반영하고, 다시 리뷰 받는 과정을 반복하고, 최종 승인받아야 작업이 끝나는데, 이 리뷰로 인한 병목 시간이 줄어들기 때문이다.