[이펙티브 코틀린] 아이템 19. knowledge를 반복해 사용하지 마라

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

 

'실용주의 프로그래머' 책에선 'Don't Repeat Yourself'라는 규칙을 'DRY 규칙'으로 표현한다. WET 안티패턴이란 이름으로 아는 사람도 있을 것이다.

DRY는 또한 SSOT(Single Source of Truth)란 이름으로도 알려져 있다. 많은 개발자가 결국 같은 얘기를 하고 있는 것이다.

그런데 너무 자주 하는 이야기라 오용 또는 남용되고 있다. 이 규칙을 확실하게 적용하려면 이 이야기가 언제 왜 나오는지 이해해야 한다. 그리고 이걸 이해하려면 간단한 이론을 알아야 한다.

 

knowledge

 

프로그래밍에서 knowledge는 넓은 의미로 '의도적인 정보'를 뜻한다. 프로젝트를 진행할 때 정의한 모든 게 knowledge다. 알고리즘 작동 방식, UI의 형태, 내가 원하는 결과 등이 모두 '의도적인 정보'이며 knowledge다. knowledge는 코드, 설정, 템플릿 등으로 표현 가능하다.

이런 knowledge는 어떤 도구, 가상머신, 다른 프로그램들에서 직접 또는 간접적으로 이해할 수 있는 정보라고 할 수 있다.

필자의 프로그램에서 중요한 knowledge 2가지를 뽑는다면 아래와 같다.

 

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

 

둘의 가장 큰 차이점은 시간에 따른 변화다. 비즈니스 로직은 시간이 지나면서 계속 바뀌지만 공통 알고리즘은 한 번 정의된 후에는 크게 변하지 않는다.

공통 알고리즘을 최적화하거나 같은 카테고리의 더 빠른 알고리즘으로 바꿀 수도 있지만 동작은 크게 변하지 않는다.

 

모든 것은 변화한다

 

프로그래밍에서 유일하게 유지되는 건 '변화한다는 속성'이란 말이 있다. 유명한 애플리케이션 또는 웹 사이트 중에 변하지 않은 사이트를 알고 있는가? 안드로이드는 2008년에 배포됐고 코틀린의 첫 번째 stable 버전은 2016년에 배포됐다.

변화는 예상못한 곳에서 일어난다. UI 디자인과 기술 표준 등은 훨씬 빠르게 변화한다. 고객에 대한 이해도 매일 변화한다. 변화하는 이유를 몇 가지 적으면 아래와 같다.

 

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

 

오늘날 대부분 프로젝트는 몇 달마다 요구사항과 내부 구조를 계속 변경한다. 널리 쓰이는 많은 관리 시스템은 애자일하며 요구 사항의 변화를 맞추는 데 적합하다. 모든 것은 변화하고 이것에 대비해야 한다.

변화할 때 가장 큰 적은 knowledge가 반복돼 있는 부분이다. knowledge 반복은 프로젝트 확장성을 막고 쉽게 깨지게 만든다.

 

언제 코드를 반복해도 되는가?

 

두 코드가 같은 knowledge를 나타내는지 다른 knowledge를 나타내는지는 함께 변경될 가능성이 높은가? 따로 변경될 가능성이 높은가? 로 어느 정도 결정할 수 있다.

 

단일 책임 원칙

 

코드를 추출해도 되는지를 확인할 수 있는 원칙으로 단일 책임 원칙이 있다. 단일 책임 원칙이란 클래스를 바꾸는 이유는 한 가지여야 한다는 의미다.

서로 다른 곳에서 쓰는 knowledge는 독립적으로 변경할 가능성이 많다. 따라서 비슷한 처리를 하더라도 완전히 다른 knowledge로 취급하는 게 좋다.