所有程序都需要某种形式的日志记录构建在它们之上，以便我们可以观察它在做什么。当程序出错时，这一点尤为重要。好程序员和坏程序员的一个区别是，好的程序员会在程序失败时添加日志记录或其他工具以方便调试。当程序按预期运行时，记录和不记录通常没有区别。然而，一旦程序失败，或者你得到一个错误的结果，你马上就会明白好程序员和坏程序员的区别。示例1：“让我们制作一个可调试的版本”例如，我收到的测试是关于一个无法正常工作的调用案例。我们检查了日志，发现问题似乎出在相邻的模块中。对其他模块的调用返回NULL。然后我们登录那个相邻的模块并重新运行测试用例，但没有得到任何更有用的信息。不知道为什么它会返回空值——可能是我们传入了错误的参数，还是某个外部系统导致了失败，相邻模块中是否存在错误，或者其他原因？当我们去询问负责这段代码的开发人员时，得到的回答是：“哦，我们必须做一个调试版本，看看是怎么回事”。失败！从某种意义上说，应该可以从日志中找到问题，如果问题存在于正在运行的系统中，添加调试构建将是一项大量工作。代码需要在日志中包含足够的信息，这样你至少可以对它失败的原因有所了解。示例2：“让我看看我们是怎么到这里的”??我们的一款产品找到了一种方法，可以在手机工作时向其发送短信***。根据手机的当前位置和目标用户所属的运营商，有许多可能的路由选择，每个都有给定的成本和其他特征。此外，还可以有一些例外，例如不允许某些路由提升其他路由。通常定义了数千条路线。在每种情况下，系统都会找到最佳路线，加上限制条件，然后传递消息。现在，假设某条短信是使用路由A发送的，但我们认为他应该使用路由B，为什么会选择A？在没有任何日志记录信息的情况下，我们只剩下数百条可能的路径、它们的成本、异常和一个复杂的算法，所以祝你好运，找出为什么选择A。在我们的实现中，所有可能的路线都按成本顺序列在日志中。当一条路由被不同的约束条件排除时，日志中会列出被排除的路由及其原因。有了算法的输入，日志中列出了所采取步骤的信息，很容易看出为什么选择了某条路径。为什么不？那么，为什么不是所有的程序员都编写可调代码呢？我可以想到三个原因：1.你必须足够谦虚，意识到你的代码不会按预期工作。相信很多程序员都会为此感到难过。2.如果你彻底测试你的代码，你应该确保它在许多不同的情况下都能工作或失败。对于每种情况，添加日志记录是很自然的，如果您没有测试这些情况，则不太可能在那里添加日志记录。3.许多程序员倾向于不在生产系统中修复自己的代码。如果在线系统出现问题，但日志没有给你任何关于为什么会出现问题的信息，你将有强烈的动机增加日志以帮助你下次遇到同样的情况。你的代码可调试吗？当然，在某些情况下，好的日志消息不会为您提供有关程序失败原因的确切消息。您可能仍然需要像那样进行调试构建，但您将始终进行日志记录，至少为您提供一些有关问题可能性的隐藏信息。那么，你准备好了吗？当您的程序失败时，日志是否告诉您出了什么问题？原文链接：henrikwarne翻译：伯乐在线-hahakaka翻译链接：http://blog.jobbole.com/61732/
