이제는 디폴트가 된 git/github 시대에 예전을 생각하면 svn(tortoise 제품, 맨날 톨토이즈라고 발음 했는데 실제로는 털터스[tɔːrtəs]), hg(mercurial) 이런 것들을 사용했다.
commit 하면 바로 서버에 올라가고 필요한 사람이 trunk 였나? 여기로 머지를 했던것 깉다.
이때는 코드 리뷰라는 말도 생소 했고, 내 로컬에서 새 버전을 다운받아 에러가 발생하면 그제야 서버 커밋 로그를 뒤져 어떻게든 돌아가게 하려고 했던 기억이 난다.
github 같은게 없어서 메신져나 동료 옆자리에 앉아 같이 코드를 보면서 수정을 했었는데...(pair programming 이라는 말도 몰랐을때다)
그러고 보면 git/github 이 이전 버전 컨트롤 보다 개발도 편하고 코드 충돌에 있어서도 교통 정리를 잘해준다.
github 이라는 오픈 공간은 같은 관심사를 가진 여러 사람들을 모이게 했고 집단지성을 발휘해 빠른 속도로 좋은 프로그램들이 많이 나올 수 있는 인큐베이터가 됐다.
이런 흐름속에 PR(Pull Request)라는 과정이 추가되고, 이곳에선 더 좋은 품질을 위해 생각을 공유하고 때론 배움의 장소로 사용된다.
실제로 구글링 하면 github 이슈에서 원인과 해결방법을 제시해주기 때문에 스택오버플루와 함께 깃헙은 좋은 나에게 좋은 선생님들이다. 이젠 이것도 AI 가 잘해주지만...
암튼 이 PR 과정에 코드리뷰가 진행되고 commiter 의 코드를 보며 갑론을박 토론의 장이 펼쳐지곤 한다.
이런 토론이 가끔 나쁘게 흘러가는 경우가 있다.
상대를 무시하는 듯한 말투, 뭐하나라도 꼬투리를 잡아 늘어지는 경우등 이런 것 들은 기여자를 기죽게하고 contribute 에 소극적이게 한다.
개인적으로 품질과 함께 생산성이 중요하다고 생각한다.
생산성에 여러 의미가 있지만 난 속도에 무게를 두고 싶다.
container 가상화, 자동화 테스트, 심지어 프로그래밍까지 간결하고 이해하기 쉬우면서도 오류를 적게 나는 언어등으로 우리는 예전 보다 더 쉽고 빠르게 (rust 생각하면)때론 더 안전하게 만들 수 있다.
그리고 AI로 품질과 생산성이 좋아져 더 좋은 서비스가 출시가 더 빨라지기까지 한다.
이런 환경속에서 서비스(software/product)가 경쟁하듯 쏟아진다.
비지니스 관점에서도 빠른 서비스 출시는 시장 장악, 매출에도 영향이 클것이다.
상황이 이런데 나,우리의 서비스도 개발을 빨라해야 되지 않을까?
물론 코드 품질은 유지하면서도 속도도 높여야 겠지.
그런데 개발과정에서 아마 문제해결을 위한 시간 다음으로 협업과정에 오는 커뮤니케이션, 프로그래머들에겐 상시 진행되는 코드리뷰 과정이 많이 시간이을 잡아 먹는것 같다.
위 코드리뷰 안티패턴의 다크사이드 리뷰어가 아니더라도 들어보며 많은 프로젝트들이 리뷰 시간이 길어져 전체적인 생산성 저하가 발생되는것을 종종 본다.
코드 리뷰 과정은 적게는 1시간에 끝날 수도 있지만 길게는 일주일, 어쩌면 영영 끝나지 않고 묻히기도 한다.
리뷰가 지체로 PR 이 쌓이면 다음 작업에 영향을 미친다. 아무리 병렬적으로 작업을 한다고 해도 최종적으로 하나의 브랜치로 머지되니 다른 작업을 하고 있다면 수시로 diff 부분을 따라가고 충돌부분도 수정해야된다. 때론 중복 작업 까지 발생해 진짜 현재 PR중이 것들과 영향이 없는 이슈에 대해서만 병렬로 작업하는게 정신건강에 좋다.
암튼 지체되는 리뷰들을 되도록 줄여 개발 진행에 막힘이 없으면 한다.
이 문제와 관련한 여러 커뮤니티,기술블로그들의 글을 찾아봤다.
빠른 리뷰를 위해 많이 말하는게 데드라인, 템플릿, 우선순위, 알림등 이런저런 규칙과 시스템이 있었다.
이런것들로 어느정도 효과를 봤다고 수치와 그래프를 보여주기도 한다.
반면 이런 규칙과 제한등을 두면 사람들은 반감을 사고 오히려 리뷰를 대충하거나 소극적으로 한다 등의 안좋은 결과를 보였다는 글도 있었다.
개인적으로 알림, 템플릿은 optional(있으면 좋지만 없어도 딱히)이고 중요한건 리뷰문화 인것 같다.
내 코드 작성하는 것도 바뻐 다른 사람 코드 리뷰하는 시간이 부족하다는 말은 많이 하는데,
좀 들여다 보면 리뷰가 자체가 굉장한 스트레스로 다가오는 경우가 많다.
나같은 경우 github files changed 들을 보면 빨간색/초록색으로 보이는 차이들이 잘 읽히지 않는다. 마치 틀린그림 찾기처럼 꽤 집중을 해야 한다.
그래서 리뷰 잘 그리고 빠르게 하려면 내 생각은
- github > pulls/review-requested 로 나에게 요청한 리뷰들 수시로 확인하는 습관
- 리뷰 중 생각난 문제들은 별도의 이슈를 생성하고 현재 리뷰는 마무리
- 리뷰 커멘트 작성시 명확하고 되도록 친절한 말을 사용
좋은 코드 뿐 아니라 잘 운영되는 리뷰 문화도 팀이 생산하는 또 하나의 결과물이 아닌가 싶다.
