프로그래밍 언어의 핵심 특징이라고 할 수 있는 재사용성(resuability)은 정렬 알고리즘과 같은 부분을 한번 만들어 놓으면, 필요할 때 이를 활용할 수 있다는 것이다.
print 함수를 약간만 변경해도 프로그램에 수많은 문제가 발생할 수 있듯, 재사용성은 힘이 있는 만큼 굉장히 위험할 수 있다.
“프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다.” 이는 단순한 휴리스틱이지만 잘 들어맞는다.
DRY(Don’t Repeat Yourself)
실용주의 프로그래머라는 책에서도 반복에 대한 부분을 DRY 규칙이라고 표현하고 있다.
추가로 아래와 같은 이름으로도 알려져 있다.
- SSOT(Single Source of Truth)
- WET(We Enjoy Typing, Write Everything Twice)
이는 굉장히 많은 개발자가 비슷한 문제를 겪고, 같은 이야기를 하고 있다는 것이다.
knowledge
프로젝트를 진행할 때 정의한 모든것이 knowledge가 될 수 있다.
프로그램에서 중요한 knowledge를 뽑는다면 다음과 같다.
- 로직(logic): 프로그램이 어떠한 식으로 동작하는지, 프로그램이 어떻게 보이는지
- 공통 알고리즘(common algorithm): 원하는 동작을 하기 위한 알고리즘
위 둘의 큰 차이점은 시간에 따른 변화이다.
비즈니스 로직은 시간이 지나면서 계속 변하지만, 공통 알고리즘은 크게 변하지 않는다.
모든 것은 변화한다.
프로그래밍에서 유일하게 유지되는 것은 변화한다는 속성이라는 말이 있다.
우리 프로젝트의 knowledge가 변화하는 이유는 다음과 같다.
- 회사가 사용자의 요구 또는 습관을 더 많이 알게 되었다.
- 디자인 표준이 변화했다.
- 플랫폼, 라이브러리, 도구 등이 변화해서 이에 대응해야 한다.
knowledge의 반복은 확장성을 막고 쉽게 깨지게 만든다. 개발자는 knowledge 반복을 줄일 수 있는 여러 도구나 기능을 활용할 수 있다.(Hibernate와 같은 ORM, 추상화 등)
언제 코드를 반복해도 될까?
반대로 아래와 같이 knowledge 반복을 줄이면 안되는 상황도 있다.
독립적인 2개의 안드로이드 애플리케이션, 빌드 도구 설정이 유사하므로 추출해 knowledge 반복을 줄이는 경우
처음에는 설정이 유사하지만 두 애플리케이션은 독립적이며 이후에 구성 변경이 필요할 수 있다. 이처럼 신중하지 못한 추출은 변경을 더 어렵게 만든다.
함께 변경될 가능성이 높은가? 따로 변경될 가능성이 높은가를 질문으로 두 코드가 같은 knowledge를 나타내는지 어느정도 결정할 수 있다.
이외에 유용한 휴리스틱으로, 비즈니스 규칙이 다른곳에서 왔는지를 체크한다. 다른 곳에서 왔다면 독립적으로 변경될 가능성이 높다.
단일 책임의 원칙(Single Responsibility Principle, SRP)
단일 책임의 원칙은 잘못된 코드 추출로부터 우리를 보호할 수 있는 규칙이다.
두 액터(actor)가 같은 클래스를 변경하는 일은 없어야 한다.
액터란 변화를 만들어 내는 존재이며 서로의 업무와 분야에 대해 잘 모르는 개발자들로 비유된다.
위와 같이 Student라는 클래스를 여러 부서에서 활용한다면 각각의 부서의 목적에 따라 수정하면서 오동작을 일으킬 수 있다.
- 서로 다른 곳에서 사용하는 knowledge는 독립적으로 변경할 가능성이 많다. 따라서 비슷한 처리를 하더라도 완전히 다른 knowledge로 취급하는 것이 좋다.
- 다른 knowledge는 분리해 두는 것이 좋다. 그렇지 않으면 재사용해서는 안되는 부분을 재사용하려는 유혹이 발생할 수 있다.
정리
- 모든 것은 변화하므로 공통 knowledge가 있다면 추출해서 이러한 변화에 대비해야 한다.
- DRY를 엄격하게 지키려고 비슷해 보이는 코드는 모두 추출하려는 경향이 있는데, 극단적인 것은 언제나 좋지 않다.
Reference
- 이펙티브 코틀린 - 프로그래밍 인사이트, 마르친 모스칼라 지음, 윤인성 옮김
개인적인 기록을 위해 작성된 글이라 잘못된 내용이 있을 수 있습니다.
오류가 있다면 댓글을 남겨주세요.