[이펙티브 코틀린] Item19. knowledge를 반복하여 사용하지 말라

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

 

 

필자가 생각하는 프로그래밍의 가장 큰 규칙이며, 이를 'knowledge를 반복하여 사용하지 말라'라는 규칙으로 표현하고 있습니다.

knowledge는 '의도적인 정보'를 뜻하며, 코드 또는 데이터로 표현할 수 있습니다.

또한, knowledge는 알고리즘의 작동 방식, UI의 형태, 원하는 결과 등 모든 의도적인 정보를 말합니다.

프로그램에서 중요한 knowledge를 크게 두 가지 뽑는다면, 다음과 같습니다.

 

1. 로직(logic): 프로그램이 어떠한 식으로 동작하는지와 프로그램이 어떻게 보이는지
2. 공통 알고리즘(common algorithm): 원하는 동작을 하기 위한 알고리즘

둘의 가장 큰 차이점은 시간에 따른 변화입니다.

비즈니스 로직은 시간이 지나면서 계속해서 변하지만, 공통 알고리즘은 한 번 정의된 이후에는 크게 변하지 않습니다.

 

 

 

모든 것은 변화한다.

 

프로그래밍에서 유일하게 유지되는 것은 '변화한다는 속성'이라는 말이 있습니다.

변화는 우리가 예상하지 못한 곳에서 일어나며, UI 디자인과 기술 표준, 사용자의 요구 등은 훨씬 빠르게 변화합니다.

이처럼 우리 프로젝트의 knowledge도 계속해서 변화합니다.

모든 것은 변화하고, 우리는 이에 대비해야 합니다.

knowledge가 반복되어 있는 부분은 변화할 때 가장 큰 걸림돌이 됩니다.

knowledge의 반복은 프로젝트의 확장성(scalable)을 막고 쉽게 깨지게(fragile)만듭니다.

이러한 위험은 추상화를 통해 줄일 수 있으며, '아이템27: 변화로부터 코드 보호하려면 추상화를 사용하라'에서 살펴보겠습니다.

 

 

 

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

 

반대로 추출을 통해 knowledge 반복을 줄이면 안 되는 상황을 살펴보겠습니다.

knowledge 반복처럼 보이지만 실질적으로 다른 knowledge를 나타낸다면, 추출하면 안 되는 부분입니다.

신중하지 못한 추출은 변경을 더 어렵게 만들어 버리며, 구성을 읽을 때도 더 어려울 수 있습니다.

두 코드가 같은 knowledge를 나타내는지, 다른 knowledge를 나타내는지는

"함께 변경될 가능성이 높은가?", "따로 변경될 가능성이 높은가?"라는 질문으로 어느 정도 결정할 수 있습니다.

 

 

 

단일 책임 원칙

 

잘못된 코드 추출로부터 보호할 수 있는 규칙이 바로 단일 책임 원칙(Single Responsibility Principle, SRP)입니다.

코드를 추출해도 되는지를 확인할 수 있는 원칙으로, SOLID 원칙 중 하나인 '클래스를 변경하는 이유는 단 한 가지여야 한다'입니다.

로버트 C. 마틴은 '두 액터(actor)가 같은 클래스를 변경하는 일은 없어야 한다'라고 표현했는데, 여기서 액터는 변화를 만들어내는 존재를 의미하며, 서로의 업무와 분와야 대해서 잘 모르는 개발자들로 비유됩니다.

이렇듯 개발자들이 같은 코드를 변경하는 것은 굉장히 위험한 일입니다.

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

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

 

 

---

정리

 

• 모든 것은 변화한다. 따라서 공통 knowledge가 있다면, 이를 추출해서 변화에 대비해야 한다.
• 여러 요소에 비슷한 부분이 있는 경우, 변경이 필요할 때 실수가 발생할 수 있는데 이러한 부분은 추출하는 것이 좋다.
• 의도하지 않은 수정을 피하려면 또는 다른 곳에서 조작하는 부분이 있다면, 분리해서 사용하는 것이 좋다.
• 개발자는 ‘Don’t Repeat Yourself’라는 문장을 엄격하게 지키려고 비슷해 보이는 코드는 모두 추출하려는 경향이 있는데 극단적인 것은 언제나 좋지 않다.
• 정보 시스템 설계는 예술의 영역과 비슷하기 때문에 수많은 시간과 연습이 필요하다.