실용주의 프로그래머 (4/27)

계획

Topic 20 디버깅

 

Tip30 당황하지 말라

‘하지만 정말 그럴 리가 없는데’로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라. 왜냐하면 명백히 그런 일은 일어날 수 있으며, 실제로도 일어났기 때문이다.

 

Tip32 그놈의 오류 메세지 좀 읽어라

먼저 문제가 무엇인지 보자. 프로그램이 죽었는가? 우리가 프로그래밍 실습이 포함된 수업을 할 때면, 빨간색 예외 메세지가 튀어나오면 냅다 탭 키를 눌러서 코드로 직진하는 개발자가 얼마나 많은지 늘 놀라울 따름이다.

 

Tip33 select는 망가지지 않았다.

대개 애플리케이션 코드가 라이브러리를 잘못 호출하고 있다고 가정하는 편이 라이브러리 자체에 문제가 있다고 가정하는 것보다 낫다.

 

Tip34 가정하지 말라. 증명하라

버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 ‘안다’고 해서 대충 얼버무리고 지나치지 말라, 그것을 증명하라. 이 맥락 안에서, 이 데이터로, 이 경계 조건하에서 증명하라.

 

→ 내가 맞다고 생각했는데 오류가 나는 경우, 당황하지 않는다. 주변을 탓하고 환경을 탓하기보다 오류 그 자체를 들여다보고 문제 해결에 집중한다. 버그상황에 확실하게 근거를 파악하고 증명한다.

 

실행

새로운 기능을 만들었고 로컬에서 정상적으로 동작했다. 테스트 환경으로 jenkins 배포 도중에 오류가 났다. 분명 로컬에서 문제가 없었는데... 라고 생각하며 갈피를 잡지 못했다.

 

나는 내 코드는 이상이 없다고 생각했다. 콘솔에서는 마지막 줄에 maven 빌드가 제대로 되지 않았다고 알려주었다. 로컬에서 직접 maven빌드를 해보았더니 너무 잘됐다. 한 2시간 이것저것 삽질했다. jenkins 구성을 뜯으보며 build 설정이 제대로 되었는지, 빌드 이후 조치가 정상적으로 이루어지는지 설정을 확인했다. 

 

그러다가 놓친 오류 메세지를 확인했다. 메세지는 아래 다음과 같았다.

 

type parameters of T cannot be determined; no unique maximal instance exists for type variable T with upper bounds int,java.lang.Object

 

 

 Mybatis SQL의 returnType이 Integer여서 service쪽에서 Integer로 리턴했어야 했는데 int를 리턴해서 생긴 오류였다. 로컬에서는 오류가 없었지만, 배포에서는 오류로 인식했다. 따라서 service쪽의 코드 리턴형을 Integer로 변환하고 정상적으로 배포를 성공했다.

 

결과

Tip32의 오류 메세지를 읽으라는 부분을 간과하고 지나쳤다. 버그 상황은 너무나도 다양하다. 버그를 모두 확인하고 메세지만 잘 검색해도 금방 오류를 해결 할 수 있다.

 

Tip33의 select는 망가지지 않는다를 읽었음에도, 나는 select가 망가졌다고 생각했다. 로컬환경과 jenkins환경이 다른 문제라 아주 조금은 맞을수는 있지만(?) 말이다. 하지만, 오류가 났다면 항상 내가 옳다고 생각했던 전제가 정말 맞는지 증명하는 과정이 필요하다. 

 

버그는 언제나 당황스럽다. 침착하고 싶지만, 사람이 빨간줄, 빨간색을 보면 그렇게 안된다. 그럼에도, 단순히 문제를 해결하는 하나의 과정이라고 스스로 주문을 외우고 해결에 집중하면 한결 마음이 편해질 수 있을 것이다.