대망의 3장 재사용성이다
3장의 재사용성의 첫 막을 여는 주제는 "반복하여 사용하지 말라"
실제로 이펙티브 코틀린 저자가 생각하는 프로그래밍의 가장 큰 규칙은 "프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다" 이다.
그리고 이걸
knowledge를 반복하여 사용하지 말라
고 표현하고 있다.
이를 실용주의 프로그래머라는 책에선 Don't Repeat Yourself라는 규칙을 DRY 규칙이라고 표현한다.
혹은 WET(We Enjoy Typing) 안티패턴, SSOT(Single Source of Truth)으로 알려지기도 한다.
그만큼 많은 개발자들이 같은 이야기를 하고 있다.
knowledge
프로그래밍에서 knowledge는 의도적인 정보를 뜻한다. 이와 같은 knowledge는 코드 또는 데이터로 표현할 수 있다.
또한, 기본 동작을 하게 아예 코드와 데이터를 부족하게 만들어서도 표현할 수 있다. 상속을 하는데도 불구하고 특정 메서드를 오버라이드하지 않게 강제한다는 것은, 해당 메서드가 슈퍼클래스와 동일하게 동작하기 원한다는 의미다.
이렇게 프로젝트를 진행할 때 정의한 모든 것이 knowledge이다. 이 종류는 굉장히 다양하다. 알고리즘의 작동 방식, UI 형태, 우리가 원하는 결과 등이 모두 의도적인 정보이며, knowledge이다.
이는 코드, 설정, 템플릿, 등으로 표현할 수 있다. 어떤 도구, 가상 머신, 다른 프로그램들에서 직접 또는 간접적으로 이해할 수 있는 정보라고 할 수 있다.
우리 프로그램에서 중요한 knowledge를 크게 두 가지 뽑는다면 다음과 같다.
1) 로직: 프로그램이 어떠한 식으로 동작하는 지와 프로그램이 어떻게 보이는지
2) 공통 알고리즘: 원하는 동작을 하기 위한 알고리즘
둘의 가장 큰 차이점은 시간에 따른 변화다. 비즈니스 로직은 시간이 지나면서 계속해서 변하지만, 공통 알고리즘은 한 번 정의된 이후에는 크게 변하지 않는다.
물론 공통 알고리즘을 최적화를 하거나 같은 카테고리의 더 빠른 알고리즘으로 바꿀 수도 있지만, 동작은 크게 변하지 않는다.
모든 것은 변화한다
프로그래밍에서 유일하게 유지되는 것은 변화하는 속성이라는 말이 있을 정도로 많은 프로젝트에서 변화가 일어난다.
기술 뿐만 아니라 언어도 빠른 속도로 변화한다. 몇 년전의 프로젝트가 있다면 그 프로젝트의 라이브러리, 아키텍처, 설계가 꽤 많이 변화했을 것이다.
변화는 우리가 예상하지 못한 곳에서 일어난다. UI 디자인과 기술 표준 등은 훨씬 빠르게 변화한다. 고객에 대한 이해 역시 그렇다.
- 회사가 사용자의 요구 또는 습관을 더 많이 알게 됐다.
- 디자인 표준이 변화했다.
- 플랫폼, 라이브러리, 도구 등이 변화해서 이에 대응해야 한다.
오늘 날 대부분의 프로젝트는 몇 달마다 요구 사항과 내부적인 구조를 계속해서 변경한다. 에를 들어 슬랙도 글리치라는 온라인 게임이었는데 소비자들이 이 게임의 커뮤니케이션 방식을 굉장히 마음에 들어했고 지금의 슬랙이 되었다.
모든 것은 변화하고, 우리는 이에 대비해야 한다. 변화할 때 가장 큰 적은 knowledge가 반복되어 있는 부분이다.
프로그램 내부에서 여러 부분에 반복되어 있는 코드를 변경하려면 어떻게 해야할까? 가장 간단하게는 반복된 부분을 모두 찾고, 모두 변경하면 된다. 하지만 이 과정 중에 실수가 아예 없을 수가 없다. 무엇보다 귀찮다!
knowledge의 반복은 프로젝트의 확장성(scalable)을 막고, 쉽게 깨지게(fragile) 만든다. 다행히도 개발자는 knowledge 반복을 줄일 수 있는 도구와 기능들을 활용할 수 있다. 대부분의 플랫폼에서는 사용자 정의 스타일 기능을 통해 한꺼번에 전체적인 뷰와 컴포넌트의 디자인을 변경할 수 있다.
여러 종류의 추상화를 표현할 수 있는 수많은 솔루션이 있으며, 이를 활용하며 반복을 줄일 수 있다.
언제 코드를 반복해도 될까?
반대로 추출을 통해 knowledge 반복을 줄이면 안 되는 상황을 살펴보자.
얼핏보면 Knowledge 반복처럼 보이지만, 실질적으로 다른 knowledge를 나타내므로 추출하면 안 되는 부분이다.
어떤 프로젝트에서 독립적인 2개의 안드로이드 애플리케이션을 만들고 있다고 해보자. 빌드 도구 설정이 비슷할 것이므로, 이를 추출해서 knowledge 반복을 줄일 수 있다고 생각할 수 있다.
하지만 두 애플리케이션은 독립적이므로 구성 변경이 일부 필요할 수도 있다. 한 애플리케이션 쪽의 구성만 변경해야 한다면 문제가 된다. 이처럼 신중하지 못한 추출은 변경이 어렵고 구성을 읽을 때도 더 어려울 수 있다.
두 코드가 같은 knowledge를 나타내는지, 다른 knowledge를 나타내는지는 "함께 변경될 가능성이 높은가? 따로 변경될 가능성이 높은가?"라는 질문으로 어느 정도 결정할 수 있다. 코드를 추출하는 이유는 변경을 쉽게 만들기 위함이므로, 이 질문은 가장 근본적인 질문이라고 할 수 있다.
잘못된 코드 추출로부터 우리를 보호할 수 있는 규칙도 있다.
바로 SRP(Single Responsibility Principle, SRP)
단일 책임 원칙
단일 책임 원칙은 클래스를 변경하는 이유는 단 한가지여야 한다라는 의미다
두 액터가 같은 클래스를 변경하는 일은 없어야한다고 표현했는데 여기서 액터는 변화를 만들어내는 존재다. 액터는 서로의 업무와 분야에 대해서 잘 모르는 개발자들로 비유된다. 이러한 개발자들이 같은 코드를 변경하는 것은 굉장히 위험한 일이다.
단일 책임 원칙은 2가지 사실을 알려준다
-
서로 다른 곳에서 사용하는 knowledge는 독립적으로 변경할 가능성이 많다. 따라서 비슷한 처리를 하더라도 완전히 다른 knowledge로 취급하는 것이 좋습니다.
-
다른 knowledge는 분리해 두는 것이 좋다. 그렇지 않으면 재사용해서는 안 되는 부분을 재사용하려는 유혹이 발생할 수 있다.
정리
모든 것은 변화한다. 따라서 공통 knowledge가 있다면, 이를 추출해서 이러한 변화에 대비해야 한다.
여러 요소에 비슷한 부분이 있는 경우, 변경이 필요할 때 실수가 발생할 수 있다. 이런 부분은 추출하는 것이 좋다. 추가적으로 의도하지 않은 수정을 피하려면 또는 다른 곳에서 조작하는 부분이 있다면 분리해서 사용하는 것이 좋다.
많은 개발자는 DRY라는 엄격하게 지키려고 비슷해 보이는 코드는 모두 추출하려는 경향이 있다. 극단적인 것은 언제나 좋지 않다. 항상 균형이 중요하다 어떤 것을 추출해야 할지 결정하기 어려울 수 있다.
정보 시스템 설계는 예술의 영역과 비슷하기 때문이다. 수많은 시간과 많은 연습이 필요하다!
느낀점
개발자라면 느낄 것이다. 유지보수할 때 (변화가 필요할때, 코드 수정이 필요할때) 공통화 되어 있는 부분을 수정하면 "아! 이래서 재사용성을 위해 따로 함수로 뺏구나"를 느끼는 적이 많고.
수정 요청이 들어온 피쳐를 다 하나하나 조사하며 수정하고 디벨롭에 머지하거나 다른 개발자의 작업이 머지되면서 하나씩 수정할 곳을 빼먹기도 한다.
실제로 이럴때마다 공통화는 중요하고 재사용성의 필요성이 절실하다. 그치만 또 재사용성이 될 줄 말고 빼놓았지만 아무도 쓰이지 않는 코드가 되기도 한다.
나는 이럴 때마다 체감을 하고 있으면서도 재사용성에 대해 조금 더 잘하고 싶은 욕심이 있었는데 마침 이펙티브 이 아이템에서 다루고 있어서 공감하고 이해하며 챕터를 읽었다.
마지막 정리에서 말한 거처럼 수많은 시간과 많은 연습이 필요하다니깐 앞으로 재활용/재사용의 왕이 되는 그날까지 정진해보겠다!
