https://martinfowler.com/bliki/CodeOwnership.html

제가 접한 코드 소유권에는 다양한 방식이 있습니다. 저는 이를 크게 세 가지로 분류했습니다.

• 강력한 코드 소유권은 코드 베이스를 모듈(클래스, 함수, 파일)로 나누고 각 모듈을 한 명의 개발자에게 할당합니다. 개발자는 자신이 소유한 모듈만 변경할 수 있습니다. 다른 사람의 모듈을 변경해야 하는 경우 모듈 소유자에게 문의하여 변경의 요청해야 합니다. 다른 모듈에 대한 패치를 작성하여 모듈 소유자에게 보내면 이 프로세스를 가속화 할 수 있습니다.
• 약한 코드 소유권은 모듈이 소유자에게 할당된다는 점에서 비슷하지만 개발자가 다른 사람이 소유한 모듈을 변경할 수 있다는 점에서 다릅니다. 모듈 소유자는 자신이 소유한 모듈에 대한 책임을 지고 다른 사람이 변경하는 것을 주시해야 합니다. 다른 사람의 모듈을 크게 변경하려면 먼저 모듈 소유자와 상의하는 것이 예의입니다.
• 공동 코드 소유권은 모듈의 개별 소유권 개념을 포기합니다. 코드 베이스는 팀 전체가 소유하며 누구나 어디서든 변경할 수 있습니다. 이를 코드 소유권이 없다고 생각할 수도 있지만, 개인이 아닌 팀의 소유권이라는 개념을 강조하는 쪽을 지지하는 사람들이 더 선호합니다.(집단적 코드 소유권이라는 용어는 익스트림 프로그래밍에서 유래했지만, 2판에서는 공유 코드라고 부릅니다.)

이 세 가지 중 제가 정말 싫어하는 것은 강력한 코드 소유권입니다. 내가 해야 할 일 때문에 다른 사람의 코드를 변경해야 하는 상황이 너무 많습니다. 변경을 설득하고 변경을 기다리는 데 시간이 너무 오래 걸려 지연과 더 큰 문제로 이어지는 경우가 많으며, 특히 변경이 단순한 경우라면 더욱 그렇습니다.

문제를 일으키는 간단한 변경의 좋은 예는 공유 메서드의 이름을 바꾸는 것입니다. 최신 리팩토링 도구는 광범위하게 사용되는 공유 메서드를 사용하여 이 작업을 안전하게 수행할 수 있습니다. 하지만 모듈 경계를 넘으면 코드 소유권을 침해하게 됩니다. 기본적으로 개발자 간의 모든 인터페이스를 게시된 인터페이스로 바꾸게 되며, 이에 수반되는 모든 오버헤드가 변경됩니다.

더 나쁜 경우는 구현 변경을 원하지만 충분히 빨리 얻을 수 없기 때문에 외부 코드의 복사본을 모듈에 만들고 코드 복사본을 호출하여 변경하는 것입니다. 물론 나중에 혼란을 정리하려고 합니다.

약한 코드 소유권은 이러한 종류의 문제를 완화하는 좋은 방법입니다. 사람들은 자유롭게 변경할 수 있고 코드 소유자는 상황을 계속 주시하기만 하면 됩니다.

약한 소유권과 집단적 소유권 사이의 선택은 팀의 사회적 역학 관계와 더 관련이 있습니다. 둘 다 똑같이 잘 작동하고 실패하는 것처럼 보입니다. 개인적으로 저는 특히 익스트림 프로그래밍의 맥락에서 집단적인 코드 소유권 팀의 역동성을 선호합니다.