TIL

아이템 11 가독성을 목표로 설계하라

개발자가 코드를 작성하는 데는 1분 걸리지만, 이를 읽는 데는 10분이 걸린다.

인식 부하 감소

• 가독성은 사람에 따라 다르지만 일반적으로 많은 사람의 ‘경험’과 ‘인식에 대한 과학’으로 만들어진 어느 정도의 규칙이 있다.

// 구현 A
if (person != null && person.isAdult) {
	view.showPerson(person)
} else {
	view.showError()
}

// 구현 B
person?.takeIf { it.isAdult }
	?.let(view::showPerson)
	?: view.showError()

• 만약 위 코드에서 B가 더 짧기에 가독성이 좋다고 한다면 이는 좋은 대답이 아니다.
• 가독성이란 코드를 읽고 얼마나 빨리 이해할 수 있는지를 의미한다.
  • 우리 뇌가 얼마나 많은 관용구에 익숙해져 있는지에 따라 다르다.
  • 코틀린 초보자에겐 일반적인 관용구(if/else)를 사용한 A가 더 읽기 쉬울 것이다.
  • B의 관용구도 코틀린 숙련자에겐 익숙한 관용구이지만 숙련된 개발자만을 위한 코드는 좋은 코드가 아니다.
  • 그리고 숙련된 코틀린 개발자라 해도 A가 훨씬 읽기 쉽다.
• 또한 if/else 블록이 코드를 수정하고 리팩터링하기도 쉽다.
  • if/else 블록 내부에 코드를 추가하면 된다.
  • 구현 B는 더 이상 함수 참조를 사용할 수 없어 코드를 수정해야 한다.

// 구현 A
if (person != null && person.isAdult) {
	view.showPerson(person)
	view.hideProgressWithSuccess()
} else {
	view.showError()
	view.hideProgress()
}

// 구현 B
person?.takeIf { it.isAdult }
	?.let {
		view.showPerson(person)
		view.hideProgressWithSuccess()
	} ?: run {
		view.showError()
		view.hideProgress()
	}

• 일반적인 디버깅 도구도 구현 A의 구조를 더 잘 분석하기에 디버깅도 간단하다.
  • 이처럼 일반적이지 않고 창의적인 구조는 유연하지 않고 IDE의 지원 등도 제대로 받지 못한다.
• 참고로 구현 A와 B는 결과가 다른데 let은 람다식 결과를 리턴하기에 showPerson이 null을 리턴하면 showError도 호출하게 된다.
• 기본적으로 인지부하를 줄이는 쪽으로 코드를 작성해야 한다.
  • 자주 사용되는 패턴을 활용

극단적이 되지 않기

• 방금 사례로 인해 let은 절대 쓰지 말자는 결론을 내선 안 된다.
• let은 좋은 코드에서 다양하게 활용되는 관용구다.
  • 아래는 nullable 가변 프로퍼티를 처리하는 코드다.
  • 원래 가변 프로퍼티는 스레드 세이프하지 않기에 스마트 캐스팅이 불가하지만 안전 호출 let을 통해 해결할 수 있다.

class Person(val name: String)
var person: Person? = null

person?.let {
	print(it.name)
}

• let은 다음 경우도 많이 사용한다.
  • 연산을 아규먼트 처리 후로 이동시킬 때
  • 데코레이터로 객체를 랩할 때

students
	.filter { itresult >= 50 }
	.joinToString(separator = "\n") { 
		"${it.name} ${it.surname}, ${it.result}"
	}
	.let(::print)
	
var obj = FileInputStream("/file.gz")
	.let(::BufferedInputStream)
	.let(::ZipInputStream)
	.let(::ObjectInputStream)
	.readObject() as SomeObject

• 위 코드들은 디버깅이 어렵고 코틀린 초보에겐 어려운 코드이기에 비용이 발생한다.
  • 이 비용을 지불할 만한 가치가 있다면 사용해도 괜찮다.
• 물론 어떤 코드가 비용을 지불할 만한 코드이지는 항상 논란이 있기에 균형을 맞추는 것이 중요하다.

컨벤션

• 프로그래밍은 표현력의 예술이다. 이를 위해 기억해야 하는 몇 가지 규칙이 있다.
• 필자가 생각하는 코틀린으로의 최악의 코드는 아래와 같다.

val abc = "A" { "B" } and "C"
print(abc) // ABC

• 위 코드가 가능하려면 다음 코드가 있어야 한다.

operator fun String.invoke(f: () -> String): String = 
	this + f()
	
infix fun String.add(s: String) = this + s

• 이 코드는 수많은 규칙을 위반한다.
  • 연산자는 의미에 맞게 사용해야 한다. invoke를 이런 형태로 사용하면 안 된다.
  • ‘람다를 마지막 아규먼트로 사용한다’라는 컨벤션을 여기에 적용하면 코드가 복잡해진다.
  • 현재 코드에서 add라는 함수 이름이 실제 함수 내부에서 이루어지는 처리와 맞지 않는다.
  • 문자열 결합 기능은 이미 내장되어 있기에 다시 만들 필요가 없다.