터지지 않는 앱의 역설(논리 에러)

최근 개발을 하다 리포트받은 버그가 있었는데, 이는 컴파일 과정이나 런타임중에 확인 할 수 없었던 부분이었다. 디버깅을 하고 나니 이는 소켓통신 결과에 따라 신규 데이터를 처리할 때 필수적인 변수에 default argument가 설정되어 있기 때문이었다. 여기서 해당 변수에 대한 mapping이 일부 누락이 되었고 이로 인해 오동작을 하게 된 소위 논리 에러가 발생하게 된 것이었다.

이번 버그를 통해 얻은 교훈이 있다면 필요에 따라 중요한 요소에 대해서는 의도적으로 개발자를 불편하게 할 필요가 있다는 것이었다. 가장 좋은 에러는 릴리즈 이전에 맛보는 에러이기 때문에, 중요한 기능들에 대해서 올바르게 구현되지 않았다면 개발자가 최소 런타임 중에, 나아가서 컴파일 중에 에러를 경험하도록 의도하는 것이 결국 완성도 높은 프로그램을 소비자에게 전달하는 길이 될 수 있지 않을까.

그렇다면 주의해서 어떤 부분에 대해 '의도적 불편함'들을 주어야 할 까. 생각나는 것들을 건조하게 정리해봤다.

• Nullable의 편안함에 빠지지 말 것(특히나 Kotlin).
• 의도되지 않은 동작에 대해서 명확한 Exception을 정의하고 발생시킬 것. (개발자를 조심스럽게 만들어라. 난 소중한 프로그램이라고..)
• interface 및 abstract class, method등을 이용해 반드시 구현해야 하는 부분을 개발자에게 강제하고 상기시킬 것.
• 메소드에서 발생한 error를 풀고자 너무 을의 입장이 되지 말 것. (에러를 해소하기 위해 꾸역꾸역 코드를 덧대기 이전에, 메소드가 필요로 하는 바와 의도를 다시금 생각해 보는게 어떨까?)