마틴 파울러 - 코드 오너십

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

Strong code ownership

• 강력한 코드 오너십은 코드 베이스를 모듈(클래스, 함수, 파일)로 분할하고 각 모듈을 하나의 개발자에게 할당한다.
• 개발자는 소유한 모듈에만 변경을 가할 수 있다. 다른 사람의 모듈에 대한 변경이 필요한 경우 해당 모듈 소유자에게 연락하여 변경을 요청해야 한다.
• 이 프로세스를 가속화하려면 다른 모듈을 위해 패치를 작성하고 해당 모듈 소유자에게 보내는 방식을 사용할 수 있다.

Weak code ownership

• 약한 코드 소유는 모듈이 소유자에게 할당되는 것은 유사하지만, 다른 사람이 소유한 모듈을 변경할 수 있다는 점에서 다르다.
• 모듈 소유자는 소유한 모듈에 대한 책임을 져야하며 다른 사람이 가한 변경 사항을 주시해야 한다.
• 다른 사람의 모듈에 대한 중요한 변경을 하려면 먼저 모듈 소유자와 상의하는 것이 예의이다.

Collective code ownership

• 집단 코드 소유는 모듈의 개별 소유에 대한 어떠한 개념도 포기한다. 코드 베이스는 팀 전체에 의해 소유되며 누구든지 어디에서든지 변경을 가할 수 있다.
• 이것은 코드 소유권이 없다고 생각할 수 있지만, 오히려 개인이 아닌 팀에 의한 소유 개념에 중점을 둔 것이라고 주장하는 사람들도 있다.
• (집단 코드 소유권이라는 용어는 익스트림 프로그래밍에서 나온 것이지만, 두 번째 판에서는 이를 공유 코드로 부르고 있다.)

마틴파울러 의견

이 세 가지 중에서 나는 강력한 코드 소유를 정말 좋아하지 않는다. 필요한 작업 중에는 다른 사람의 코드를 변경해야 하는 상황이 너무 많다. 변경을 요청하고 변경을 기다리는 것은 종종 지연과 더 심각한 문제로 이어지기 때문에 문제가 발생한다. 특히 변경이 간단한 경우에는 더욱 짜증난다.

문제를 일으키는 간단한 변경의 좋은 예는 공개 메서드의 이름을 변경하는 것이다. 현대적인 리팩터링 도구는 많이 사용되는 공개 메서드를 안전하게 변경할 수 있다. 그러나 모듈 경계를 넘어가면 이는 코드 소유를 위반한다. 본질적으로 모든 개발자 간의 인터페이스를 PublishedInterfaces로 변환한 것이다. 변경에 따른 모든 부가적인 비용이 발생한다.

더 나쁜 경우는 구현 변경이 필요하지만 빨리 얻을 수 없기 때문에 외부 코드의 복사본을 모듈로 만들어 변경을 가하는 것이다. 물론 나중에 이 난잡함을 정리하려고 할 것이다.

약한 코드 소유는 이러한 종류의 문제를 완화하는 좋은 방법이다. 사람들은 자유롭게 변경할 수 있으며, 코드 소유자는 그냥 상황을 주시하면 된다.

약한 소유와 집단 소유 중에서 선택은 팀의 사회적 동력과 더 관련이 있다. 두 가지 방식 모두 효과적으로 동작하거나 실패하는 것 같다. 개인적으로는 익스트림 프로그래밍의 맥락에서 집단 코드 소유 팀의 동력을 선호한다.

개인 의견

• 강력한 코드 오너십은 MSA 구조에서 모듈 별 개발자(그룹)이 나뉘어져 있는 경우에는 유용 한 것 같다.
  • 최소한 repository나, 멀티 모듈 구조에서 개별 모듈로 나뉘어져 있어야 의미가 있을 것 같다.
  • 그 이하(패키지 이하)로 오너십을 나누는 것은 득보다 실이 더 큰 것 같다.
• Collective code ownership에서, @author를 적는 것은 의미가 없는 것 같다.
  • 많은 개발자 또는 팀에서 관습적으로 @author를 적는데, 코드 오너십을 어떤 유형으로 가져가고 있는지 다시 생각해 볼 필요가 있다.
  • 어차피 집단 코드 소유 구조라면 @author는 전혀 참고가 안되고, git history로 수정 이력을 보게 된다.
• 나는 집단 소유 코드와 약한 코드 소유 중 약한 코드 소유를 더 좋아한다.
  • 팀원 개개인의 코드 스타일과 실력이 더 잘 드러나기 때문이다. ‘왜 이 부분을 이렇게 했는지?’ 물어보기 좋다. 코드 설계 시 ‘타인의 레거시로 인해 어쩔 수 없이’라는 부분을 배제 할 수 있기 때문이다.
  • 집단 코드 소유는 코드 오너십이 지나치게 희미해져서, 꼭 필요한 유지보수가 아니면 아무도 코드를 개선하려 하지 않는 최악의 상황으로 빠질 가능성이 있다.