가독성, 사용성, 유지보수 편의성, 확장성, 테스트 편의성, 성능 등의 다양한 관점에서 코드를 검토하면서 작성한다. 예상 가능한 모든 예외 사항을 무시하지 않고 처리한다. 이 때 로그만 찍고 진행할지, 예외를 던질지, 충분히 고민해서 코드에 반영한다.

현실에서 이게 가능할까? 이런 식으로 코드를 작성하려면 다루어야 할 이슈와 결정사항이 무수히 많다. 많은 시간과 노력, 의지가 필요하다. 하지만, 그 일들은 허구로 만들어낸 일이 아니라 실제로 가치있는 일이라는 점을 기억해야한다. 그 일들을 지금 하지 않으면, 나중에 내가 원하지 않은 시점에 예상치 못한 방식으로 수면위로 올라와 ‘예상할 수 없는’ 시간과 노력이 들게 된다. 개발 시간을 예측할 수 없는 것은 개발 시간이 ‘예측 가능하게’ 오래 걸리는 것보다 더 많은 문제를 야기한다. 또, 다른 업무에 집중하고 있을때도 지속적으로 다른 이슈가 발생하기 때문에 생산성에 큰 피해를 준다.

집에 물이 새면 고치는 것뿐만 아니라 다시는 물이 새지않게 예방하는 작업도 해야한다. 거기에 더해서 물이 새면 금방 알아차릴 수 있는 장치도 마련해야한다. 자동화된 알람일 수도 있고, 정기적인 체크 계획일 수도 있다.

코드에서 버그가 발생하면 버그를 고치는 것에 만족하지 말고, 다음에는 같은 종류의 버그가 발생하지 않게 예방 조치를 해야한다. 그리고 버그가 발생했을때 QA나 유저 리포트에 의존하지 않고 빠르게 발견할 수 있는 조치와 함께 디버깅 없이 원인을 파악할 수 있는 조치를 해야 한다.

집을 편안하게 꾸며두면 집에 있는 시간이 행복해지기 마련이고, 집에 있는 시간일 길 수록 그 효용이 커진다. 프로그래머는 많은 시간을 코드와 함께 지내기 때문에 코드를 다루기 편한 상태로 유지해두면 생산성이 좋아진다. 코드를 정리하는 작업은 새 기능을 추가하는 작업에 비해 우선순위가 밀리기 쉬우므로 의도적으로 장단기적인 이득을 저울질하고 적절한 시간을 할애할 필요가 있다.

“인자로 넘어오는 저 객체는 Null일 수 있을까? 아니면 이미 체크된 상태로 넘어오는 것일까?“

이런 의심이 드는 순간, 호출하는 코드들을 몇 군데 찾아서 살펴보고 나서 메소드 안쪽에서 Null 체크를 해야할지 결정한 적이 있다면 다시 생각해보는 것이 좋다. 내일이라도 누군가가 Null 체크를 하지 않고 내 메소드를 호출할 수 있기 때문이다.

이는 단순히 Null 체크 하는 방법에 대한 애기는 아니다. 우리가 다른 클래스의 구현상황을 보고나서 내 메소드를 어떻게 구현할지 결정하는 모든 경우를 말한다. 문제가 되는 것은 데이터의 상태일 수도 있고, 호출되는 시점일 수도 있다. 그게 무엇이든 다른 클래스의 구현을 보고 판단했다면, 우리 코드는 그 클래스의 구현에 의존성을 갖게 되고, 그 클래스의 구현이 변경되는 순간 우리의 코드는 올바른 동작을 보장할 수 없게 된다.

비정상적인 데이터가 들어오는 일이 구조적으로 불가능한 경우를 제외하고서는 항상 데이터를 검사해야한다.

하지만 데이터를 검사하는 일은 공짜가 아니다. CPU도 쓰겠지만, 코드도 늘어나고, 검사에 실패했을때 어떻게 조치할지 결정해야하고, 메소드의 사용자에게 사용법을 알려야한다. 제일 좋은 방법은 ‘구조적으로’ 잘못된 데이터가 들어올 일이 없게 하는 것이다. 가능한 적은 메소드를 노출하고, 가능한 적은 데이터를 노출하는 것. 가능한 private으로 만들고, 가능한 getter만 제공하는 것만으로도 데이터 검사의 필요성을 상당부분 줄일 수 있다.