9장. 예상하지 못한 것을 예상하기

실패하도록 두라

실패를 막기위해 값을 조작하는 행위는, 더 큰 버그를 만들고 디버깅을 어렵게 한다. 책에서는 얼랭을 예로 들고 있는데, 최소한 개발 단계에서는 명확한 에러가 더 낫다고 생각한다. 특히 초기 개발 단계에서는 더 그렇다.

10장. 버그 사냥하기

세계 경제를 살리기 위해서라도 개발자에게는 버그를 좀 더 빨리 해결해야 할 책임이 있다.

그냥 웃겨서 코멘트를 남겨 놓는다. 마틴 파울러는 "미련한 프로그래머는 컴퓨터가 이해할 수 있는 코드를 만들고, 좋은 프로그래머는 사람이 이해할 수 있는 코드를 만든다." 라고 말했다. 메서드 하나를 만들때도 만들고나서 경우에 따른 예외처리를 덕지덕지 붙일게 아니라, 처음부터 예외처리를 하지 않도록 만들어야 한다. 그래야 코드도 줄어든다. 엔트로피 법칙(놀라운 물리의 법칙....)에 따라 코드가 많으면 버그도 많다. 버그를 남기지 않기 위해서는 처음부터 고민하고 코드를 최대한 안짜야 한다. 코드부터 짜지 말고 생각을 해야한다. 타이핑을 열심히 하면, 손가락에 관절염을 얻을 뿐이다.

이진 탐색 전략을 목표로 하라.

컴퓨터만 이진 탐색을 하는 것이 아니다. 컴퓨터가 하는 일은 사람이 할 일을 X나 빠르게 하는 것 뿐이다. 코드도 반씩 나눠서 보다보면 생각보다 너무 쉽게 찾을 수 있다.

지금 당장은 괜찮아 보일지라도, 테스트라는 안전장치 없이는 추후 쉽게 무너질 수 있다.

테스트를 통하여 문제를 해결했음을 증명해야한다. 한가지 문제를 해결했는데 다른 문제가 생기면 어떻게 할 것인가. 사소한 버그를 해결했는데 중요한 부분에서 문제가 생긴다면? '나는 이 문제를 해결했으니 괜찮다.' 라고 생각한다면 다른 직업을 알아보는 것이 좋을 것이다. 최소한의 검증은 반드시 필요하다. 그래야 해결하는 의미가 있다. 그렇지 않다면 롤백뿐이다.

과하게 디버거에 의존하는 것은 좋지 않다.

디버거는 강력한 툴이다. 하지만 나는 어지간하면 쓰지 않는다. 자존심의 문제... 라기보단, 문제를 미시적으로 바라보게 되기 때문이다. 자바의 JPA는 하이버네이트의 1차 캐시 때문에 다른 언어의 DB 라이브러리들과 동작방식이 조금 다르다. 이로인한 차이는 디버거를 백날 바라봐야 나오지도 않고, 끝까지 들어가기조차 쉽지 않다. (어디까지 들어가게 될지도 모르겠다.) 오히려 쿼리와 엔티티 매니저의 DEBUG 로그까지 다 켜서 로그를 봐야 동작 방식을 이해하고 문제를 파악하고 해결책에 접근 할 수 있다.
(JPA는 한 트랜잭션 내에서 조회를 통해 영속성 컨텍스트에 저장하면, 동일한 객체에 대해 조회를 하더라도 DB에서 불러오지 않고 영속성 컨텍스트에서 꺼내온다. 이 때 반드시 DB에서 값을 다시 읽어와야하는 경우가 있는데, 그럴 경우에 어떻게 해야할까? 찾아보고 구현해보자. 이 문제를 디버거만 가지고 해결할 수 있다면 댓글을 꼭 부탁드린다.)

재현할 수 없는 버그

네트워크 상태나 디스크 등 물리적 영향을 받는 건 어쩔수 없다. 상호 베타적이지 않은 기능을 스레드로 돌리거나... 빈으로 등록할 클래스에 상태를 표현하는 변수를 둔다거나... 이런 짓은 하지 말자.

도망가지 말라.

마구잡이로 달려들었다가 지쳐서 나가떨어지면 안된다. 그럴 땐, 잠깐 머리를 식히고 같은 팀 사람들에게 현 상황을 설명해보자. 뜬금없이 해결책이 떠오를 수 있다. 현재 그 문제에 대해 가장 잘 알고 있는 사람은 바로 당신이다.