19장 - knowlege를 반복하여 사용하지 말라

Effective Kotlin의 저자가 생각하는 프로그래밍의 가장 큰 규칙

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

 

이를 Effective Kotlin에서는 "knowlege를 반복하여 사용하지 말라"라고 표현합니다.

 

실용주의 프로그래머라는 책에서는 "Don't Repeat Yourself"라는 규칙을 'DRY 규칙'이라 표현합니다.

 

 

모든 것은 변화한다.

프로젝트는 매우 빠르게 변화합니다.

기술뿐만 아니라 언어도 빠른 속도로 변화하기 때문입니다.

 

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

우발적 중복인 경우일 수 있습니다.

이미 클린 아키텍처를 읽었으며 책에서도 단일 책임 원칙을 언급하여 쉽게 이해할 수 있었습니다.

 

"두 액터가 같은 클래스를 변경하는 일은 없어야 합니다"

 

여기서 액터란 변화를 만들어내는 존재로 A: 관리자, B: 사용자로 생각해볼 수 있습니다.

이때 초기에는 A, B가 동일한 기능을 한다고 생각하여 하나의 코드로 통합하여 관리할 수 있습니다.

하지만 시간이 지남에 따라 A와 B의 요구사항이 달라지고 결국에는 분리되어야 합니다.

 

이렇지 않으면 A의 수정이 B에 영향을 미치고, B의 수정이 A에 영향을 미칩니다.

 

 

코드로 예를 들어보겠습니다.

다음과 같은 정책이 내려왔습니다.

A 관리자는 "hello"라는 구문을 반환한다.

B 사용자는 "hello"라는 구문을 반환한다.

 

이제 개발자는 이런 생각을 합니다.

 

중복되는데 하나의 메서드로 추출하여 만들자

fun main() {
    val userSay = commonSay()
    val managerSay = commonSay()
    println(userSay)
    println(managerSay)
}

fun commonSay() = "hello"

 

이제 정책이 바뀌었습니다.

A 관리자는 "hi"라는 구문을 반환해야 합니다.

 

개발자는 코드를  수정해야 합니다.

하지만 hello를 hi로 바꾸게 되면 user도 영향을 받게 됩니다.

 

이를 미리 인지하지 못했다면 장애로 이어질 가능성도 있습니다.

fun main() {
    val userSay = userSay()
    val managerSay = managerSay()
    println(userSay)
    println(managerSay)
}

fun userSay()= "hello"
fun managerSay() = "hi"

 

이제 정책에 따라 변경이 되며 두 가지 함수로 분리되었으며 각각의 함수는 액터의 요구에 따라 다르게 변화하게 됩니다.

이처럼 처음에는 중복으로 보였지만 사실은 액터의 관점으로 바라보고 중복을 허용해야 합니다.