最近宣传我的书《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意识,产品化工程理念,商用化的务实思想等等,以及对细节的敏感度。
所以,我在这里提请大家关注一点,看待本书,建议不要钻进去看,而是跳出技术看思想,代码不值钱的,值钱的是代码背后的思想,即希望大家关注一个问题,怎么写不重要,但作者本人是怎么想到应该去写这些代码的。
以上是我本人的一点解释和建议,一家之言,欢迎拍砖啊,大家还有问题的话,欢迎提问,我会很高兴就这个话题和大家讨论。