클린 코드 #14일차

TIL (Today I Learned)

 

• 2022.03.03

 

📕 오늘 읽은 범위

 

• 7장. 오류 처리

 

🙂 책에서 기억하고 싶은 내용

 

• '오류 코드보다 예외를 사용하라' (p.130)

 

• 'Try-Catch-Finally 문부터 작성하라' (p.132)

 

• '미확인unchecked 예외를 사용하라' (p.133)

 

• '예외에 의미를 제공하라' (p.135)

 

• '호출자를 고려해 예외 클래스를 정의하라' (p.135)

 

• '정상 흐름을 정의하라' (p.137)

 

• 'null을 반환하지 마라' (p.138)

 

• 'null을 전달하지 마라' (p.140)

 

• 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 이 둘은 상충하는 목표가 아니다. 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하 면 튼튼하고 깨끗한 코드를 작성할 수 있다. 오류 처리를 프로그램 논리와 분리 하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다. (p.142)

 

🤔 오늘 읽은 소감은?

 

   대다수의 우리들이 겪는 코드와의 전쟁에서 nullPointerException은 아주 빈번하게 발생하고 우리를 괴롭히는 감기 바이러스 같은 존재라 볼 수 있다. 그렇게 노련하게 싸워온 우리들은 (p.139)의 예제같은 코드를 많이 봐오고 혹은 그렇게 짜왔을 것이다. null을 체크하는 것은 nullSafety를 위해서 많은 사람들이 사용하는 방법이지만, 저자는 저렇게 일일이 체크하는 노력에도 불구하고 놓칠수 있는 nullPointerException을 Wrapper 메서드를 통해 예외를 던지거나 '특수사례객체'를 던져 해결할 것을 추천하고 있다. 

 

   본인의 경우는 '?','&','|' 과 같은 연산자를 사용해 null을 체크하였는데, if 조건절 보다야 코드는 줄일 순 있겠지만, 이 방법도 결국 null이 예상되는 즉, 개발자가 인지하는 부분에서 체크한다는 점이 위의 문제와 다를바 없다. 요즘 typescript 같은 기술에서는 자동으로 nullSafety를 체크해줘서 참 편해졌지만, 근본적으로 돌아가 null 값을 반환하거나 전달하는 경우를 줄이도록 하는 방법을 계속 염두해야 하겠다.

 

   사실 그동안 예외로 던질 때 책에서도 소개하듯이 (p.138, 140)예제처럼 충분히 생각해서 줄일 수 있는 부분도 기계적으로 예외 혹은 조건문을 달아 왔던 부분이 많았을 것이다. 처음부터 좋은 코드의 최적의 길을 찾아 내긴 어렵겠지만, 코드를 여러번 수정하면서 한번에 한글자라도 나아 질 수 있도록 지속적인 노력을 필요할 것이다.