[Effective Kotlin] 아이템 19 : knowledge를 반복하여 사용하지 말라

복사하게 하지말고 이해시키는 블로그가 되자·2022년 7월 5일

이펙티브 코틀린 3장 재사용성

목록 보기

1/7

프로그래밍에서 가장 중요한것중 하나는 재사용성 이다.
우리가 System.out.print를 구현한다고 생각해보자.
JNI의 C를 통해 운영체제와 통신하는 부분을 구현해야하는데 우린 이것을 몰라도 언제든 System.out.print를 사용할수 있다.

이와 마찬가지로 Iterable.sorted 또한, 정렬 알고리즘을 공부하지않아도 알아서 졍렬된다는것을 알수 있다.
이처럼 함수를 만들어놓으면 언제든 사용할 수 있는것을 재사용성할수 있는데, 재사용성을 고려해서 함수를 만드는것은 생각보다 어렵고 다양한 오류를 발생할수 있다.

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

DRY(Don't Repeat YourSelf)규칙은 어디서든 많이 들어봤을 것이다.

프로그래밍에서의 중요한 정보를 뽑자면 다음과 같다.

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

이해를 쉽게 하자면, 갤러리를 만든 앱이 있다.

안드로이드 초창기 시절, 처음에는 자바로 구현을 했었다.
하지만 코틀린이 나오면서 프로그램을 코틀린으로 리펙토링 하였다.
그리고 새로운 기술이 나오면서, 갤러리에 이미지를 로딩할때 코일이란 라이브러리를 사용하였다.
기술, 프레임워크, 라이브러리가 바뀌었지만 어떤 목적을 위해 이 앱을 만들었는가는 변하지 않았다.

하지만 큰 문제점이 있다.

다양한 기술에 따라 프로젝트의 리펙토링을 진행하면서 반복되는 코드를 발견한것이다.
이러한곳을 다 변경할 수 있자만, 그러기엔 시간이 너무많이가고 변경점이 일어날때마다 항상 모든것을 변경 해야한다.
심지어 만약 계속 변경을 반복하다가 놓치기라도 한다면 바로 오류로 이어진다.

그렇다면 언제 코드를 반복해도 되는가?

fun `설정이 들어 있는 함수`{
// 설정을 세팅 해줌
}

만약 두개의 어플리케이션이 설정이 같아서 하나의 함수로 세팅하고 있다고 생각해보자.

그러다 어느날 어플리케이샨 따로 설정값을 가지게 된다면?

코드를 추출 하기전에 함께 변경될 가능성이 높은가? 을 생각해보고 분리하는것이 좋다.

또한 잘못된 코드추출로 우리를 보호할수 있는 규칙이 있는데 바로 단일 책임 원칙이다.

단일 책임 원칙

직장에서 신입이 들어왔다고 생각해보자.

"두 액터(변화를 만들어 내는 존재 = 개발자)가 같은 클래스를 변경하는 일은 없어야 한다"
클린코드의 저자 마틴옹의 말

신입에게 코드 분석을 시키고, 프로젝트를 위임했다고 생각해보자.


class CashPoint{

val myCash : Int
val myPoint : Int

fun calculatePoint(point : Int) = myPoint - point
fun calculateCash(cash: Int) = myCash - cash

}