责怪他人前,先检查自己的代码

原文链接

开发者——至我们所有人!是否经常焦虑自己的代码被否定。不存在的,就算有,也肯定是编译器的错。

而实际情况是一段代码出错几乎(一万个几乎)不可能是由于编译器、解释器、OS、应用服务、数据库、内存管理器,或任何系统级的软件导致的。你信或者不信,bug就在那里,只是没你想的那么普遍。

我有次是真遇到这种情况,编译器错误地优化了循环变量,但在此之前我已经在脑瓜里意淫过无数遍(就是编译器的错)。我浪费了大把的时间,都把时间花在意淫里,然而事后证明就是自己的错时,又感觉自己多么愚昧。

假设一个工具被广泛使用,且成熟应用于各技术栈当中,那只可能有很少的情况下应该去质疑它的质量。当然,除非它刚发布,或者用的人很少,再或者下载量小,0.1版本,开源软件等情况下,确实有可能找到很多质疑点。(同样,商业软件的alpha版本也会被质疑)。

编译器级别的bug如此罕见,你其实可以更好地花时间和精力去找到错误,而不仅仅是为了证明是编译器的错。利用所有可用的调试手段,隔离问题,存根调用,包围式打击(测试);检查所有调用约定、共享库、版本号;和别人解释;找出堆栈破损以及变量类型不匹配的地方;尝试在不同机器及不同构建配置中重新跑这段代码,比如debug和release版本;

质疑你自己的假设和他人的假设。工具出自不同厂商之手,就会有不同的情景假设来构建它们——同一个厂商的不同工具也可能。当其他人在报告这个问题你就没必要重复了,去看看他们在做什么。他们可能正在做一些你从未想过或不按套路走的事情。

如果有bug却无法定位问题的时候,个人往往会认为问题出在编译器,并把时间用来查找堆栈破损。如果经过跟踪调试后解决了该问题,那就确定无疑了。

其他代码中的bug引发的多线程问题可以把你头发都急白了。所有建议都赞同,简单的代码在多线程系统里将变得不简单。调试和单元测试在查找一致性错误时会变得不可靠,所以请保持简单朴素的设计。

所以,先别急着去怪编译器,记住夏洛克·福尔摩斯的一句话:“排除一切不合理,无论剩下什么,无论多么不可能,那就是真相”。更喜欢Dirk Gently的另一句话:“排除一切的不可能,无论剩下什么,无论多么不合理,那就是真相”。

0%