做一个编写可调试代码的程序员

所有的程序最好能够以某种形式的日志记录下来，这样能方便我们即时知道现在在做什么。而且一旦出现异常，其重要性就愈加明显了。我们之所以要把程序员分成三六九等，很大一个原因就是，一个伟大的程序员会去写日志和调试工具，这样一旦出现问题就能调试程序。

如果程序运作正常，那么可能写不写日志没啥区别。但是，不怕一万就怕万一，万一程序崩溃或者出来一个错误的结果，那么这个程序员好不好马上高下立现。

例1：“我们先搞一个调试版本吧。”

举个例子，测试人员跑来告诉我说有一个调用函数不工作了。我们先查看了日志，然后发现原因可能出在相邻的模块上。调用这个模块返回的却是一连串null值。当我们查阅相邻模块的日志记录并重新运行测试时，却没有获得任何有用的信息。对于为什么会返回null毫无头绪——不知道是参数错了，还是外部系统出了故障，亦或是相邻模块有bug，Who knows？

当我们去咨询负责该段代码的开发人员时，他们的回答是：“这个简单，我们先搞一个调试版本吧。”最终往往还是不行！因为我们根本不知道是哪里出了问题，出了什么问题。而且要是已经到了生产阶段，增加调试版本就意味着增加更多额外的工作。代码的日志里面得包含足够多的信息，以便于一旦出现问题我们可以找到解决的关键所在。

例2：告诉我我们应该怎么做

我们产品的一个作用是为SMS（短信）找到成本最低的途径并将路径传达给相应的手机。由于当前手机的位置以及用户所属的运营商的不同，理论上存在着很多很多的可能路径，而且每一条路径都有一定的成本和相应的优缺点。此外，还会有各种意外会导致不得不禁止某些路径或者加重某些路径的权重。系统通过给定约束条件，搜索到最便宜的路线然后返回提供给SMS。

现在，假设某短信建议使用路径A发送，但是我们认为路径B更好，那么路径A又是怎么被选上的呢？如果没有日志资料，光看那可能的成百上千条的线路，看它们的成本和复杂的算法，我想我会疯掉。幸亏日志里给出了之所以选择路径A的原因。Thank Godness！

日志里面包含了所有可能的路线，并按成本进行排序。哪怕是由于条件限制而淘汰的路线也会列在日志里，并附上之所以淘汰的原因。总之，在日志里会将如何把所有信息输入到算法中以得出结论的各个步骤描述得一清二楚，以便于我们知道为什么要选择相应路径。

为什么不愿意写可调试的代码？

既然好处大大的，那么为什么不是所有的程序员都愿意写可调试的代码呢？原因有三：

1.得有足够的自知之明，能认识到万一程序发生异常的情况。不过很多程序员往往要经过很长一段时间才会明白“老子并非天下第一”。

2.彻底地测试代码才能保证它能在各种场景下都能正常运作。而且每个场景都要写日志。如果不都测试一下，那你怎么知道哪里需要添加记录。

3.很多程序员往往对自己的代码做不到精益求精。如果在现场演示的时候系统出了问题，但是在日志里又看不出是为什么，那么最好能在日志里加点什么，以防下次再碰到类似的情况。

你的代码是可调试的吗？

当然也会有这样的情况，那就是日志写的很好，但是你还是不知道问题的关键原因。这时候，你可能还是得创建一个调试版本。但是你的日志最最起码得能给出问题的线索。

最后，请问大家，你的代码是可调试的吗？当代码出现问题，你的日志能告诉你是怎么回事吗？