null 리턴은 왜 나쁠까?
toss.tech
🤔 Null 리턴은 왜 나쁠까?
프로그래밍에서 Null 의 사악함(?)은 많은 아티클들을 통해 접해보셨을 겁니다.
오늘 공유해드릴 글은 Null 을 리턴하는 코드가 왜 나쁜 코드인지, 코드를 읽는 사람의 입장과 코드 복잡성 관점으로 설명한 글입니다.
Null 리턴은 코드의 복잡성을 높여서 서비스 사용자에게는 버그와 장애를, 개발자에게는 낮은 생산성을 가져올 수 있습니다.
이를 해결하기 위해서는 다음과 같은 해결 방법이 있습니다.
📌 로그에 맥락을 남기기
주석을 남기는것도 방법이지만, 주석은 실제 코드가 아니기 때문에 변경이 발생할때 같이 관리되지 않을 수 있습니다.
따라서 null 이 리턴 되었을 경우 로그나 Exception 메세지에 왜 null 이 발생할 수 있는지를 명확하게 정리함으로써 코드를 읽는 개발자가 이를 쉽게 파악할 수 있도록 합니다.
📌 맥락 처리를 위한 기능 만들기(단, 필요할때만)
null 이 리턴되었을 경우 이를 수정하기 위한 추가적인 로직 혹은 재시도 처리 등을 통해 Null 이 리턴되는 상황을 어느정도 유추하고 방어할 수 있습니다.
단, 무분별한 재시도 처리 등은 성능 저하 및 생산성을 떨어뜨릴 수 있기 때문에 반드시 필요한 경우에만 만드는게 좋습니다.
공유드린 원문에 이에 대한 상세한 예시들이 정리되어있으니 관심있으신 분들께서는 원문 내용을 참고해주세요.
📚 원문
https://toss.tech/article/engineering-note-2?utm_source=oneoneone
📚 함께 보면 좋은 글
🛠 Java Optional 은 언제 사용해야할까?: https://careerly.co.kr/comments/87740?from=search-result&fromArea=tab-comment
다음 내용이 궁금하다면?
이미 회원이신가요?
2023년 11월 17일 오전 8:40
댓글 6
오늘 restdocs 관련 검색을 하다가 우연히 토스테크 페이지에 들어가서 위에 null 관련 포스트를 봤는데 이렇게 또 이 내용을 여기서 보게되네요 약간 운명인것 같아 몇자 의견을 적어봅니다 원문의 내용대로 null을 반환하는것이 그 의미를 불분명하게 만들기 때문에 최대한 지양하는게 옳다고 생각합니다 다만 이를 설명하는 내용에서 약간 갸우뚱 하게되는 부분이 있네요 null을 반환하게 되는 유일한 이유가 특정일에 시행되는 싱크작업이 이루어 지지 않았기 때문이라고 이유를 정해버리고 설명을 풀다보니 이게 과연 null사용을 지양하자는 내용인지 아니면 싱크를 하는 방법에 대한 내용인지 논점이 흔들리네요 애초에 싱크를 한다고 해서 백프로 null이 발생하지 않는것도 아닐텐데 말이죠 오히려 단순히 user 정보를 얻고자 하는 동작에 의도하지 않게 싱크라는 부가적인 동작까지 이루어 지게 될수도 있구요 개인적으로는 다소 아쉽게 끝나는 글이었습니다 ㅎㅎ
@minw 안녕하세요! 말씀하신 것처럼 글에서 나온 예시가 일반적인 느낌은 아니고 글의 마무리를 열린결말(?)처럼 매듭을 지어 아쉬운 부분에 대해 공감하는 바입니다. 다만 null 일때 예외를 던지는 fail-fast 전략이 아닌 경우의 해결 방안으로 이해하였고 이는 실제 구현해야하는 비지니스 로직에 따라 다를수 있어 무조건 이렇게 하는게 정답이라 얘기하긴 힘들거라 생각하였습니다. 결국 글쓴이의 의도는 비지니스 로직이 거대해져 나중에 손쓸수 없기 전에 이런 고민들을 잘 녹여내야 한다는 거로 이해하였습니다.
질문이 있는데 JSON의 속성값중 NULL값을 응답하는것도 해당사항이 있을까요? 어플리케이션단에서 null은 지양해야하는걸로 알고있는데 API와 통신하는 클라이언트 입장에서는 특정 필드가 null인 것이 어쩌면 명확할 수 있겠다는 생각이 들어서요
@Kiwik exception을 날려서 catch 처리하는게 낫지 않을까요 여러 경우를 대응할 수 있으니까요
@Kiwik 안녕하세요! client 와 server 가 서로 약속하여 NULL 일 경우 어떤 케이스다 라고 정하고 쓸수도 있겠습니다만, 개인적으로는 NULL 보다는 정의되지 않았다 라는 의미의 default 값을 정의하는게 더 좋지 않나 싶습니다. 가령 String 의 경우 "UNKNOWN" 혹은 "UNDEFINED"이란 text 를 쓴다던지, int 일 경우 0 혹은 -1 을 쓴다던지, list 나 object 의 경우 empty list 혹은 empty object 를 쓰는 방향으로요. 이렇게 하면 client 단에서 전달받은 응답값을 deserialize 하여 NULL 값을 참조할 일이 있을 때 NPE 발생을 막을 수 있고 좀더 명확하게 해당 필드 데이터는 현재 존재하지 않다 라는 의미를 줄 수 있다고 생각합니다.
API와 연결하는 클라이언트의 관점에서는 애플리케이션 수준에서 null을 피해야 하는 경우에도 특정 필드가 null이라는 것이 명백할 수 있습니다. https://geometrygame.io/
함께 읽은 게시물
🧨 개발자를 잠 못 들게 만드는 코드
개
... 더 보기
이력서에서 소프트스킬을 어떻게 보여줄 수 있을까요?
이
... 더 보기요즘 사람들이 가장 많이 AI를 활용하는 분야 Top 10
1
... 더 보기💸 기술 부채 개념, 유형, 해결 방법
기
... 더 보기서버 이미지 포맷 종류와 사용 기준
앱
... 더 보기🤔 API Versioning 은 반드시 필요할까?
R
... 더 보기
