프로젝트 초기부터 '선리뷰 후커밋'을 실행했지만, 잘 되는 것 같지 않아 '선커밋 후리뷰'을 하자고 제안하였다. 구성원이 한 자리에 모여 작업하는 시간이 주 4시간 정도가 되었다면, 개발 속도가 느리지는 않았을 것 같다. 각자 원하는 시간대에 작업을 하기 때문에, 리뷰어가 리뷰를 해줄 때까지 기다리는 것이 큰 낭비가 된다. 리뷰를 받아 패치를 마스터에 올리기 전까지는 다음 패치를 작성할 수 없을 가능성이 높기 때문이다. 또한 리뷰를 받고, 패치를 올리기까지의 과정이 낯설어, 이런 프로세스에 익숙하지 않을 경우 패치를 작성하기 조차 어렵게 만드는 장벽이 될 수도 있다고 생각된다.

내가 돈(!)을 받으며 코딩을 시작했을 때, 코드 베이스는 오픈소스 프로젝트 웹킷(이하 웹킷)의 최신 리비전이었고, 웹킷은 이미 훌륭하게 잘 돌아가는 프로젝트였다. Challengers3가 지지부진하게 진행되면서 가장 답답했던 부분은, 훌륭하진 못하더라도, 적어도 일부 기능이 돌아가는 코드 베이스가 없었고 코드 베이스가 없었기 때문인지는 몰라도, 리뷰 프로세스나 이슈트래커가 오히려 생산성을 떨어뜨리는게 아닌가 하는 느낌이 들었다. 코드 리뷰를 해서 더 나은 점을 찾기엔 모든 부분이 논의가 안되어 있었고, 모든 부분이 이슈였다.
-
팀원들이 온라인으로 작업하는 환경에서, 어느 정도 돌아가는 코드를 효율적으로 협업하려면 어떻게 해야 할까.