Original site : http://www.extremeprogramming.org/rules/collective.html

코드 공동 소유는 모든 사람들이 프로젝트의 부분적인 새로운 아이디어로 기여할 수 있는 용기를 준다.  어느 개발자라도 코드의 어떤 라인에 기능 추가, 버그 수정, 리팩토링을 위해서 변경 할 수 있다.  어느 누구도 코딩에 대한 병목 현상이 될 수 없다. 

처음에는 이것이 이해하기 힘들다.  모든 팀원이 시스템 아키텍처에 대한 책임을 가진다는 것은 거의 믿지 못할 만 하다.  설계 부서장 혼자서 하는 것이 아니다. 

설계 부서장에게 질문을 하고 답을 얻는 것은 명백하게 틀린 것이다.  이것은 현재 당신이 리드하는 팀의 프로그래머들에게는 틀린것이 아니다.   허술한 시스템은 한사람의 마음을 잡을 수 없다.  다른 프로그래머들이 설계의 비전에 대한 동의없이 시스템을 변경하는 작업은 힘들다.  하지만, 당신이 이것을 깨달은 것과 관계 없이 설계는 이미 당신의 팀에게 배포되었다.  만일 모든 팀이 설계에 대한 책임을 이미 가지고 있다면, 그들이 가지고 있는 권한을 잘 수행하지 않을까?

이 방법으로 하는 업무는 각 개발자들이 개발한 코드에 대해서 유닛 테스트를 진행하는 것과 같다.  소스코드로 저장소에 릴리즈된 모든 코드는 유닛 테스트를 포함하고 있다.  추가된 코드, 고쳐진 버그들, 변경된 오래된 코드들은 자동화된 테스트에 의해서 처리 된다.  당신은 모든 코드 저장소에 대한 와치독을 하기 위한 테스트 수트에 의존할 수 있다.  그 전에 모든 코드들은 테스트 수트에서 100% 통과해서 릴리즈 되어야 한다.

한번에 어떤 클래스의 어떤 메소드를 변경하고, 필요에 의해서 코드를 저장소에 릴리즈 하는 것은 누구에게나 적용된다.  자주 통합작업이 수반 되었을 때, 개발자들은 클래스가 확장되거나 문제점이 고쳐졌는지를 인식할 수 있다.
공동 코드 소유에 대한 실천은 한 사람이 특정 클래스에 대한 책임을 가지고 있는 것 보다 확실할 수 있다.  특히 한 사람이 프로젝트를 떠났을 때에 잇점이 있다.