프로그래밍 노트/Effective 시리즈

[Effective Kotlin. 11] 가독성을 목표로 설계하라

깡냉쓰 2023. 11. 1. 15:29
728x90
반응형

개발자가 코드를 작성하는 데는 1분 걸리지만, 이를 읽는 데는 10분이 걸린다 - 로버트 마틴 <클린코드>

  • 프로그래밍은 쓰기보다 읽기가 중요
  • 항상 가독성을 생각하며 코드릴 작성할 필요가 있음

인식 부하 감소

  • kotlin을 처음 접하게 되면 코드가 간결해지는 몇 가지 마법들을 만나게 된다.
  • 이 몇가지 마법들을 알게되면 활용을 하고 싶어지고, 코드를 계속 간결하게 만들고 싶은 욕망에 사로잡히게 되는데 가독성 측면에서 생각해볼 필요가 있음

무엇이 더 좋을까?

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

// 구현 B
person?.takeIf { it.isAdult }
  ?.let(view::showPerson)
  ?: view.showError()
  • B는 간결하지만 읽고 이해가기가 어려움
  • 가독성이란 코드를 읽고 얼마나 빠르게 이해할 수 있는지를 의미
    • 얼마나 많은 관용구(구조, 함수, 패턴)에 익숙해져 있는지에 따라 차이는 있음
  • 코틀린 개발자라면 B 코드도 쉽게 읽을 수 있겠지만, 숙련된 개발자만을 위한 코드는 좋은 코드가 아님 (찬성하는 바임)
    • B 코드도 쉽게 읽겠지만 A 를 이해하는 것이 훨 쉬움
  • A vs B 는 당연히 A가 훨씬 가독성이 좋은 코드임
    • 수정도 쉬우며
    • 디버깅도 간단
    • 일반적이지 않고 '굉장히 창의적인'구조는 유연하지 않고, 지원도 제대로 받지 못함(ex. intellij)

기본적으로 인지 부하를 줄이는 방향으로 코드를 작성하자.

  • 뇌는 패턴을 인식하고, 패턴을 기반으로 프로그램의 작동 방식을 이해
  • 가독성은 '뇌가 프로그램의 작동 방식을 이해하는 과정'을 더 짧게 만듬
  • 자주 사용되는 패턴을 활용하면 이와 같은 과정을 더 짧게 만들 수 있음
  • 뇌는 기본적으로 짧은 코드를 빠르게 읽을 수 있지만, 익숙한 코드는 더 빠르게 읽을 수 있음

극단적이 되지 않기

  • let 관용구를 잘 이해하지 못하면 잘못된 동작을 눈치채지 못할 수 있음
    • 위의 A와 B 코드는 다르게 동작하는데, let은 람다식의 결과를 리턴하기 때문
    • showPerson이 null을 리턴하면, B는 showError도 호출하게 됨
  • 그렇다고 let은 절대 쓰면 안 된다라고 이해하면 안됨 (이렇게 이해하는 사람도 있나??)
  • nullabl 가변 프로퍼티가 있고, null이 아닐때만 어떤 작업을 수행해야하는 경우 let이 활용될 수 있음
class Person(val name: String)
var person: Person? = null

fun printName() {
  person?.let {
    prtin(it.name)
  }
}
  • 아래 같은 경우에도 let 사용
    • 연산을 아규먼트 처리 후로 이동시킬 때
    • 데코레이터를 사용해서 객체를 랩할 때
// print(students.filter {}.joinToString {})
students
  .filter { it.result >= 50 }
  .joinToString(separator = "\n") {
    "${it.name} ${it.surname}, ${it.result}
  }

var obj = FileInputStream("/file.gz")
  .let(::BufferedInputStream)
  .let(::ZipInputStream)
  .let(::ObjectInputStream)
  .readObject() as SomeObject
  • 비용이 지불할 만한 가치가 없는 코드에 비용을 지불하지 말자.
728x90
반응형