程序员需要知道的97件事情之----- 在指责其他原因前首先请检查自己的代码

   本人英语抄过4级，奇烂无比，翻译这个实属蛋疼，错误是肯定有的，而且是翻不出出来就是随便猜，欢迎指出，谢谢啦。但愿我能够翻完我看的懂的....
   原链接：oreilly的程序员需要知道的97件事http://programmer.97things.oreilly.com/wiki /index.php/Contributions_Appearing_in_the_Book

   程序员们， 包括我在内的所有人！经常有怀疑自己的那部分代码被破坏的疑惑。这一般是不可能的。如果发生一次，也可能是编译器破坏的。
  事实上，代码被编译器，DB，应用服务器，内存管理器BUG破坏的概率低到不能在低了。使得，它们存在BUG，但是他们的发生的概率使得我们安全可以忽略它。

   我曾经也遇到过一次编译器优化循环遍量的BUG，但是我想象了很多种编译器或者操作系统的BUG，我在处理的过程中浪费了大量的时间，可是每次都仅仅发现自己的愚蠢，因为每次最后都发现时我自己的错误。

  假设工具被广泛的使用，成熟之后在各种技术中使用，他们不应该被经常怀疑。当然，不如这工具还是初期版本，仅仅在小部分人中使用，很少下载量，比如0.1版本的BETA开源软件，他们可以成为怀疑的对象。（公平的说，内测的版本都是可以被怀疑的对象）

    鉴于工具或者底层平台之类的基础发生BUG的概率可以忽略，这样我们就该把更多的精力放在代码的调试上面，通过测试和debug；来发现问题。通常的debug建议有：隔离错误问题，围绕问题进行测试。检查调用约定，共享变量，版本号等，找出中断栈和变量类型不匹配；试着让代码在不同的机器上运行或者不同的配置环境下，debug或者发布等等。

   怀疑你自己的设想和他人的设想，不同的厂商的工具有不同的构建方式---所以最好可能在开发中用同一家厂商的各种不同的工具。

  当他人报告了你没有遇见过的问题，去看看他人的解决方案，他们可能提供你从来没有想过的解决方法，这对你很有帮助。

   作为一个我个人的习惯： 如果我有一个我不能解决的BUG，我会想像我是编译器，是时候去寻找混乱的栈。如果我们加入调试跟踪代码，让错误出现，这样看起来很真实。

   多线程的问题是引起BUG的另外一个源头，这让机器很头疼的问题。所以的建议都是当系统是多线程的时候，让代码尽量简单。Debug和单元测试很难发现多线程的问题，所以设计的尽量简单是非常重要，这对于我们查找错误还是很有帮助的。

    所以，在你指责编译器犯错的时候，记住Sherlock Holmes的忠告：排除你确认的不可能发生的问题，不管保留下来是的什么东西，也不管有多么的不可能，一定要坚信，这就是真相！。
By  Allan Kelly