第四十二章 修复bug(第 2/3 页)

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

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

    这在业界被称为workaround： workaround - wikipedia。

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

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

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

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

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

    不过……

    有的人敲字灌水都错字连篇，但是有人手写几十上百万字的小说，随便截一段都差不多能进语文课本……

    所以，人与人还是有极大差别的。

    不能因为“linus也写bug”甚至“linus也写过低级bug”，就认为“我写个一百个整数里找最大值的简单程序出三十个bug也是正常的”——初学者搞出这事，正常。

    至于专业人员嘛……出一个都不正常。

    不仅如此。

    既然“写长篇出bug正常，发条短信就那么十几个字，错一个都不应该”；那么我们把长篇拆开成若干章，一章只写三千字呢？再把一章拆开成若干段，一段只写数百个字呢？

    这就是为何写程序要先做模块设计、然后再把模块按职责拆分成类、类按功能拆分成函数、最后还要求一个函数不要超过一屏（大约80行）的原因了。

    经过拆分之后，一个一个函数填写实现、然后再一个一个函数做单元测试，测完再组合起来搞功能测试、集成测试……

    -->>(第 2/3 页)（本章未完，请点击下一页继续阅读）