Debug It! 실용주의 디버깅 : 소프트웨어 개발자가 꼭 알아야 할 디버깅의 정석
인터넷 검색중에 우연찮게 이 책에 눈에 들어왔다. 생각해 보면 우연이 아닐 수 있다. 왜냐하면 다른 사람이 만든 앱을 디버깅 하는 중에 이 책을 발견하게 됐기 때문이다. 마침 디버깅에 관련한 책은 한 번도 본 적이 없었다.
저술 의도 : 저자는, 디버깅이 중요하지만 이에 대한 책이 거의 없다는 것을 알고 책을 쓰게 됐다.
저술 목적 : 저자는, 여러 프로젝트들과 동료들로 부터 얻은 디버깅에 관련한 교훈을 독자들과 공유하고 이 책으로 인해 많은 소프트웨어 개발자들이 디버깅을 수월하게 재미있게 할 수 있기를 바란다.
p. 40 @이 페이지에서 힌트를 얻어 나만의 로그 클래스를 업그레이드 하기로 했다.
p. 102 코드 리뷰 받기 -> 자신의 단점을 고칠 수 있거나 위험한 부분을 발견 할 수 있게 된다.
p. 102 코드 리뷰를 누구에게? 언제? -> 규칙은 없다. 여러 번 코드 리뷰를 하지 말라는 규칙이나 언제쯤 하라는 규칙 따위는 없다. 누가 코드를 검토했느냐에 상관없이 리뷰를 한다는 것은 크게 도움을 얻을 수 있는 계기가 된다.
p. 114 선순환 구조 만들기
표준 코딩, 테스트 표준, 문서 표준, 버그 보고/추적 표준, 설계 지침, 성능 요구 사항
p. 126 사용자가 버그를 알려주려 할까요? @사용자의 익셉션(오류) 로그를 서버로 올려 차곡차곡 쌓아 놓는 방법은 어떨까?
p. 137 버그를 고치는 데 얼마나 걸릴지 어떻게 추정할 수 있나요?
-> 불확실 해서 불가능하다. 하지만, 한 주에 몇 개의 버그를 고쳤는지를 기록해 놓으면 그 토대로 얼마나 걸릴지 예상 할 수 있다.
p. 147 버그는 최대한 빨리 찾고, 찾자마자 수정하자. 버그 없는 소프트웨어를 만들 수 있다는 마음가짐으로 행동하되, 실용주의를 가미한 완벽주의를 따르자.
코드의 품질이 나쁠 때 : 은탄환은 없다는 사실을 알자. 기초를 먼저 세우자. 깨끗한 코드를 더러운 코드로부터 격리하고, 계속 깨끗하게 유지하자. 버그 선별을 통해서 버그 데이터베이스의 최상위 버그부터 작업하자. 점진적으로 나쁜 코드에 테스트를 추가하고 리팩토링해 정리하자.
p. 173 보는 눈이 많으면 버그를 쉽게 찾을 수 있다. ( 오픈소스 )
p. 177 이상적인 디버깅 환경 : 자동 테스트, 소스 관리 시스템, 전자동 빌드 시스템
p. 227 프리마돈나 : 일을 잘하고, 관리자에게 신임도 얻지만, 설계나 디버깅이 부족해서, 버그가 난무하는 사람
프리마돈나는 팀을 무너뜨린다.
p. 228 프리마돈나 개선책 : 확실하게 끝내야 끝 / 오염자 부담 원칙 도입. 누구든 버그를 만든 사람이 그 버그를 수정한다.
p. 233 오래되고 녹슨 vs 새롭고 광이 나는
꾸준하게 오랫동안 점차적으로 자신의 자동차를 개발해 나가는 사람이 경주에서 1등으로 치고 나갈 수 있다.
저자는 업무 외에 취미로 자동차 레이싱을 즐기고 있다. 주말마다 자동차의 표면을 닦고, 정기 점검을 하고, 저번 경주에서 생긴 손상을 고치거나 가장 중요한 1/10초를 줄이기 위해 장비를 업그레이드 한다.
지금까지 두 번 정도 자동차를 완전히 처음부터 조립해본 적이 있다. 굉장히 멋진 경험이었다. 몇 년 동안 그대로 놔둬서 중간에 그대로 굳어있는 너트, 볼트와 씨름하면서 더러운 기름 범벅될 거 없이, 번쩍 번쩍하고 딱 들어가는 새 부품으로 작업할 수 있었다. 항상 이렇다면 얼마나 좋을까.
하지만 경주용 자동차는 절대로 '그냥' 빨라지지 않는다. 처음에 몇 번 레이싱을 해보면서 차의 속도를 느리게 만들고 완주를 못하게 만드는 초기 문제(안정화가 아직 덜된 초반에 나오기 쉬운 자잘한 문제-옮긴이)를 계속 찾아서 고쳐야 한다. 이런 모든 문제를 잡아주고 나서야 최고의 성능을 이끌어 낼 수 있다.
꾸준하게 오랫동안 점차적으로 자신의 자동차를 개발해 나가는사람이 경주에서 1등으로 치고 나갈 수 있다.