Debug It! 실용주의 디버깅 [소프트웨어 개발자가 꼭 알아야 할 디버깅의 정석]
- 원서명Debug It!: Find, Repair, and Prevent Bugs in Your Code (ISBN 9781934356289)
- 지은이폴 부처
- 옮긴이박일
- ISBN : 9788960771413
- 25,000원
- 2010년 06월 29일 펴냄 (절판)
- 페이퍼백 | 268쪽 | 185*235mm
판매처
- 현재 이 도서는 구매할 수 없습니다.
책 소개
[ 소개 ]
직업 프로그래머는 한 치의 오차도 없이 버그의 근본 원인을 제거하는 기술을 익힌다. 디버깅 기술은 평소 버그 있는 코드를 생성하고 이를 수정하면서 얻는 경험에서 배울 수 있다. 이 책에는 저자가 그렇게 얻은 생생한 경험이 적혀있다. 이 책에서 얻은 실전 경험을 바탕으로 버그를 줄이고, 버그가 있더라도 훨씬 쉽게 찾을 수 있도록 코드를 작성하는 방법을 익힐 수 있다.
『Debug It! 실용주의 디버깅』은 확신을 가지고 버그를 잡는 데 도움이 될 만한 도구, 기법, 접근 방법을 제공한다.
전문 디버깅의 비밀은 버그의 전 과정, 즉 디버깅을 쉽게 할 수 있도록 소프트웨어를 만드는 것에서부터, 버그를 찾고 재현하고 진단하고 마지막으로 수정하는 과정까지를 전부 보여준다. 자바냐 기계어냐, 서버냐 임베디드 마이크로컨트롤러냐, 애자일이냐 전통적인 방법이냐에 상관없이 기본적인 버그 수정 원칙을 적용할 수 있다.
이 책에서는 소프트웨어만의 독특한 기능을 통해 실제로 어떤 일이 벌어지는지 보여줄 수 있는 경험주의적인 접근 방법, 안정적이고 편하게 버그를 재현할 수 있는 방법의 중요성, 공통적인 실수를 피할 수 있는 방법 등을 배울 수 있다. 흔히 사용되는 도구를 활용해 고객이 버그를 발견하기 전에 먼저 자동으로 찾을 수 있는지도 익힌다. 또한, 결정적인 내부 정보에 알아서 접근하고, 버그를 생성하는 깨진 가정이 어디인지 알려주는 '스스로 디버깅하는' 소프트웨어를 만들 수 있다.
[ 이 책의 구성 ]
■ 1부. 문제의 핵심
1부에서는 개발 중인 소프트웨어를 통해 내부에서 뭐가 어떻게 실행되는지를 보는 경험주의 접근법과, 이에 기반한 핵심 디버깅 방법(재현, 진단, 수정, 반영)을 소개한다.
■ 2부. 큰 그림
고쳐야 하는 문제가 있다는 걸 처음에 어떻게 찾을 수 있을까? 디버깅 과정을 소프트웨어 개발 프로세스 안에 어떻게 넣을 수 있을까?
■ 3부. 디버깅 비급
3부에서는 다음과 같은 좀 더 어려운 주제를 살펴본다.
• 1~2부에서 살펴본 방법들은 모든 버그에 적용할 수 있지만 특별한 조치를 해줘야 하는 버그도 있다.
• 디버깅은 해당 버그 때문에 열 받은 사용자가 불평 전화를 걸어오기 훨씬 전부터 시작한다. 특정 도구나 프로세스를 써서 이런 일을 미연에 방지할 수 없을까?
• 마지막으로 빠지기 쉬운 여러 가지 함정도 알아본다.
목차
목차
- 1부 문제의 핵심
- 1장 구조적인 접근
- 1.1 디버깅은 ‘버그를 없애는 것’ 그 이상이다
- 1.2 경험주의 접근법
- 1.3 핵심 디버깅 과정
- 1.4 중요한 일부터 먼저
- 1.5 실천하기
- 2장 재현
- 2.1 고민하기 전에 재현부터 해보자
- 2.2 소프트웨어 제어
- 2.3 환경 제어
- 2.4 입력 제어
- 2.5 재현 방법 다듬기
- 2.6 정말로 재현할 수 없다면?
- 2.7 실천하기
- 3장 진단
- 3.1 잠깐, 지금부턴 과학을 할 겁니다
- 3.2 계략
- 3.3 디버거
- 3.4 실수
- 3.5 심리전
- 3.6 진단 확인
- 3.7 실천하기
- 4장 수정
- 4.1 전투 준비
- 4.2 테스트
- 4.3 증상이 아닌 원인을 고친다
- 4.4 리팩토링
- 4.5 체크인
- 4.6 코드 리뷰 받기
- 4.7 실천하기
- 5장 반영
- 5.1 이게 어떻게 돌아가고 있었지?
- 5.2 뭐가 잘못된 거지?
- 5.3 다시는 이 문제가 생기지 않을꺼야
- 5.4 선순환 구조 만들기
- 5.5 실천하기
- 2부 큰그림
- 6장 문제 발견
- 6.1 버그 추적
- 6.2 고객과 작업하기
- 6.3 지원 팀과 일하기
- 6.4 실천하기
- 7장 실질적인 무관용
- 7.1 버그 우선순위
- 7.2 디버깅할 때의 마음가짐
- 7.3 품질 결함 수렁에서 빠져나오기
- 7.4 실천하기
- 3부 디버깅 비급
- 8장 특수한 경우
- 8.1 기존 릴리스 패치
- 8.2 하위 호환성
- 8.3 병렬
- 8.4 하이젠버그
- 8.5 성능 버그
- 8.6 임베디드 소프트웨어
- 8.7 서드파티 소프트웨어 버그
- 8.8 실천하기
- 9장 이상적인 디버깅 환경
- 9.1 자동 테스팅
- 9.2 소스 관리 시스템
- 9.3 자동 빌드
- 9.4 실천하기
- 10장 소프트웨어가 스스로를 디버깅하게 만들기
- 10.1 가정과 단언문
- 10.2 디버깅 빌드
- 10.3 자원 누수와 예외 처리
- 10.4 실천하기
- 11장 안티 패턴
- 11.1 우선순위 인플레이션
- 11.2 프리마돈나
- 11.3 유지 보수 팀
- 11.4 화재 진압
- 11.5 새로 작성하기
- 11.6 코드 주인의식 실종
- 11.7 흑마술
- 11.8 실천하기
- 부록 A 자원
- A.1 소스 관리 시스템과 이슈 추적 시스템
- A.2 빌드와 지속적인 통합 도구
- A.3 유용한 라이브러리
- A.4 다른 도구
관련 블로그 글
디버깅과 테스팅의 교본『Debug It! 실용주의 디버깅』
소프트웨어 개발자가 꼭 알아야 할 디버깅의 정석
폴 부처(Paul Butcher) 지음 | 박일 옮김
2010년 6월 29일 출간예정 | 268쪽 | 25,000원
YES24, 교보문고, 인터파크, 강컴, 알라딘
1. 잘하면 재미있지만, 잘못하면 짜증난다.
2. 힘들다.
3. 하면 할수록 늘지만, 너무 자주 하는 건 싫다.
4. 밤에 할 때가 많다.
5. 대놓고 얘기하긴 부끄럽다(얘기할 때는 몇 배 부풀린다).
6. 다들 궁금해한다.
7. 책이 별로 없다.
무슨 이야기일까요? 아무래도 좀 난~한 이야기이긴 하지만, 미성년자가 저희 책을 사볼 일은 거의 드물(?) 테므로, 밝히자면, 이 책『Debug It! 실용주의 디버깅』의 역자 박일님이 자신의 블로그 "박피디의 게임 아키텍트 블로그'에 올렸던 '디버깅과 섹스의 공통점'이라는 블로그 글에서 발췌한 내용입니다. 7가지만 추렸지만, 블로그 글을 읽어보시면 역자분이 밝힌 20가지 외에도 수많은 분들이 공통점을 올려주셨네요. 재미있는 예제 글이었습니다. 하지만 실전에선 후자는 누가 알려주지 않아도 몸으로 익히면 그만이고 뭔가를 추구하는 데 어려움이 없는 반면, 디버깅은 개발자들을 졸졸 쫓아다니는 족쇄같은 것으로 뿌리치기도 힘들고 제대로 알기도 어려운 것이 아닐가 싶습니다.
소프트웨어 개발 분야가 발달하고 번창함에 따라 각종 기술과 개발방법론에 대한 책은 엄청나게 쏟아져 나오고 있습니다. 그러나 그 중에서도 유일하게, 이론으로 정립된 서적이나 문헌이 드문 분야가 디버깅 분야가 아닐까 싶습니다. 최근 들어 테스팅 관련 서적이 드물지 않게 쏟아져 나오고 있어서 이에 대한 갈증을 메워주는 역할을 합니다. 그리고 디버깅 관련서적도 심심치않게 보이는 건 사실입니다.
저희 에이콘에서만도 "리눅스 디버깅과 성능 튜닝", "실전 윈도우 디버깅", "메모리 분석과 활용 제1권", "WinDbg로 쉽게 배우는 Windows Debugging" 등 수 권의 디버깅 관련 서적을 출간했습니다. 도구에 관한 설명이나 실제 코드 예제 등을 들어가며 설명하기에 실전에서 활용하기에 충분한 책입니다. 그러나 제목에서 알 수 있듯이 리눅스나 윈도우 등 특정 플랫폼에서 적용가능한 책인 경우가 많아 전체적인 개념을 익히기에는 뭔가 아쉬운 점이 있었습니다.
이 책 『Debug It! 실용주의 디버깅』은 아무도 속시원히 알려주지 않았고, 개발자들을 여간 괴롭히지 않았던, 이론을 정립하기도 실전에서 제대로 활용하기도 너무 힘들었던 디버깅에 관한 모든 것을 알려줍니다.
1부. 문제의 핵심, 2부. 큰그림, 3부. 디버깅 비급 세 부분으로 나뉜 이 책이 돋보일 수밖에 없는 이유는 이 책의 세부 내용을 구성한 방식에 있습니다.
이 책에서 저자 폴 부처는 난해하고도 어려운 갖가지 디버깅 이론과 실제, 그 철학을 설명하는 데 있어 실전적인 방법을 차용합니다. 우선 저자를 비롯한 개발자들이 현장에서 부딪힌 갖가지 수많은 사례들을 보여줍니다.
일례로 두 가지를 들려드릴까요. 프린터 디바이스 드라이버를 개발한 뒤 출력물에 이상한 가로줄이 생기는 버그를 테스팅 팀에게서 신고 받은 개발자 데이브의 일화. 자신의 사무실에서 아무리 프린트를 해봐도 이상한 점을 발견할 수가 없었고, 테스트 환경과 개발 환경에도 별 차이점이 없습니다. 결국 "사무실 위층에 귀신이 살고 있다"라고밖에 주장할 수 없었지요. 그러나 결국 면밀한 조사 끝에 개발사 사무실 전기 배선에 문제가 있었음을 발견합니다. 전력 문제로도 이런 버그가 발생할 수 있음을 알려주는 재미있는 일화지요.
또 하나의 일화. 마이크로소프트 사 인턴으로 취업해 엄청난 삽질을 한 한 개발자의 이야기도 있습니다. CodeView라는 디버거 팀에서 일을 하며 당시 출시전인 C 컴파일러(마이크로소프트 C/C++ 7.0)의 버그 탐색 과정에 들어간 혈기 넘친 젊은 개발자. 왕성한 의욕으로 몇 천 줄이 넘는 소스파일의 전처리 결과에 대한 버그 리포트를 올립니다. 하지만 일주일 지나 엄청난 노력을 기울인 그의 버그 리포트는 중복 판정을 받게 됩니다. 버그 리포트를 훑어보는 일이 얼마나 중요한지 그제서야 알게 되죠.
이처럼 디버깅이란, 우리가 지금까지 알고 있듯이, 너무 멀리 있지도 않으며 아주 어려운 것도 아닙니다. 수많은 변수가 있을 수 있으며 '등잔 밑이 어둡다'는 말처럼 주변의 사소한 것들에 신경을 쓰면 쉽게 찾을 수 있는 것도 많습니다. 이를 위해 저자는 독자들이 흥미와 호기심을 자아낼 수많은 일화와 사례, 그리고 '조(Joe)란느 개발자의 질문'을 통해 누구나 궁금해왔던 버그에 관한 질문을 재미있게 답해줍니다. 또한 두 줄짜리 핵심 요약을 통해 해당 단락과 절을 요약해 디버깅의 핵심을 알려줍니다.
<조의 질문> 몇 가지
1. 코드에 로그를 남겨놔야 할까요?
2. 비결정적 버그가 왜 문제가 되나요?
3. 일일노트가 디버깅에 어떤 도움이 될까요?
4. ‘땜질 코딩’도 괜찮나요?
5. 꼭 컴퓨터로 버그를 추적해야 할까요?
6. 병목이 없다면 어떻게 하죠?
7. 어떻게 하면 경고를 전부 없앨 수 있을까요? ...... and much more
이처럼 여러분이 궁금해하셨던 내용이 이 책에 모두 담겨있습니다.
<핵심 요약> 몇 가지
1. 디버깅은 반복 과정이다.
2. 소프트웨어의 작동에 영향을 미칠 수 있는 것이라면 무엇이든 소프트웨어의 환경이 될 수 있다.
3. 많은 실험을 빠르게 해보는 게 좋다.
4. 동시에 여러 개를 변경하면 잘못된 결론에 이를 수 있다.
5. 뭐든지 우리가 이해하지 못하는 부분은 잠재적인 버그다.
6. 디버깅은 순간이지만 테스트는 남는다.
7. 고쳤을 때 아무런 효과가 없다면 원했던 부분을 고친 게 아니다.
8. 깨끗한 소스에서 시작한다. ...... and much more
그야말로 재미와 얻을거리의 관점에서 저희 출판사의 '조엘 온 소프트웨어'와 인사이트에서 출간한 '실용주의 프로그래밍'에 버금가는 디버깅의 완전 교본이라고 할 수 있습니다.
고급 소프트웨어 엔지니어로 거듭나기 위해 꼭 필요하면서도 간과하기 쉬운 디버깅 기술. 개발 플랫폼에 무관하게 전문 소프트웨어 개발자가 디버깅에 대해 알아야 할 모든 이론과 지식, 실전 경험을 망라해둔 디버깅의 정석. 저자가 쌓아온 노하우와 디버깅 철학을 이 책에 모두 공개한다!
『xUnit 테스트 패턴』의 번역을 마칠 즈음인 어느 날, 호기 있게 이 책의 출간을 적극 권유해주신 박일님의 이 책에 대한 애정은 매우 깊었습니다. 디버깅 서적 시장이 협소함에도 불구하고, 모든 개발자의 필독서로서 우리 땅에서 반드시 출간해야 할 책이라고 일갈하시는 역자님의 열정에 저희도 설득될 수밖에 없었구요. 번역 출간을 앞둔 지금, 박일님의 주장은 한 치도 어긋남이 없을 것이라 믿습니다.
리눅스든 윈도우든 어떤 플랫폼이든 상관없이 모든 소프트웨어 개발자가 꼭 읽으시고, 자신의 내공을 업그레이드하기에 2% 부족했던 그 간극을 메우실 훌륭한 책으로 자리매김하게 되길 바랍니다.
이 책은 지금 YES24, 교보문고, 인터파크, 강컴, 알라딘에서 예약판매 중입니다.
크리에이티브 커먼즈 라이센스 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.