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

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

이를 “knowledge를 반복하여 사용하지 말라” 라고 표현하기도 하고 Don’t Repeat Yourself인 DRY 규칙으로 표현하기도 한다.

그런데 이를 잘못 이해하는 경우가 있다.

Knowledge

프로젝트를 진행할 때 정의한 모든 것이 Knowledge(=의도적인 정보)이다.

알고리즘의 동작 방식, UI 형태, 우리가 원하는 결과등이 모두 의도적인 정보이다.

가장 중요한 두 가지 Knowledge를 뽑으면 다음과 같다.

• 로직: 프로그램이 어떻게 동작하는지, 어떻게 보이는지
• 공통 알고리즘: 원하는 동작을 하기 위한 알고리즘

둘의 차이점은 시간에 따른 변화이다. 비즈니스 로직은 시간이 지나면서 같이 변하지만 공통 알고리즘은 쉽게 변하지 않는다.

모든 것은 변화한다

프로그램에서 유일하게 유지되는 것은 변화한다는 속성이다.

그러므로 우리가 알고 있는 프로젝트의 Knowledge 또한 아래와 같은 이유로 변화한다.

• 회사가 사용자의 요구, 습관을 더 많이 알게 되었다.
• 디자인 표준이 변화했다.
• 플랫폼, 라이브러리, 도구 등이 변화해서 대응한다.

모든 것은 변화하고, 우리는 이에 대비해야 한다. 그러므로 변화할 때 가장 큰 적은 Knowledge가 반복되어 있는 부분이다.

반복되어 있는 부분을 모두 찾아서 동일하게 수정해야하고 이러한 과정에서 실수가 나올수 있다. 그리고 약간 다른 방식으로 이미 변경되어 있다면 더 골치 아파진다.

따라서 Knowledge의 반복은 프로젝트의 확장성을 막고, 쉽게 깨지게 만든다.

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

반대로 추출을 통해 Knowledge 반복을 줄이면 안 되는 상황이 있다.

Knowledge의 반복처럼 보이지만, 실제로 서로 다른 Knowledge를 나타내는 경우이다.

어떤 프로젝트에서 독립적인 2개의 웹 애플리케이션을 만들고 있는데 빌드 도구 설정이 비슷할 것이라 생각하여 이를 추출하여 Knowledge의 반복을 줄이려고 할 수 있다.

하지만 두 애플리케이션은 독립적이므로 개별 구성이 필요한 경우 추출한 Knowledge가 상황을 어렵게 만들 수 있다.

따라서 신중하지 못한 추출은 변경을 더 어렵게 만들 수 있음을 기억하자.

중복된 부분이 같은 Knowledge를 나타내는지 다른지는 “함께 변경될 가능성이 높은가? 따로 변경될 가능성이 높은가?” 라는 질문이 도움이 된다. 중복된 부분을 추출하는 이유는 변경을 쉽게 하기 위함이기 때문에 근본적인 질문이 가장 도움이 된다.

또한 비즈니스 규칙이 다른 source에서 왔는지를 확인하는 것은 독립적으로 변경될 가능성을 판단하는데 도움이 된다.

단일 책임 원칙

단일 책임 원칙은 “클래스를 변경하는 이유는 단 한 가지여야 한다.” 라는 의미이다. 약간의 비유를 들어 설명하면 ”서로 다른 두개의 변화를 만들어내는 존재(=액터)가 같은 클래스를 변경하는 일은 없어야 한다.”고 표현하다.

서로 다른 두개의 변화를 만들어 내는 존재가 하나의 클래스를 의존하고 있다면 하나의 클래스가 아닌 개별 클래스로 분리하도록 하자.

그리고 다음과 같은 규칙을 지킨다.

• 액터가 사용하는 헬퍼 함수는 private이 아닌 public으로 만들어 함부로 수정하지 못하도록 규약하라.
• 헬퍼 함수는 액터별로 만들도록 하라.

단일 책임 우너칙은 우리에게 두 가지 사실을 알려준다.

• 서로 다른 곳에서 사용하는 Knowledge는 독립적으로 변경할 가능성이 많다. 따라서 비슷한 처리를 하더라도 완전히 다른 Knowledge로 취급하는 것이 좋다.
• 다른 Knowledge는 분리해 두는 것이 좋다. 재사용하면 안되는 부분을 재사용하려는 유혹이 생긴다.