knowledge를 반복하여 사용하지 말라 #
" 프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다. "
규모가 작은 것들(예를 들어, 함수, 단일 클래스 등)은 재사용할 수 있게 잘 추출해서 정리하고 있다. 다만, 최근에 규모가 큰 것(패키지 단위)에 대해서 복붙한 경험이 있다. 공통 모듈로 분리할 수 있었지만 깊이 있게 고민하지 않고 넘어갔다. :thinking:
DRY, WET 안티패턴(We Enjoy Typing, Waste Everyone’s Time or Write Everthing Twice), SSOT(Single Source of Truth)
WET 패턴, 흥미롭다.
언제 코드를 반복해도 될까? #
어떤 프로젝트에서 독립적인 2개의 애플리케이션을 만들고 있다고 가정해보자. 빌드 설정이 비슷할 것이므로, 이를 추출해서 공통으로 작성할 수도 있겠다.
하지만 두 애플리케이션은 독립적이므로 각각 필요한 변경 사항이 필요할 수 있다. (e.g., 한 애플리케이션의 구성만 변경해야 할 때)
이처럼 신중하지 못한 추출은 변경을 더 어렵게 만들어 버린다.
두 코드가 같은 knowledge 를 나타내는지, 다른 knowledge 를 나타내는지는 “함께 변경될 가능성이 높은가? 따로 변경될 가능성이 높은가?”(= 해당 코드의 라이프사이클이 같은가?) 를 고민해보면 좋겠다.
서로 다른 곳(부서, 사용처)에서 사용하는 knowledge는 독립적으로 변경할 가능성이 많다. 따라서 비슷한 처리를 하더라도 완전히 다른 knowlede 로 취급하는 것이 좋다. (위 내용은 실제로 경험한 적이 있어서 공감된다.)
다른 knowledge는 분리해두는 것이 좋다. 그렇지 않으면 (공통으로 사용해서는 안되는 코드를)공통으로 만들어 재사용하려는 유혹이 발생할 수 있다. (공감된다.)
단일 책임 원칙 #
" 클래스를 변경하는 이유는 단 한가지여야 한다. “
:star: :star: :star: “단일 책임을 가져야 한다.”
= “클래스를 변경하는 이유는 한가지여야 한다.”
” 두 액터(actor, 변화를 만들어 내는 존재)가 같은 클래스를 변경하는 일은 없어야 한다. “