Debug it! 실용주의 디버깅

( 이미지 출처 Yes24 : http://www.yes24.com/24/Goods/3937865?Acode=101 )

감상

선배로부터 들었던 주옥같은 조언들, 평소 막연히 생각은 했지만 체계화하지 못했던 원칙들이 잘 정리되어 있다. 특정 개발환경에만 국한되지 않는 보편적인 원칙들로 채워져 있어서, 시간이 지나도 이 책의 가치는 바래지지 않을듯..

인상 깊은 부분

p65

동시에 여러 개를 변경하면 잘못된 결론에 이를 수 있다.

p68

뭐든지 우리가 이해하지 못하는 부분은 잠재적인 버그다.

p76

디버깅은 순간이지만 테스트는 남는다.

디버거가 디버깅 방법 중에서 가장 강력한 것임에는 틀림없다. 우리 모두는 디버거가 손에 익도록 해야 한다. 하지만 나같은 경우에는 디버거를 점점 안 쓰게 됐다. 그리고 나만 그런 것도 아니었다. 비슷한 얘기를 하는 개발자들이 많았다. 왜 이런 일이 벌어지는 걸까?

변화의 중심에는 테스트 우선 개발이 있다. 예전에는 디버깅하면 디버가가 떠올랐다면 요즘에는 테스트 작성이 떠오른다.

테스트는 이론이 맞음을 증명해 보여줄 뿐만 아니라 버그가 제대로 수정됐는지도 검증해준다.

p101

로직을 하나 바꿀 때마다 체크인하기 디버깅 관점에서 소스 관리 시스템의 가치는 감사 추적 기능에 있다. 누군가가 회귀를 만든 경우에는 이전 버전을 따라가면서 어디를 고쳤기 때문에 회귀가 생겼는지, 그래서 어디를 고쳐야 할지를 정확하게 찾을 수 있어야한다. 하지만 이 방법의 효과는 매번 체크인한 양에 반비례한다. 어느 체크인에서 버그가 생겼는지를 찾더라도 그 체크인에서 프로젝트 전체에 펴져있는 수백 개의 파일을 변경했다면 크게 의미가 없다.

이런 문제를 피하려면 ‘로직을 하나 바꿀 때마다 체크인하기'라는 규칙을 준수하자.

p146

자, 테스트 없는 코드를 어떻게 리팩토링할 수 있을까? 못한다. 먼저 테스트를 작성하자.

p171

우리 코드를 먼저 의심하자. 버그가 우리 코드에 있을 거라고 먼저 가정하자. 버그가 다른 곳에 있다는 결론이 나더라도 다시 한 번 우리 코드를 세삼하게 살펴보자. 온갖 방법을 다 동원해 봐도 우리가 문제가 아니다 싶은 다음에야 서드파티 코드를 비난하자.

p197

좋은 소프트웨어를 만드는 방법에 대한 글은 참 많다. 하지만 디버깅하기 쉽게 소프트웨어를 만드는 방법에 대한 글을 별로 없다.

좋은 소식은, 개발하면서 관심의 분리, 중복 금지, 정보 은닉 같은 일반적인 좋은 소프트웨어 개발원칙을 따랐다면 소프트웨어가 구조도 잘 잡혀있고, 이해하기 쉬우며, 수정하기도 좋을 뿐만 아니라 디버깅하기도 쉽게 돼 있을 거라는 점이다. 좋은 설계와 디버깅하기 좋은 구조는 서로 충돌하지 않는다.