在软件开发过程中，经常会遇到各种问题和挑战。其中，最令人头疼的莫过于那些在开发过程中没有被发现，却在产品发布后突然出现的“隐形”错误。这些错误往往难以追踪，给开发者和用户都带来极大的困扰。在本文中，将探讨调试器在解决这类问题中的关键作用，以及为什么即使代码编写得很好，仍然需要调试器。
调试器是一种强大的工具，它可以帮助理解代码在执行过程中的具体情况。虽然它们的名字可能暗示它们只是用来“找bug”的，但实际上，调试器的功能远不止于此。通过逐行调试代码，甚至稍微修改一些变量，可以学到很多关于应用程序（或仅仅是一个函数）在做什么的知识。
无论如何，认为调试器是发现“意外问题”的必备工具。这并不是说使用其他技术就不可能找到bug（实际上，这就是在Google工作时需要做的事情）……但是，调试器可能会将一整天的添加日志、审查日志、修改代码、再次运行所有内容，变成一个5分钟的步骤：步入、查看变量状态、可能更改其中一些、找到bug。
在讨论编程时，所说的真正的问题是指“看不见或未检测到的bug”。意思是，在开发过程中，一切似乎都很好。然而，在“野外”（也就是当产品发布到世界上时），一些bug被注意到了。这是最糟糕（也相对最常见）的情况：当产品发布到世界上时，不仅仅有少数几个开发者测试他们能想到的所有可能性。可能有整个世界的人在使用应用程序，做所有未计划和/或意想不到的事情。
回到本文的标题，优秀的开发者有助于避免任何需要调试的情况。在这种意义上，如果有优秀的开发者，就不需要调试器的想法是正确的。只要开发者永远不会犯错，就永远不会需要调试任何东西。但是，如果确实犯了错误，应该怎么做？
甚至有一个故事，和一个朋友讨论优秀的编程，他告诉，在“完美世界”中，所有的代码都会有好的单元测试。回答说，在这样一个完美的世界里，没有开发者会犯错，需要单元测试。
即使有点自相矛盾，整个想法是：如果100%确定代码永远不会导致错误（并且实际上对这种信念是正确的），也许拥有好的单元测试不会有帮助。一切都已经完美了。但是，如果单元测试没有避免问题，至少让代码“调试器友好”……希望项目能够处理一个调试器。
不能为所有语言和所有情况回答这个问题，但对来说，一个好的调试器需要：
嗯……可能还有很多其他需要考虑的事情，但这些都是真正使用并帮助很多的事情。不，单元测试从来没有帮助解决过新bug。它们在避免旧bug重新出现（如果计划得好，可能永远不会存在）方面很棒，但它们不帮助解决现有的bug。
哦……文字可能太严厉了。单元测试确实避免了真正的bug出现，并不是说不需要它们。只是说单元测试是关于“已知可能发生”的bug，即使有可能处理不同的情况（有更好的开发者），它们很少解决“现有bug”或完全“意想不到的bug”……这完全是关于调试器（或者在某些情况下，当事情已经“闻起来”时，进行重大重构）。