当你习惯了测试驱动的开发(Test-Driven Development,TDD)之后,你会发现自己越来越少地使用调试器(debugger)——如果你发现程序里有什么问题,你不应该用调试器去抓bug,而是应该用一个单元测试用例来揭示问题的所在。由于存在细粒度、完整覆盖的单元测试用例,每个bug都相当清晰,于是很少会需要各种巧妙的调试手段了。
——————————
Summary
As debuggers have grown in power and capability, they have become more and more harmful to the process of software development.
Debuggers have become immensely powerful. A good debugger is a very capable tool. With it, an experienced developer can step through very complex code, look at all the variables, data structures, and stack frames; even modify the code and continue. And yet, for all their power, debuggers have done more to damage software development than help it.
Since I started using Test Driven Development in 1999, I have not found a serious use for a debugger. The kinds of bugs I have to troubleshoot are easily isolated by my unit tests, and can be quickly found through inspection and a few judiciously placed print statements.
I teach a lot of classes in C++, Java, C#, TDD, XP, Patterns, etc. In those classes I often have the students write code. It is not unusual for me to find a student with his or her nose buried in a debugger, painstakingly stepping from line to line, examining variables, setting breakpoints, and generally wasting time. The bug they are tracking could be found through simple inspection of the code.
I consider debuggers to be a drug -- an addiction. Programmers can get into the horrible habbit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort. Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just rewriting the offending code, *then* you may need a debugger.