회사에서 일할 때 주의할 점2

9일부터 오늘까지 주말을 포함해서 4일간..

에러를 찾지 못해서 고생을 했었다.

 

controller 에서 service 를 통해 DB 로 결과물을 전달하고

응답을 받아야되는데 계속 서버에러로 전달은 되지만

결과물이 Controller 로 전달되지 않았던 것이다. 

 

원인은 Xerces 가 pom.xml 에 등록이 되어있지 않았었고

그로인해 mybatis에 .xml 에 등록되어 있었던 복잡한 쿼리문이 파싱이 제대로 되지않아

값을 해독하지를 못했던 것이었다. 

 

ko.wikipedia.org/wiki/%EC%95%84%ED%8C%8C%EC%B9%98_%EC%84%9C%EC%84%B8%EC%8A%A4

아파치 서세스 - 위키백과, 우리 모두의 백과사전

왜 이렇게 쉬웠던 에러를 빠르게 해결하지 못한 이유가 무엇일까 고민을 해본 결과...

개발 시, 로그를 남기지 않았던 것과

초반에 발생하는 에러를 무시했던 점이었던 것 같다..

 

개발을 할때 주의해야될 점은.. 에러가 나올 때 그냥 넘기지 않아야 하는 것인데

몇일 동안 같은 에러가 tomcat 을 시작할 때 계속 떴었는데도 말이다.

그것을 보고 찾아보았다면..어쩌면 2일정도면 해결할 수 있었을 듯 하다..

 

그리고 중요한 곳마다 로그를 심어놓아서 어디서 문제가 발생했는지 알게할 수 있으면 그것도 

금상첨화..!

 

이번 4일의 시간을 통해 3가지를 배운 것 같다.

 

1. 디버그는 여전히 중요하다

- 처음에는 디버그를 귀찮아서 잘 하지 않으려 했었으나.. 디버그를 하면서 

  어디에 문제가 있는지를 캐치할 수 있었다. 역시 디버그는 귀찮아도 꼭 해야되는 것을 

  다시한번 배울 수 있었다.

 

2. 사소한 에러라도 무시하지 말 것

- 사소한 에러 하나로 인해 4일의 시간을 날리게 되었다.. 아직 초급이라 봐줄 수 있다(?) 일수도 있으나.

  개발자가 사소한 에러를 별것 아니겠지라고 무시한 것은..좀 아니었다. 

  4일의 시간은 많은 것을 진행할 수 있는 시기였다 참고로.. 앞으로는 사소한 에러라도 발생할 시에, 

  바로 구글링을 하거나해서 원인을 찾고 해결하거나 판단하고 넘어갈 것!

 

3. 개발 초기, 중요한 곳에는 로그를 심어두어 볼 수 있도록 하자

- 이번 문제를 해결하는 데 로그를 몇군데 심어본 것이 큰 역할을 했었다..

  어디서 문제가 있는지를 빠르게 캐치할 수 있어야, 개발 속도도 보다 빨라질 수 있다.

  사소한데서 이렇게 시간을 끌 수는 없다