第44章 修复bug（1 / 2）

晚上。

已经和王晓雪收拾好了明天需要带回家的东西之后，叶新晨就打开了曹庆阳发给他的东西。

趁着现在时间还足，所以叶新晨也是准备直接花费一点时间帮曹庆阳给搞定。

打开文件，叶新晨看着这个代码，陷入了沉思，他陷入沉思的原因不是因为这个修复漏洞很难，相反，很简单，叶新晨半个多小时就给他修复好了。

他感觉到的只是修改BUG和找BUG那真的是两个情况。

不过有些人也肯定很疑惑，程出现BUG是必然出现的情况还是程序员水平有限导致的？

这个嘛……仁者见仁，智者见智。

就比如这个——

print(“hello，world.“)

你看，这个“程序”就是没有BUG漏洞的……

实际上但凡有过一点正式开发经验的程序员，写个简单的helloworld都能写出BUG的恐怕不多见吧。

别说helloworld了，一个简单的、不涉及“隐秘”机制的百行小程序，绝大多数资深程序员也可以直接写成0bug。

因为这些实际上是对计算机的原理深度决定的，比如你对计算原理或者语言机制理解越深，对你来说“隐秘”的东西就越少，写出高质量代码的机率就越高。

而且，就像黑土平台里面的交流板块哪怕只是在上敲一篇一千个字的灌水文，有几个可以保证无语法错误、无错别字且标点符号使用正确呢？

尤其这还是在机器替你写字，使得“提笔忘字”“书写错误”之类错误无法存在的前提下：这样你都不能保证全对……

那么不仅大小写敏感、而且逻辑更为曲折复杂、容不得半点含糊的计算机程序呢？

因此，有BUG漏洞那真的是无可避免。

当然还有一种情况，你的程序本身是无bug的；但支持环境比较坑……

这种正常来说不算程序bug，当然实践中，你可能没办法坐等OS或者浏览器等厂商修改——所以结果就是你只好积极行动起来，在自己的程序里为别人的错误擦屁股……

这在业界被称为workaround：Workaround-Wikipedia。

正常来说，workaround是临时的，并且，如果不是诸如0day之类特别关键、刻不容缓的问题，搞workaround往往是出力不讨好的——因为它包含了丑陋，易错，含糊，难以理解；而且等OS或者浏览器等的原始厂商修了它自己的bug，你原本好好运行的workaround往往反而会引起问题。

尤其是，有时候OS或者浏览器厂商修复速度比较慢、致使某种workaround反倒成为“主流技术”；那么当“正统”修复方案和workaround冲突时，OS或者浏览器厂商往往不得不将错就错，以免捣毁那些用了workaround的实现……

这类复杂情况暂不讨论，提它主要是为了说明，搞清楚bug的真正发生点是极为重要的。

修不到bug的根源、滥用workaround，度过的是眼前的难关，牺牲的却是整个项目的稳固性。

类似的，尽量把程序写的“大众化”一点，没有必要不碰新特性，也可以在很大程度上避免“遭遇官方bug”问题——如果你自己理解上再有点偏差，用新特性就和作死无异了。