首页 – Woodpecker Wiki for CPUG
以动手实践为荣 , 以只看不练为耻;
以打印日志为荣 , 以单步跟踪为耻;
以空格缩进为荣 , 以制表缩进为耻;
以单元测试为荣 , 以人工测试为耻;以模块复用为荣 , 以复制粘贴为耻;
以多态应用为荣 , 以分支判断为耻;
以Pythonic为荣 , 以冗余拖沓为耻;
以总结分享为荣 , 以跪求其解为耻;
相关问题：
为什么打印（跟踪）日志的调试效力远高于普通的 Debugger 排错方式？ – 编程
回复内容：
日志和 debugger 都是有其优缺点和最佳应用的场景的。合格的程序员应该分清楚自己面对的问题所处的场景，根据日志、debugger 各自的优缺点选择最合适的工具来处理问题。
使用日志来进行调试，在日志输出科学，并且程序员本人对系统熟悉的前提下，找出错误所在的时效性是很高的——很多简单的错误都可以通过日志“秒杀”之，就不用麻烦开动“大杀器” debugger 来重现场景了。现实生产环境下，有一些 bug 是在极端的场景下出现的，自己手动重现的可能性几乎是 0，所以使用调试器去查错也是几乎不可能的。在这个时候，我们可以通
过在可疑代码段挂上日志输出的代码，将代码上下文以及环境信息打到日志中供后续分析。日志能够做到很多 debugger 做不到的东西。
使用 debugger 来进行调试，可以获得几乎最为详细的代码运行时的上下文、环境信息，而且你能够控制程序的逻辑，能够更快地验证自己的猜测，这点是日志很难媲美的。魔鬼在细节中。有时候，日志反映的信息还是不够详细，需要你去”深入此山中“，找到自己想要的细节，这个时候就是 debugger 派上用场的时候了。
日志有日志的好处，debugger 有 debugger 的好处，而且，它们的优缺点基本上是互补的。为什么不两者结合起来用呢？没必要过于绝对地说日志好，debugger 不好，所以就只用日志不用 debugger。“思维绝对化”就像“依赖猜测”一样，是一个合格的工程师最好不要有的性格特点。
讨论还没有完。不要忘记了一个大前提：这句话是出于 Python 社区的。对于动态语言，因为语言本身实现的原因，使用 debugger 来进行调试（甚至实现一个 debugger）往往是一件费力不讨好的事情——进一步地，当一个用动态语言实现的项目的源代码量特别大，代码间关系特别复杂，依赖的环境（例如 web 应用中的缓存、队列，以及各种分布式基础设施等等）不再单一甚至可靠、可依赖时，用 debugger 来进行调试几乎就变成了一件不可能的事情。这个时候 debugger 就显现出了它的劣势了。所以说这一句话还是有一定的道理的——不要忘了抛出这个观点时的场景。当然，这句话的绝对论断，我是不敢苟同的。
最后：我一直相信，没有绝对优和绝对劣的工具。使用工具的是人。聪明的人在合适的场景下让一个为此场景而生的工具发挥效力提高生产力，这才是工具的意义。用螺丝刀钉钉子，然后说螺丝刀不好，是不明智的。为什么要使用日志来诊断问题，而不是使用单步跟踪，是因为：
单步跟踪的前提是已经知道了如何对问题进行复现，然后在重现的场景中进行单步调试，但是很多情况下并没有这个条件。
比如说你的服务端程序挂了，这种bug 10w次query才出现1次，请问如何单步跟踪？
再比如说你写的客户端程序已经发版了，用户告诉你程序闪退，请问如何单步跟踪？
除此以外，使用日志来诊断问题，能强迫你把代码写得更加规范，更加容易理解。
一位著名的计算机科学家说过，好的程序，应该看日志就能对它的运作细节了如指掌 
转载请注明原文链接：打印日志 (log) 是比单步跟踪 (debugger) 更好的 Python 排错手段吗？
