我不喜欢在调试器中调试，因为我认为它通常低于编程语言的抽象层，并且通常不可重现。我赞成在可能的情况下使用单元测试，我认为它们是一种好方法，但实现它们并不总是那么容易。您是否知道避免使用调试器的其他任何替代方法？
答案 0 :(得分：7)
调试器是一个工具，说我想避免调试器就像一个木匠说我想避免锤子。你最好问问题什么时候我应该避免使用调试器？
应避免使用调试器的时间，
我确信有时候使用调试器是一个坏主意，但我的观点是你的问题是错误的。不要问我怎么不使用调试器，而是问我何时/不应该使用调试器。
我的2cents
答案 1 :(得分：5)
想想！ :) - 严重的是，在调试器普遍可用之前，大多数人会通过将大量状态信息写入其输出设备来解决代码问题。它仍然有效。
答案 2 :(得分：4)
答案 3 :(得分：4)
按合同设计，单元测试和这些类型的东西可以帮助您确保代码的块，通常是一个函数，它可以正常工作。这对此有好处，但它不会取代调试。
调试意味着找出为什么代码块不能正常运行。单元测试只能告诉你一个块不能正常工作，它不能告诉你为什么。要找出原因，您必须逐行逐步执行代码，跟踪状态与您预期的不同或逻辑分支意外的位置。要跟踪这些事情，您需要在任何给定时间检查状态。您可以使用print语句执行此操作，使用它们来获取变量状态或推断逻辑分支。调试器是一种可以帮助您在不更改代码的情况下执行这两项操作的工具。
你必须使用其中任何一个。即使单元测试基本上是一个print语句，它会自动检查正确性，只是在不同的粒度级别。
您似乎希望在不查看代码的情况下自行修复代码。您可以根据需要将测试和合同放在代码中，如果这些事情告诉您代码中存在错误，最终您将不得不查看它。如果你想通过输入print语句来检查代码而不改变它，那么剩下的唯一工具就是调试器。除非取得重大突破，否则这就是最先进的技术。
答案 4 :(得分：3)
任何非平凡的应用程序都应该内置某种日志记录/跟踪工具。你希望能够打开/关闭各种输出。
记录所有输入特别有用。如果您可以“回放”输入，那么重现问题要容易得多。
答案 5 :(得分：1)
就个人而言，我自己很少使用调试器。我经常发现，在我到达重要部分之前，我花了太多时间单步，并且通常会弄乱机制。
我最喜欢的调试方法是在战略位置简单地添加print语句。就像，如果计算得出错误的答案，我可能会添加print语句来转储计算中的值。
在Java中，我通常会写类似
的内容System.out.println（“在函数foo：bar =”+ bar +“，plugh =”+ plugh）;
如果问题似乎是程序通过逻辑的路径，我将添加打印“即将进入销售计算块”或“完成写入数据库”或其他任何内容的语句。
当我不知道问题是什么时，我只会求助于调试器，而且我只想通过每一步来查看它出错的地方。
答案 6 :(得分：1)
一个策略是开发一个“调试”模式，其中应用程序公开了几个有用的信息，如使用过的资源，http变量，日志，sql语句等......
例如，我有一个Web应用程序，通过隐藏的输入管理网页状态，并使用xml消息与数据库交互...
当我将“debug = 1”添加到url时，所有隐藏的输入都显示在可折叠的框中，还有执行的xml-in和xml-out ......
更重要的是，在调试模式下，我可以双击页面的某个位置来查看数据库配置信息，还有一个“模拟”用户的快捷方式，以便测试权限......
最后添加的一个是可折叠的框，它显示了构建整个页面的时间，以及访问数据库所花费的时间
在数据库端，我们处理该xml并生成几个sql语句。如果我追加xml标签＆lt; show-sql＆gt; 1＆lt; / show_sql＆gt;而不是执行查询我得到sql语句...所以我可以从SQL控制台“调试”存储过程......
你可以在几天内开发所有这些东西，我可以向你保证它真的有回报......
了解我正在谈论的内容，您可以通过symfony框架查看开发人员前端的证据
http://www.symfony-project.org/book/1_0/16-Application-Management-Tools
让你检查几件事情，比如记录信息，请求和响应内容，执行的操作等......
简而言之，准备好您的应用程序以便轻松检查...
答案 7 :(得分：1)
打印行 tm 我认为是迄今为止最常用的调试方式。
你知道：
log("Starting transaction for client id %s", id )
始终确保使用良好的日志记录框架，否则您的日志将变得无用。