11장 - 가독성을 목표로 설계하라

개요

널리 알려진 이야기로 개발자가 코드를 작성하는데 1분 걸리지만 읽는 데는 10분이 걸립니다.

실제로 프로젝트를 진행할 때 코드 한 줄 고치기 위해 몇 주 동안 코드를 살피는 상황도 많습니다.

프로그래밍은 쓰기보다 읽기가 더 중요하며 가독성을 항상 고려하며 코드를 작성해야 합니다.

 

인식 부하 감소

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

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

A가 B보다 읽기 쉽습니다.

B는 경험많은 코틀린 개발자라면 코드를 쉽게 읽을 수 있지만 대부분의 개발자들에게 코틀린은 첫 번째 프로그래밍 언어가 아닙니다.

 

코틀린에 익숙하지 않은 개발자는 takeIf, let과 같은 함수가 어떤것인지 찾아봐야 합니다.

 

코드를 수정하는 일도 A가 더 쉽습니다.

코드를 디버깅하는 일도 A가 더 쉽습니다.

 

사실 구현 A와 구현 B는 실행 결과가 다릅니다.

let은 람다식의 결과를 리턴하며 showPerson이 null을 반환하면 두 번째 구현 때는 showError도 호출합니다.

 

실제로 글을 작성하면서도 이를 깨닫는데 시간이 오래 걸렸으며 익숙하지 않은 구조를 사용하면, 이처럼 잘못된 동작을 코드를 보면서 확인하기 어렵습니다.

 

기본적으로 인지부하를 줄이는 방향으로 코드를 작성해야 합니다.

 

극단적이 되지 않기

그러면 let을 절대로 쓰면 안 될까요?

let은 좋은 코드를 만들기 위해 다양하게 활용되는 인기 있는 관용구입니다.

가변 프로퍼티는 스레드와 관련된 문제를 발생시킬 수 있어, 스마트 캐스팅이 불가능합니다.

이때는 nullable 한 가변 프로퍼티를 안전하게 호출하게 위해 let을 사용합니다.

 

하지만 남발할 경우 코드를 디버깅하기 어렵고, 경험이 적은 코틀린 개발자는 이해하기 어렵습니다.

항상 균형을 맞추는 것이 중요합니다.

 

컨벤션

- 연산자는 의미에 맞게 사용해야 합니다.

- 함수의 이름과 내부에서 이루어지는 처리가 맞지 않습니다.

- 문자열을 결합하는 기능은 이미 언어애 내장되어 있습니다.(다시 만들 필요 없음)