Toss | null return은 코드 복잡성을 만든다.

토스 테크블로그를 읽고 쓰는 글입니다.
https://toss.tech/article/engineering-note-2

 

 

개발자 고객을 위한 코드 복잡성 관리!

 

☑️ 체크리스트

ㄴ 코드 한줄을 바꾸기 위해 바꿔야할 코드가 많다?

ㄴ 메서드 인자에 값을 추가하기 위해 지나가는 모든 메서드 인자 값을 추가한 적이 있다?

ㄴ ...

 

하나라도 체크를 했다면, 코드 복잡성을 경험해본 것이다!

 

직접 겪어보고 크게 공감되었던 두개의 체크리스트만 가져와보았다. 

코드를 바꿔야할 때 위의 경험들에 대해 고민을 해왔던 적이 종종 있었다. 과연 이게 올바른 방향일까? 라는 의문과 함께.

 

“코드를 읽는 사람 입장에서 null은 복잡성을 만든다.”

 

예시를 보자.

val user: User? = userRepository.findByName("애용")

 

만약 user가 null이라면?

1. 원래 없는 데이터여서 null인가?
2. 삭제된 데이터여서 null인가?
3. …

이처럼 null로 반환된 경우, 해당 맥락을 파악하기가 어렵다.

맥락을 알기 위해 세부 구현을 들여다보는 순간, 개발자의 생산성은 줄어든다.

 

null뿐 아니라, 빈문자열이나 -1이 반환되었을 때도 마찬가지이다.

 

---

 

나는 보통 findBy~의 메서드 경우 해당 데이터가 없는 경우를 포함하여 nullable 타입을 리턴하도록 하였다.

그리고 삭제된 데이터도 조회하는 경우도 있기에(ex. 어드민) 메서드에 includeDeleted 인자를 추가하였다.

이때 default=false를 추가하여, 이 메서드를 호출하는 쪽에서는 해당 인자에 값을 설정하지 않게 하였다.

 

하지만 이 블로그에서 인자가 많은 함수는 나쁘다고 했는데, 한번 해당 글도 봐야겠다.

 

해당 블로그에서 제시한 해결책같이

val user: User = userRepository
  .includeDeleted(true) // 이 라인을 삭제해도 findByName() 호출에는 문제 없음
  .findByName("애용")

 

요런식으로 표현해봐도 좋을 것 같다!

 

---

null 리턴은 왜 나쁠까?