코드의 소유권(Code Ownership)은 다양한 형태로 나타난다. 이들은 크게 세 가지 범주로 나눠볼 수 있다:
- 강한 코드 소유권 코드 기반을 클래스, 함수나 파일 등의 모듈로 나눠서 개별 모듈을 특정 개발자에게 할당하는 방식. 개발자는 자기가 소유한 모듈에 대해서만 변경을 허용받는다. 다른 사람의 모듈에 변경이 필요한 경우는 이를 요청한다. 빨리 수정을 하게 하려면 패치를 작성해서 코드 소유자에게 보낼 수 있다.
- 약한 코드 소유권 은 모듈을 할당하기는 하지만 다른 사람의 코드도 수정할 수 있는 경우다. 모듈 소유자가 자신의 코드에 대한 책임을 지고 다른 사람에 의해 변경된 부분에 대해서도 모니터링해야 한다. 다른 사람의 코드에 많은 변경이 가해지는 경우라면 먼저 소유자에게 언급하는 것이 무례를 피하는 길이다.
- 코드의 공동 소유 모듈에 대한 개별 소유권은 없고 팀 전체가 코드기반을 공유하고, 누구나 어떤 코드라도 변경할 수 있는 경우다. 코드 소유권이 없는 것으로 간주할 수도 있지만, 공동 소유를 지지하는 이들은 개인이 아닌 팀이 소유한다는 사실을 강조한다.
나는 이들중에서 강한 코드 소유권을 좋아하지 않는다. 다른 사람의 코드를 변경할 일이 너무 잦기 때문이다. 담당자를 변경하도록 설득하고 이를 기다리는 일은 종종 많이 시간이 소요되어서 일정 지연이 발생한다. 특히 단순한 변경이 요구되는 상황이라면 문제가 더 커지게 만든다.
한 예로 public 메소드의 이름을 변경하는 경우를 보자. 대부분의 리팩토링 툴을 사용하면 public 메소드를 사용하는 코드에서 메소드 이름을 모두 찾아서 쉽게 변경하는 것이 가능하다. 그러나, 다른 사람이 소유한 모듈에 적용되면 소유권이 위배된다. Published Interface로 만들어야만 소유권 위반이 일어나지 않고, 그렇게 되면 변경에 따르는 부하가 증가된다.
더 문제가 되는 것은 개발자 본인의 코드에서 사용하는 다른 클래스에 변경을 가하고 싶을 때 이것이 바로 되지 않기 때문에, 변경후를 가정한 다른 코드를 임시로 작성해야 할 수도 있다. 물론, 추후 이들 코드의 일부는 반드시 찾아서 제거해야 하는 번거로움을 수반한다.
약한 코드 소유는 이런 문제를 상당히 줄일 수 있다. 자유롭게 수정할 수 있고, 코드 소유자는 지속적인 관리를 한다. 약한 코드 소유와 공동 소유중에 어떤 것을 선택하느냐는 팀이 어떻게 작업하느냐에 따라 달라진다. 개인적으로는 Extreme Programming에서 말하는 코드 공동 소유에 어울리는 작업방식을 선호한다.
원문: CodeOwnership
