#gerrit #codereview 사용 소감 [2014-01, 2017-03]

/pnotes/assets/2017-04-16-gerrit-code-review-2014-01-2017-03.jpg

느슨한 규칙을 사용해도 충분히 도움이 된 코드 리뷰

리뷰를 염두에 둔 커밋을 만드는 게 가장 큰 장점이라 생각한다. 2점 이상 돼야 머지할 수 있는 규칙. 커밋을 올린 사람도 2점을 줄 수 있는 느슨한 규칙을 사용했다. 느슨한 규칙을 사용했어도 리뷰를 염두에 둔 커밋을 만들 게 된다는 건 코드 품질 향상에 크게 기여한다고 생각한다.

다른 사람에게 코드 검토를 부탁하는 일은 생각보다 힘든 일이다. 논리의 오류나 지름길을 놔두고 내가 둘러간 길을 지적받기 위해서인데, 이런 지적에 마음 상하지 않기가 참 어렵다. 그래서 코드 검토를 부탁하는 일이 드문지도 모른다. 여기서 이런 문제를 명쾌하게 짚어 주는데 코드와 자신을 동일시하는 자아적 프로그래밍(ego programming) 때문에 이런 현상이 발생한다는 거다. 코드에 대한 비판을 감성적이지 않고 이성적으로 받아들일 수 있는 즉, 코드와 자신을 분리할 수 있는 이런 걸 비자아적 프로그래밍(egoless programming)이라 부른다

- #book 프로그래밍 심리학 - 프로그래밍은 사람이 한다

비자아적 프로그래밍(egoless programming)은 힘들다. 훈련이 필요하다. 난 아직도 멀었다. 진짜 코드와 자신을 분리할 수 있긴 한 걸까? 하지만 초반보다는 덜해졌다. 이런 변화를 보면 더 훈련하면 가능할지도 모르겠다. 힘들다는 걸 알면 코드 리뷰에 대한 말투도 조금은 상대방을 배려하게 된다.

초반에는 스타일에 대해 리뷰도 했었는데, 효과가 별로 없음을 깨달았다. 논의가 생각보다 길어지고 논의 후에 나와야 하는 행동을 이끌기가 힘들었다. 그래서 후반에는 코드에 대한 결함에 집중했다. 이해가 잘 안 되는 코드에 대해 질문도 같이. 이 두 가지만 해도 코드 리뷰를 도입할 만하다고 생각한다.

딱 필요한 것만 있는 gerrit

코드 리뷰 툴로는 gerrit을 사용했다. 이슈 트래킹 시스템으로 레드마인을 사용 중이어서 코드 리뷰 기능만 있어도 충분했다. 겹치는 기능이 없어서 정보가 흩어질 염려도 없고 어디에 적어야 하나 고민할 필요도 없었다.

gerrit 버전을 따라가지 못한 게 아쉽다. 망했을 때, 파급력이 큰 툴이라 업그레이드가 겁난다. 업그레이드에 대한 두려움을 없애려고 docker를 고려했다. 이미 설치된 CentOS 버전 때문에 좌절. 그래서 그냥 미뤄버렸다. 버전을 잘 따라갔으면 좀 더 편해졌을 텐데 아쉽다. 딱히 담당자가 있진 않았고 답답한 사람이 버전 올리는 총대를 메는 식이었다. 공용 조직 도움을 받던가 속 편하게 호스팅 서비스를 사용하는 게 어떨까? 최대한 개발에 집중하고 싶다.

코딩 컨벤션을 자동으로 지적하는 봇을 못 만들었다. 코딩 컨벤션 지적하는 리뷰를 보면 이건 사람이 할 일이 아니란 생각이 들었다. 서로 에너지만 낭비하는 일이다. 에너지 낭비는 무한한 에너지를 가진 봇이 해야 한다.

불편한 게 있어서 추가 작업을 했다. 그중에는 gerrit 버전만 잘 따라갔으면 따로 할 필요 없는 작업도 있다. 커밋 메시지에 있는 일감 번호 링크를 따로 만들었다. 커밋 메시지 규칙을 어기면 -1점을 주게 했다. 커밋 메시지에 특정 문자열을 넣으면 해당 프로그래머를 자동으로 리뷰어로 추가했다. 잘 동작했다. 제어할 수 없는 문제가 하나 있었다. patchset-created 훅이 너무 늦게 실행되는 문제. 최신 버전은 어떤지 모르겠다.


크리에이티브 커먼즈 라이선스 |