코드 소유권에 대한 좋은 글이 있어서 올립니다.
우리 회사의 기본 입장은 소스코드의 공동소유입니다.
기민한 개발을 위해서는 잘못된 코드는 다른 개발자가 작성한 것이라도 바로 고칠 수 있어야 합니다.
다만 뭐가 잘못되었고 왜 그렇게 고쳤는지는 원 개발자에게 통보 할 수 있는 소통 문화가 있어야 할 것 같습니다.
개발자 마다 구현 방식에 차이가 있고 구현 방식마다 장단점이 있기 때문에
이 부분에 대해서는 거리낌없이 자유로운 토론을 할 수 있는 개발문화가 필요하다고 생각합니다.
코드 리뷰 시간을 활용하는 것도 좋을 것 같군요
코드 공동 소유(Collective Code Ownership)
익스트림 프로그래밍(Extreme Programming)에서 제창하는 코드 공동 소유는 간단히 말해 문제가 생기면 자신이 문제 코드를 작성한 사람이 아니더라도 성실하게 그리고 자발적으로 문제 해결에 나서는 정신이다.
보통 개발 조직에선 마틴 파울러가 말하는 강한 코드 소유권을 시행한다. 서로 간섭하거나 간섭 받지 않도록 업무를 모듈별로 나눠서 진행한다. 약한 코드 소유권과 달리 내가 작성한 코드를 남이 고쳐서 커밋하는 일은 있을 수 없다. 그에 반해 코드 공동 소유는 누구나 동일한 권한을 부여 받는다. 내가 작성한 코드를 내 허락 없이 다른 사람이 수정해도 무방하고, 그 반대도 마찬가지다. 말 그대로 코드는 다 함께 소유하게 되고, 어찌 보면 코드를 경제 기반으로 한 사회주의 시스템이라 할만하다.
처음 익스트림 프로그래밍을 접할 땐 코드 공동 소유가 어떤 파급효과를 가졌는지 몰랐지만, 경험이 쌓일수록 그 기저에 놓인 엄청난 자신감과 통찰력에 놀라게 된다. 이 정책이 실질적으로 시행되는 개발 조직이 몇이나 될지 생각해보면 어렴풋이나마 그 놀라움이 와 닿을 것이다.
코드 공동 소유에 대해 진정한 전문가의 의견을 듣고 싶다면, 마틴 파울러가 쓴 Code Ownership을 읽어보는 편이 좋다. 원문은 http://martinfowler.com/bliki/CodeOwnership.html에 있고 한글 번역판은 http://younghoe.info/11 에서 읽을 수 있다. 항상 그렇듯 번역하신 분께 감사의 인사를 드린다.
출처: 최재훈. 함께 일하다 보면.
코드 소유권(Code Ownership)
2006/소프트웨어 설계 2006/09/16 02:41
코드의 소유권(Code Ownership)은 다양한 형태로 나타난다. 이들은 크게 세 가지 범주로 나눠볼 수 있다:
- 강한 코드 소유권 코드 기반을 클래스, 함수나 파일 등의 모듈로 나눠서 개별 모듈을 특정 개발자에게 할당하는 방식. 개발자는 자기가 소유한 모듈에 대해서만 변경을 허용받는다. 다른 사람의 모듈에 변경이 필요한 경우는 이를 요청한다. 빨리 수정을 하게 하려면 패치를 작성해서 코드 소유자에게 보낼 수 있다.
- 약한 코드 소유권 은 모듈을 할당하기는 하지만 다른 사람의 코드도 수정할 수 있는 경우다. 모듈 소유자가 자신의 코드에 대한 책임을 지고 다른 사람에 의해 변경된 부분에 대해서도 모니터링해야 한다. 다른 사람의 코드에 많은 변경이 가해지는 경우라면 먼저 소유자에게 언급하는 것이 무례를 피하는 길이다.
- 코드의 공동 소유 모듈에 대한 개별 소유권은 없고 팀 전체가 코드기반을 공유하고, 누구나 어떤 코드라도 변경할 수 있는 경우다. 코드 소유권이 없는 것으로 간주할 수도 있지만, 공동 소유를 지지하는 이들은 개인이 아닌 팀이 소유한다는 사실을 강조한다.
나는 이들중에서 강한 코드 소유권을 좋아하지 않는다. 다른 사람의 코드를 변경할 일이 너무 잦기 때문이다. 담당자를 변경하도록 설득하고 이를 기다리는 일은 종종 많이 시간이 소요되어서 일정 지연이 발생한다. 특히 단순한 변경이 요구되는 상황이라면 문제가 더 커지게 만든다.
한 예로 public 메소드의 이름을 변경하는 경우를 보자. 대부분의 리팩토링 툴을 사용하면 public 메소드를 사용하는 코드에서 메소드 이름을 모두 찾아서 쉽게 변경하는 것이 가능하다. 그러나, 다른 사람이 소유한 모듈에 적용되면 소유권이 위배된다. Published Interface로 만들어야만 소유권 위반이 일어나지 않고, 그렇게 되면 변경에 따르는 부하가 증가된다.
더 문제가 되는 것은 개발자 본인의 코드에서 사용하는 다른 클래스에 변경을 가하고 싶을 때 이것이 바로 되지 않기 때문에, 변경후를 가정한 다른 코드를 임시로 작성해야 할 수도 있다. 물론, 추후 이들 코드의 일부는 반드시 찾아서 제거해야 하는 번거로움을 수반한다.
약한 코드 소유는 이런 문제를 상당히 줄일 수 있다. 자유롭게 수정할 수 있고, 코드 소유자는 지속적인 관리를 한다. 약한 코드 소유와 공동 소유중에 어떤 것을 선택하느냐는 팀이 어떻게 작업하느냐에 따라 달라진다. 개인적으로는 Extreme Programming에서 말하는 코드 공동 소유에 어울리는 작업방식을 선호한다.