第七章_敏捷调试_34 警告就是错误

1. 问题是什么？

当程序中出现一个编译错误时，编译器或是构建工具会拒绝产生可执行文件。工程师别无选择——必须要修正错误，才能继续前行。

可是，代码编译的时候，出现的警告怎么办 ？

警告是另外一种情况，我们还可以继续运行程序。那么忽略警告信息，会导致什么状况呢？这样做等于是坐在一个嘀嗒作响的定时炸弹上，而且它很有可能在最糟糕的时候发生爆炸。

有些警告可能是过于挑剔的编译器的良性副产品。可是，有些并不是。

2. 恶魔的方案

编译器的警告信息只不过是给过分小心和过于书呆子气的人看的。它们只是警告而已。如果导致的后果很严重，它们就是错误了，而且会导致无法通过编译。所以干脆忽略它们就是了。

3. 天使的方案

• 将警告视为错误

代码不应该产生任何警告信息

方法：要找一种方式让编译器将警告作为错误提示出来。如果编译器允许调整警告的报告级别，那就把级别调到最高。

这个方法，可以大大提高源代码的代码质量。

编译器可以轻易处理警告信息，可是你不能。

4. 切身感受

警告给人的感觉就像······哦，警告。它们就像某些问题给出警告，来吸引软件工程师的注意。

5. 如何平衡？

• 编译器的bug或者第三方工具或代码的原因，有些警告无法消除。如果没有对策，就不要浪费时间了。但这种问题发生概率极低
• 应该经常指示编译器：要特别注意将无法避免的警告作为错误进行提示，这样就不用费力去查看所有的提示，以找到真正的错误和警告。
• 弃用的方法被弃用是有原因的。不要再使用它们了，至少，安排一个迭代来将它们安全地移除掉。
• 如果将过去开发完成的方法标记为弃用方法，要记录当前用户应该采取何种变通之策，以及被弃用的方法将会在何时一起移除。

6. 总结

夫子曰：上医治未病。

编译代码产生的警告信息，没有危险的，那是我们幸运！

如果是有bug的警告，绝对够你喝一壶。因为它藏在隐秘的角落，根本就不在你得考虑范围之内，也不在你设计的控制流，数据流之内。因为这个bug是出现在将源代码转换为机器代码的过程中的，或者在运行过程的。反正，绝对在你的意料之外！

这种bug，排查的难度，还有项目如果很赶，或者在量产，或者服务上线的时候出现这种问题，你得工作强度可想而知。估计要修养两三个周。

解过bug的码农，都不会想碰到这种在意料之外的bug。

这个活动肯定是大牛遇到此类问题之后，血与泪般的教训。

还是听大牛的话吧，好好处理警告信息，治病于未然！这才是敏捷调试的真谛。
注：文中斜体部分文字为引用书中内容