准备的怎么样了当你顺序失败时，所以log会告诉你哪儿出错了吗？以便我可以观察到正在做什么。这尤其在顺序出错时就显得非常重要。一个优秀的顺序员和一个糟糕的顺序员之间的一个不同之处是一个优秀的顺序员会增加日志或其他工具以便在顺序失败时方便调试。所有的顺序都需要某种形式的日志记录建立在之上。

有日志和没日志往往没什么差别。然而，当顺序如同预期的一样工作时。一旦顺序失败，或你得到一个错误的结果的时候，会立即明白优秀的顺序员和糟糕的顺序员之间的差异。

例1让我做一个可调试的版本”，测试关于一个不能正常工作的调用case过来找我检查了日志，然后发现问题貌似出在一个相邻的模块。对其他模块的调用返回值为 空。然后我那个相邻的模块中做了日志记录，重新跑了一遍测试case,比如说。却没有得到任何更多的有用信息。没有任何线索标明为什么会返回空 -难道是下错了参数，或者是某个外部系统导致的失败，那个相邻的模块中是不是存在一个错误，又或者？

得到回答是Oh必需做一个debug版本来看看到底发生了什么”失败！从某种意义 来说，当我去询问负责这块代码的开发人员时。从日志中找到问题所在应该是可能的如果问题存在一个运行的系统中，添加一个调试版本将会有大量的工作要做。代码需要包括足够多的信息在日志，以便你至少可以对失败的原因有一些了解。

例2让我看看我如何走到这里的?有很多可能的路由选择，一个产品在工作时会找到一个短信息传递到手机最便宜的路径。依据手机的当前位置和目标用户所属的运营商。每一个都有一个给定的利息和其他特征。除此之外，可以有一些例外，比如说禁止一些路线，以促进其他路线，通常 会有成千上万的路由被定义，每个case中系统找到最便宜的一个路由，加上限定条件，并且传送消息。

但是认为他应该使用B为什么A会被选择呢？如果没有任何日志记录信息，现在假想某个SMS信息使用A路线传送。只剩下成百个可能的途径，本钱，例外，以及一个复杂的算法，那么祝你好运搞清楚为什么A会被选择。所有可能存在路由以成本大小的顺序罗列在日志中，实现中。当路由被不同的限制条件排除时，排除掉的路由和原因就会被列在log中。随着算法的输入，以及采取的方法信信息列在log中，就会很容易的看出为什么某个路径会被选取。

为什么不是所有的顺序员都会写可调式的代码呢？能想到三个原因：

1.必需足够谦虚的意识到代码会有不按预期工作的时候。相信很多顺序员会对此比较难过。应该确保它会在很多不同场所工作或失败。2.对于每个方案，如果你完全地测试了代码。很自然地加入日志记录，如果你没有测试 那些情况，不太可能会在那里添加记录。但log并没有反馈任何信息给你为什么这里会有一个问题，会有一个很强烈的动机去增加log。3.很多顺序员往往不会在产品系统中修复他自己的代码。如果在线系统中有一个问题。以便下次遇到相同的情况时帮助到

代码可调试吗？对于顺序为什么会失败好的日志信息也不能给你一个确切的信息。可能还是要做出那样的调试版本，当然会有一些情况。但是经常做记录至少还是会提供给你一些隐藏信息关于问题的可能性。