关于0bug的解释

最近宣传我的书《0 bug ---- C/C++商用工程之道》，很多同学议论纷纷，感觉到书名口气太大，呵呵，0 bug，可不可能嘛，明显是吹牛。

因此，这里特地解释一下：

0 bug，要我这个作者来说，首先是不可能。我本人做了这么久程序，做到最好的成绩是1个bug，3万行代码的一个程序。

不过，我之所以这么提，是认为作为商用程序员，在进行商用工程开发时，会面临很高的质量标准，企业发布的软件产品，从老板的本意上，是希望0 bug的，避免用户投诉，避免不必要的维护成本支出。因此，0 bug，首先我认为是商业程序员一个永恒的追求目标，我们可能做不到，但是我们会尽量去争取。从这个意义上说，我认为提出0 bug的提法，是正确的，起码应该给程序员一个追求自身境界的目标。

其次，我认为0 bug是可以细分的，我们都知道，商用工程，一般分很多阶段，设计阶段，代码阶段，测试阶段，每个阶段都有自己的目标。其实公司设置QA部门，就是希望在软件产品正式推出市场时，尽量达到0 bug的地步。如果一个公司的程序员，做出的产品哪怕再烂，只要有好的QA部门，在上市之前全部检查出来，并修改完成，最终这个产品还是可以称为0 bug的产品的。

因此，其实我们反过来可以得出一个结论，0 bug的产品是可能的，只要有够强悍的QA测试部门，就有可能。0 bug仅仅是分阶段，在前面几个阶段，不太容易做到而已。不知道大家同不同意。大家通常所说的0 bug不太容易做到，我的理解指代码阶段更多一点。

不过，就是这点，我发现一个问题。我学过一点“精品”理论，我认为，改bug是改不出精品的，一个好的商业化产品，从其规划、设计、代码实现、测试、发布、部署，每个环节都应该是精品，最终才有可能得到精品的结果，任何一个环节没有做好，都会造成“短板效应”，最终影响整个产品的市场表现。

因此我强调，程序员不能把任何事情都推给后面的QA测试部，而是应该从自己做起，尽量输出精品的程序设计。要有0 bug的意识，而不能因为有了QA，自己就乱写程序。我写这本书，其实主要就是强调这个问题，即程序员应该有0 bug的意识，一定要争取做到0 bug，否则，就不是一个好的商用程序员，至少，只能算一个不负责任的商用程序员。

当然，要争取0 bug，不能简单喊喊口号，还要有实际的策略。为此，我进行了长达十几年的研究，根据研究结果，我认为，只要总结一些正确的原则、方法和习惯，再配合一些程序员自己实际工作中总结的经典工程库代码，让程序一写出来就有较高的鲁棒性，达到0 bug的程度，其实是有可能的。

我这本书里面，其实很大一部分都在share这些正确的原则、方法和习惯，甚至很多重要的观念，我是上升到世界观程度来强调，就是希望加深大家的认识和印象，帮助大家在以后的工作中少犯错误。同时，我在书中也share了一套自己总结的工程库代码，这些代码以及其背后思想的形成，跨越近十年的时间，确实很不容易，很多经典的工程库代码，我不断翻写，一遍遍的优化，最多的，甚至翻写39遍。因此，希望大家仔细阅读。

为了便于理解，虽然写程序我不强调多加注释，但我写书时，还是尽量加上了详尽的注释，不但要解释怎么做，还要解释为什么，注释与代码比例差不多超过1：2，我想，至少我这一生，没有看过注释这么详尽的代码。

不过提醒大家一点，虽然本书提供了大量工程库源代码，但这个工程库是我个人总结的，主要贴合我过去的开发目标，并不见得适合每个人。因此，我并没有提供直接的代码光盘和源代码下载。这些代码在我看来，其实是写书的另外一种语言，是程序员写给程序员看的一种语言，是用来讲清楚问题的，而不是直接拿来就用的。授人以鱼，不如授人以渔，我希望大家能学习的，是开发工程库的能力，而不是使用工程库的能力，因为我们C和C++程序员，毕竟不是脚本程序员，不能简简单单会用库，而必须会写库。

也有部分朋友谈到，代码规范，无错化设计其实过去已经有很多书和讲座在讲了，我现在旧事重提，是不是有点炒剩饭的感觉。我个人觉得不是。

根据我的经验，代码规范，各家公司基本上有，没有的，抄也要抄一个过来摆着，但是，实际上能用起来的，大家想想，能有几个？这种没有实用性的代码规范，其实意义并不大。

另外，现代工程开发，和几十年前C语言刚刚诞生时已经有很大差别，现在是并行开发的世界，很多程序一上来，就是多任务、多线程的并行开发，而并行开发下，有很多禁忌、限制，过去在单任务环境开发的代码规范，未必实用，必须修改。过去很多无错化的设计原则，也是如此。

举个简单例子，从上世纪80年代开始，模块化，结构化程序设计思想开始深入人心，goto语句很多时候，被建议不要再使用了，这在相对简单的单任务模型，问题不大。但是，在多任务环境下，由于动态内存分配，进出锁域等大量二元动作的存在，对于程序跳转的精准控制需求甚至达到了一个“变态”的地步，此时，break、continue等传统结构化程序建议的，用来替代goto的语句，反而还没有goto好用。这就需要再改回来，但很多人显然没有转过这个弯来。

因此，我在书中特别强调不要自我设限，不要有思维框框，要客观，要务实，就是指在这些细节的原则把握上，很多时候，如果程序员不能根据具体情况灵活机动采取应对策略，程序根本就写不下去，死板僵硬地强调结构化，最终只能导致程序复杂度直线上升，最终超出程序员脑中的“堆栈”，使程序开发不可控，bug自然也就随之而来。

还有一个问题也请大家关注，就是过去我看过很多关于减少程序bug的学习资料，但很多是程序员的角度写的，因此，文中技巧很多，对于规律的总结归纳很少，上升到原则和思想的就更少了，而结合到团队开发，帮助整个团队减少bug的，根本没有。这样的问题就是，哪怕学会了这些技巧，程序员最多仅仅是熟练工，而不是一个合格的商用程序员。

前面我们讲了，商用工程包含前期的系统分析、规划和设计环节，如果这些环节出了问题，后面的程序哪怕再正确，商用产品也会失败，这种设计上的bug，其实比程序bug更加可怕。我本人就亲眼见到，一个交换机产品，一百多人研发一年半，最后无法上市，项目终止，公司损失差不多一个亿人民币的事例。原因很简单，就是前期的系统分析出了问题，核心芯片选型有误，当产品快上市时，该芯片停产。大家说可惜不可惜？

因此，我在书中从头至尾强调务实，强调系统化、商业化、产品化思维理念。我希望大家能理解，进入企业，成为一个商业程序员，你的命运其实就是和公司绑定在一起的，仅仅强调自己的程序没有bug，是没有意义的，一个团队哪怕一个人做不好，一个产品设计流程哪怕一个环节做不好，最后产品、项目都可能失败，因此，要做到0 bug的商用程序员，不但要关心自己的程序，还要关心团队伙伴的工作，要尽量帮大家查漏补缺，尽量提供最优质的服务给团队，最终才有可能实现盈利目标。

我想，本书强调的0 bug标准，可能比大家通常认为的0 bug会高一点，简单说来就是，最终产品卖到钱了，才能算作0 bug。

最后还是要说一点建议，在我看来，虽然我在书中share了大量的工程库代码，以及大量的经验，但是要我自己来评价，这些都不值钱。 因为我觉得这些仅仅是技术，既然是技术，就有过时的一天，既然是技术，就不难掌握，只要有心，多想一点，其实很容易就想出来了。

我本人真正看重的，其实是技术背后的思想，这包括0 bug意识，产品化工程理念，商用化的务实思想等等，以及对细节的敏感度。

所以，我在这里提请大家关注一点，看待本书，建议不要钻进去看，而是跳出技术看思想，代码不值钱的，值钱的是代码背后的思想，即希望大家关注一个问题，怎么写不重要，但作者本人是怎么想到应该去写这些代码的。

以上是我本人的一点解释和建议，一家之言，欢迎拍砖啊，大家还有问题的话，欢迎提问，我会很高兴就这个话题和大家讨论。

=======================================================
在线底价购买《0bug-C/C++商用工程之道》
（直接点击下面链接或拷贝到浏览器地址栏）
http://s.click.taobao.com/t_3?&p=mm_13866629_0_0&n=23&l=http%3A%2F%2Fsearch8.taobao.com%2Fbrowse%2F0%2Fn-g%2Corvv64tborsvwmjvgawdkmbqgboq---g%2Cgaqge5lhebbs6qzlfmqmttgtyo42jm6m22xllqa-------------1%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2C18%2C19%2C20---40--coefp-0-all-0.htm%3Fpid%3Dmm_13866629_0_0
肖舸