所有的程序都需要某种形式的日志记录建立在它们之上，以便我们可以观察到它正在做什么。这尤其在程序出错时就显得非常重要。一个优秀的程序员和一个糟糕的程序员之间的一个不同之处是一个优秀的程序员会增加日志或其他工具以便在程序失败时方便调试。 当程序如同预期的一样工作时，有日志和没日志往往没什么差异。然而，一旦程序失败，或你得到一个错误的结果的时候，你会立即明白优秀的程序员和糟糕的程序员之间的差别。 例1：“让我们做一个可调试的版本” 比如说，测试关于一个不能正常工作的调用case过来找我。我们查看了日志，然后发现问题貌似出在一个相邻的模块。对其他模块的调用返回值为 空。然后我们在那个相邻的模块中做了日志记录，重新跑了一遍测试case,却没有得到任何更多的有用信息。没有任何线索表明为什么会返回空 -难道是我们下错了参数，或者是某个外部系统导致的失败，那个相邻的模块中是不是存在一个错误，又或者？ 当我们去询问负责这块代码的开发人员时，我们得到的回答是：“Oh，我们必须做一个debug的版本来看看到底发生了什么”。失败！从某种意义 来说，从日志中找到问题所在应该是可能的，如果问题存在一个运行的系统中，添加一个调试版本将会有大量的工作要做。代码需要包含足够多的信息在日志，以便 你至少可以对失败的原因有一些了解。 例2：“让我看看我们是如何走到这里的” ?? 我们的一个产品在工作时会找到一个短信息传递到手机最便宜的路径。依据手机的当前位置和目标用户所属的运营商，有很多可能的路由选择， 每一个都有一个给定的成本和其他特征。除此之外，可以有一些例外，比如说禁止一些路线，以促进其他路线，通常 会有成千上万的路由被定义，在每个case中系统找到最便宜的一个路由，加上限定条件，并且传递消息。 现在，假想某个SMS信息使用A路线传递，但是我们认为他应该使用B，为什么A会被选择呢？如果没有任何日志记录信息，我们只剩下成百个可能的途径， 他们的成本，例外，以及一个复杂的算法，那么祝你好运搞清楚为什么A会被选择。 在我们的实现中，所有可能存在的路由以成本大小的顺序罗列在日志中，当路由被不同的限制条件排除时，排除掉的路由和原因就会被列在log中。 随着算法的输入，以及采取的步骤信信息列在log中，就会很容易的看出为什么某个路径会被选取。 为什么不呢？ 所以，为什么不是所有的程序员都会写可调式的代码呢？我能想到三个原因：
你的代码可调试吗？ 当然会有一些情况，对于程序为什么会失败好的日志信息也不能给你一个确切的信息。你可能还是要做出那样的调试版本， 但是你经常做记录至少还是会提供给你一些隐藏信息关于问题的可能性。 所以，你准备的怎么样了？当你的程序失败时，log会告诉你哪儿出错了吗？ 原文链接： henrikwarne 翻译： 伯乐在线 - hahakaka |
