아이템 19 - knowledge 를 반복하여 사용하지 말라

• 저자가 생각하는 프로그램의 가장 큰 규칙은 다음과 같다

프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다.

 

• 실용주의 프로그래머 라는 책에서는 DRY 규칙(Don't Repeat Yourself)으로 표현하고 있다.
• 프로그래밍에서 knowledge 는 넓은 의미로 의도적인 정보 를 뜻합니다.
• 프로그램에서 중요한 knowledge 를 크게 두 가지 뽑는다면, 다음과 같다
  • 로직: 프로그램이 어떠한 식으로 동작하는지와 프로그램이 어떻게 보이는지
  • 공통 알고리즘: 원하는 동작을 하기 위한 알고리즘
• 둘의 가장 큰 차이점은 시간에 따른 변화 이다.
• 비즈니스 로직은 시간이 지나면서 계속해서 변하지만, 공통 알고리즘은 한 번 정의된 이후에는 크게 변하지 않습니다.

 

모든것은 변화한다

• 프로그래밍에서 유일하게 유지되는 것은 변화한다는 속성 이라는 말이 있다
• 많은 프로젝트들이 오랜기간 유지되지만 변화되지 않은것은 없다.
• 변화는 우리가 예상하지 못한 곳에서 일어납니다. UI 디자인과 기술 표준 등은 훨씬 빠르게 변화합니다.

 

언제 코드를 반복해도 될까?

• 추출을 통해 knowledge 반복을 줄이면 안 되는 상황을 살펴보자
• 결론부터 말하면 엇핏보면 knowledge 반복처럼 보이지만, 실질적으로 다른 knowledge 를 나타내므로 추출하면 안 되는 부분이다.
  • 예를들자면 독립적인 2개의 안드로이드 애플리케이션을 만들때, 빌드 도구 설정등이 비슷하여 이를 추출하여 knowledge 반복을 줄일 수 있다고 생각할 수 있지만, 두 애플리케이션은 독립적이므로 구성 변경이 한쪽만 구성을 변경해야 하는 등의 문제가 발생할 수 있다.
• 두 코드가 knowledge 를 나타내는지, 다른 knowledge 를 나타내는지는 "함께 변경될 가능성이 높은가?" 라는 질문으로 어느 정도 결정할 수 있다.
• 한 가지 유용한 휴리스틱으로, 비즈니스 규칙이 다른곳(source)에서 왔는지 확인하는 방법이 있습니다. 다른 곳에서 왔다면, 독립적으로 변경될 가능성이 높습니다.
• 잘못된 추출로부터 우리를 보호할 수 있는 규칙도 있다. 바로 단일 책임 원칙(SRP) 이다

 

단일 책임 원칙(Single Responsibility principle)

• https://jeong0427.tistory.com/13 참고
• 두 액터(actor)가 같은 클래스를 변경하는 일은 없어야 한다.
  • 액터는 서로의 업무와 분야에 대해서 잘 모르는 개발자들로 비유됩니다.
• private 함수는 두 가지 이상의 역할을 하지 않기 때문에, 이러한 관습에 따라서 다른 책임을 갖고 있을 거라는 것을 예측 못할 수 있다.
• 이러한 문제를 방지하려면, 처음부터 책임에 따라서 다른 클래스로 구분해서 만들어야 한다.
• 또는 확장 함수를 활용하면, 두 함수는 해당 클래스 아래에 두면서도, 각각의 다른 액터가 관리하는 서로 다른 모듈 파일에 배치할 수도 있을 것이다.
• 두 결과를 계산하는 추가적인 함수를 만들면 어떨까요? => 할 수 있다 그렇지만 헬퍼 함수는 private 함수로 마늘지 않고 다음과 같이 만드는 것이 일반적이다
  • 두 부서에서 모두 사용하는 일반적인 public 함수로 헬퍼 함수를 만든다. 공통 부분은 두 부서에서 모두 사용하므로, 이를 함부로 수정해서는 안되게 규액을 정한다.
  • 헬퍼 함수를 각각의 부서 모듈에 따라 2개 만든다.
• 단일 책임 원칙은 우리에게 두 가지 사실을 알려 준다.
  • 서로 다른 곳에서 사용하는 knowledge 는 독립적으로 변경할 가능성이 많다. 따라서 비슷한 처리를 하더라도, 완전히 다른 knowledge 로 취급하는 것이 좋다.
  • 다른 knowledge 는 분리해 두는 것이 좋다. 그렇지 않으면, 재사용해서는 안되는 부분을 재사용하려는 유혹이 발생할 수 있다.

 

---

 

정리

• 모든 것은 변화한다.
• 따라서 공통 knowledge 가 있다면, 이를 추출해서 이러한 변화에 대비해야 한다.
• 극단적인 것은 언제나 좋지 않습니다.항상 균형이 중요합니다.

 

생각

• 클래스를 같이 사용하되, 확장함수 아이디어는 생각을 안해봤는데 괜찮을거 같다. 각 모듈별로 관리할때 좋을거 같다.
• 책에 있는 말도 맞는거 같다. 극단적인거는 좋치 않은거 같고, 클래스의 단일책임보다는 개인적으로는 함수의 단일 책임이 더 땡긴다.