TIL

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

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

• 다른 말로 DRY(Don’t Repeat Yourself) 규칙이라고도 한다.

Knowledge

• 프로그래밍에서 knowledge는 ‘의도적인 정보’를 뜻한다.
  • 프로젝트에선 정의한 모든 것이 knowledge이다.
• 프로젝트에서 중요한 knowledge를 2개 뽑는다면 다음과 같다.
  • 로직(logic): 프로그램이 어떻게 동작하는지와 어떻게 보이는지
  • 공통 알고리즘(common algorithm): 원하는 동작을 하기 위한 알고리즘
• 로직과 알고리즘의 큰 차이는 시간에 따른 변화이다.
  • 비즈니스 로직은 시간이 지남에 따라 변한다.
  • 공통 알고리즘은 정의된 이후 크게 변하지 않는다.

모든 것은 변화한다

• 프로그래밍에서 유일하게 유지되는 것은 ‘변화한다는 속성’이다.
• 변화는 우리가 예상하지 못한 곳에서 일어나는데 대표적인 이유는 다음과 같다.
  • 사용자의 요구 또는 습관을 더 많이 알게 되었다.
  • 디자인 표준이 변화했다.
  • 플랫폼, 라이브러리, 도구 등이 변화해서 이에 대응해야 한다.
• 모든 것이 변화하고 변화할 때 가장 큰 적은 knowledge가 반복되어 있는 부분이다.
  • 프로그램 내에 반복된 부분을 모두 변경하려면 상당한 비용이 든다.
• knowledge의 반복은 프로젝트의 확장성을 막고 쉽게 깨지게 만든다.
• 변화에 대응하려면 적절한 추상화가 필요하고 이와 관련한 많은 도구들이 존재한다.
  • ex) SQL 변화에 대응하기 위한 ORM

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

• knowledge 반복처럼 보이지만 실질적으로 다른 knowledge인 경우가 있다.
• 공통이라 생각해서 추출했다가 한 쪽만 독립적을 변화되는 상황이 그 예다.
• 다른 knowledge인지 판단하려면 ‘함께 변경될 가능성이 높은가’를 따져봐야 한다.
• 단일 책임 원칙을 통해 잘못된 코드 추출로부터 보호할 수 있기도 하다.

단일 책임 원칙

• 단일 책임 원칙 - 클래스를 변경하는 이유는 단 한 가지여야 한다.
• 클린 아키텍처에선 ‘두 액터가 같은 클래스를 변경하는 일은 없어야 한다’라고 표현한다.
  • 액터는 서로의 업무와 분야에 대해 잘 모르는 개발자들로 비유된다.
  • 서로 다른 액터가 같은 클래스 파일에서 서로 다른 요구사항을 만족시키기 위해 같은 공통 private 함수를 건드는 경우 서로의 요구사항이 상충되는 상황이 발생할 가능성이 높다.
  • 아래 Student 클래스 예시에서 한쪽 부서가 자신의 프로퍼티를 다루기 claculatePointsFromPassedCourses를 수정하면 다른쪽 프로퍼티가 예상치 못한 동작을 할 가능성이 높다.

class Student {
	// ...
	
	fun isPassing(): Boolean = // 인증 관련 부서가 사용
		calculatePointsFromPassedCourses() > 15
		
	fun qualifiesForScholarship(): Boolean = // 장학금 관련 부서에서 사용
		claculatePointsFromPassedCourses() > 30
		
	private fun claculatePointsFromPassedCourses(): Int { // 각 프로퍼티가 사용하는 공통 로직
		// ...
	}
}

• 따라서 처음부터 책임에 따라 다른 클래스로 구분해서 만들어야 한다.
  • Student 클래스의 경우 각각 다른 모듈에 아래처럼 확장 함수로 만들 수도 있을 것이다.

// accreditations 모듈
fun Student.qualifiesForScholarship(): Boolean { 
	/*...*/
}

// scholarship 모듈
fun Student.calculatePointsFromPassedCourses(): Boolean { 
	/*...*/
}

• 단일 책임 원칙은 두 가지 사실을 알려준다.
  • 서로 다른 곳에서 사용하는 knowledge는 독립적으로 변경할 가능성이 많다.
    • 비슷해 보여도 완전 다른 knowledge로 취급해야 한다.
  • 다른 knowledge는 분리해 두는 것이 좋다.
    • 재사용해서는 안 되는 부분을 재사용하려는 유혹이 발생할 수 있다.