실용주의이야기(Pragmatic Story)

모든 사람이 매일 커밋하기

통합은 커뮤니케이션이 주가 된다. 통합은 개발자가 다른 개발자에게 변경사항에 대해 이야기 하도록 해준다. 잦은 커뮤니케이션은 사람들에게 개발에 따른 변경을 빨리 알려주게 된다.

개발자가 메인라인에 커밋을 하는데 있어 단 하나의 사전조건은 코드가 빌드되어야 한다는 것이다. 물론 이 조건은 빌드 테스트도 성공해야 함을 내포한다. 커밋의 주기가 어떻든지간에 개발자는 작업한 것을 메인라인에 맞춰서 반영해야 하는데, 메인라인과 충돌이 발생하면 이를 해결해서 자기 PC에서 빌드가 되도록 해야 한다. 빌드가 되면 메인라인에 커밋해도 된다.

이렇게 자주 하면 할수록, 개발자는 두 개발자간에 충돌이 있음을 빨리 발견할 수가 있다. 문제를 빨리 해결하는데 있어 중요한건 빨리 발견하는 것이다. 개발자가 몇시간 마다 커밋하다 발생하는 충돌은 발생한지 몇시간내에 발견되기 때문에 이를 해결하는건 그리 어렵지 않다. 몇주동안 남아있던 충돌을 해결하는게 어렵다.

작업한게 빌드된다는 사실은 문자그대로 컴파일 단계에서의 충돌을 발견했다는 의미이다. 빌드 단계중에 셀프 테스팅이 있다면 코드가 실행되는 중에 충돌 역시 발견할수가 있다.  후자의 충돌이 오랫동안 코드에 숨겨져 있던 버그를 발견하는 셈이다. 커밋간에 단지 몇시간의 차이만 있다 하더라도 문제는 여러 부분에 숨어있게 된다. 더우기 변경이 많이 이루어진 경우에는 diff-debugiing을 사용하는게 버그를 찾는데 도움이 된다.

내가 가진 일반적인 규칙은 모든 개발자는 매일 레파지터리에 커밋해야만 한다는 것이다. 사실 개발자가 더 자주 커밋하는게 유용할때도 있다. 더 자주 커밋하면 충돌 에러때문에 살펴봐야 하는곳이 더 적어지고, 그래서 더 빨리 충돌을 수정할 수 있다.

잦은 커밋은 개발자가 자기가 작업할 분량을 몇시간내로 마칠수 있는 작은 단위로 세분화 하도록 만든다. 이는 진척도를 추적하고 진척도를 이해하는데 도움이 된다. 사람들은 처음에는 몇 시간내에 의미있는 작업을 할수 있다고 생각하지 않는다. 하지만 멘토링과 실습을 통해서 가능하다는것을 알게된다.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.