从日常代码质量检查工作中感受工作中的乐趣、生活的乐趣

测试部经理找我谈话，角色他自己的平时的工作太繁重、而且总是有很多低级的错误反复测试。

软件质量是软件项目、软件产品的根本，软件的编码质量不过关会影响整个软件产品的质量，质量不好就无法按时收款、无穷无尽的后期维护、公司效益提不上来，让人恶心的擦别人的屁股的事情会是无穷无尽的恶性循环，也是整个公司噩梦的开始。

本来质量不好的东西、越维护越脆弱、越维护越没信心、整天会是进入修修补补的恶性循环，是无穷无尽的苦海，开发人员痛苦、测试人员痛苦、实施人员痛苦、产品经理痛苦、老板痛苦、客户也痛苦，大家都没啥好日子过。

想防患于未然、当然是在开发阶段、测试阶段就解决问题，而不是软件产品发布给客户再去进行弥补错误的补救行为。

例如，在开发阶段能修改的错误，例如开发阶段修补错误花费的成本是1个单位来计算，例如1人修改1天的工作量就可以了。

那到测试阶段，可能需要3个单位的时间，才能把这些问题都测试好，因为不只是测试一次就可以解决问题。

最终到了客户手里，特别是到了很多最终客户后，产品发布后要把这个错误进行弥补，可能需要投入的成本就是10个单位，甚至是50个单位。

本来很多问题都可以扼杀在摇篮里的问题，由于但是的开发人员、设计人员思路不严谨、没有相应的检查把关过程，导致大量问题被扩大到测试部、实施部去了。

若测试部的工作很繁重、实施部的后期维护压力很大，很有可能问题的根源发生在 设计、开发人员身上；很多国内的软件公司又难有单独的设计部门，开发部门又担当了设计工作、也同时完成了开发工作，很可能设计不完善不讲、实现也是想当粗糙的。

再由于没有代码质量检查这个步骤，很可能导致最后的错误被放大了。

A（无代码质量检查）:例如有一个软件是耗费了100个工时开发出来的，其中有10个工时的错误没有及时做好，结果拿到测试部，耗费18个工时测试出了6个工时的错误，开发部又反工来修改错误，耗费了6个工时，实施部门拿到客户哪里实施后，发现了另外的4个工时的错误，为了弥补这4个工时的错误，又进行反复测试、反复修正、反复发布给客户，最终又产生了30个工时。

100个工时(开发部) + 18工时(测试部) + 6个工时(开发部修正错误) + 40个工时(实施部实施+测试部测试+开发部修正) == 164工时（总共）

B（代码质量检查）:例如同样一个100个工时的软件，其中有10个工时没及时做好，先代码质量检查，这个几乎是1：1，假设我们耗费了5个工时，事先解决了5个问题的所在，然后开发部门再耗费5个工时，把错误修正好，测试部耗费12个工时，能查出4个工时的错误，开发部继续修正4个工时，那只有剩下1个工时的错误被遗留在软件产品里，这个后期的修正成本应该是10个工时。

100个工时(开发部) + 5个工时(代码质量检查) + 5个工时(开发部修正) +12工时(测试部)+ 4个工时（开发部修正错误） + 10个工时（实施部实施+测试部测试+开发部修正） == 136工时（总共）

虽然我们中间多了一个环节、代码质量检查步骤、但是总的工期却下降了，测试部的工作、实施部的工作都有些减轻了，客户被折腾得更少了，说白了开发部开发人员也被折腾得更少了一些了，虽然代码质量检查是一个多余的步骤一样，但是有一个这样的步骤，大家的整体工作效率反而会提高，从长远来看，也是会明显提高整个公司的产品质量的，有的时候科学的管理、先进的理念就是这么实实在在的硬道理。

164工时与136工时，你可能觉得差距并不是很大，你买同样的房子一个人卖你164万，另一个人卖你136万，你会卖哪个？你愿意支付136万买下房子呢，还是愿意支付给别人164万，买下同样的房子呢？

开发部、测试部、实施部，都希望工作量能减少一些、按时谈恋爱、按时回家好呢？还是每天多加班多工作 164-136/136 == 1/5 的工作量 == 1.6小时/天？

估计没一个人愿意，每天多工作1.6个小时吧？谁愿意维护质量没经过检查的代码？还是质量经过检查的代码？

一方面我们需要努力工作、另一方面我们也要学会用头脑聪明的工作，

要想做好代码质量检查工作：

01：要有比较可行的编码规范，这样可以统一制约大家，否则谁说了算。

02：需要形成一个制度、不是今天想起来了就执行，下个月忘记了就放弃了。

03：大家要有共识、有一个良好的代码质量互查的氛围，每个人都有意识的互相交互检查。

04：连开发部自己的关都没过的代码、何必送到测试部折腾人家、丢人啊，先自己内部检查一下吧。

05：开发人员不止是学会开发程序，还要学会软件项目管理、软件工程周期管理意识。

06：程序如人、程序有Bug与做人人品有点儿问题、脑子有点儿问题、思路有点儿问题是一样的道理，我写出来的软件的质量就是我的人的质量，我怎么可能容忍我的软件有错误？我岂能让别人鄙视我？我岂能让客户用有瑕疵的产品？

07：软件的质量有问题，就像豪华车的方向盘有点儿小毛病、发动机、刹车有点儿毛病是一样的道理，软件绝不允许有任何错误。

08：我的软件有错误，我哪里能吃得下饭？睡得着安稳觉？按时下班回家？我们丢不起那个人。

09：心平气和、用学习的态度、用交流的心态去与同事们进行代码互查工作，不仅提高公司的软件质量、还能促进同事之间的友谊，互相学习优点，大家一同进步。

10: 检查代码也是需要高水平与高境界，不只是需要有这个意识，很多人顾自己也顾不过来，哪里有精力去顾别人？能查出别人代码中的问题需要水平，能说服别人按正确的方式修改、需要更高的境界与能力，不是人人都能做好代码质量检查工作的。

若有这样的心态与价值观，加上我们大家的不懈努力，我们的软件产品的质量只能会越来越好，收款会更顺利、实施部门、测试部门的工作量会减轻，客户对我们的评价也会越来越好，公司的项目也会收款越来越顺利的。

一个人努力做事情很重要，大家正确的努力做事情更重要，能说服同事形成共识、与大家一同用正确的方法做正确的事情更重要。

CMMI、软件项目管理，其中有一个环节讲的就是 代码质量检查、代码质量互查的重要性等，这就是所谓的理论指导实践，通过实践摸索？理论。

CMMI是否重要？的确很重要，CMMI能给我们解决难题吗？但是他从来不是帮我们解决技术上的难题的、赚钱上的难题，只是解决日常管理上的宏观性的难题的。

什么叫工作效率？工作能力？例如让一个人做代码质量检查，查了10天，查了3个人的代码，也没查出什么大问题来，另外一个人轻松查了1天，查了10个人的代码，查出来很多严重的问题，并把如何修改的方法、问题所在的原因等，给这10个人都讲清楚了，这就是工作能力与办事效率的体现，若老板觉得1天就可以查出来蛮多问题，那是否愿意做代码质量检查工作？若10天折腾了也查不出什么大问题，耗时耗力老板是否愿意支持代码质量检查工作？

什么叫人才？能把道理讲清楚、而且能始终坚持这个代码质量检查工作，就算遇到了再大的困难，也始终能坚持这个真理，这就是人才，不是今天想起来了就做做，明天遇到挫折了就放弃，这就不是人才了。

完整的文档，请下载 通用权限管理组件使用说明书V3.0.doc

/Files/jirigala/handbookV3.0.pdf

将权限管理、工作流管理做到我能力的极致，一个人只能做好那么很少的几件事情。

About

吉日嘎拉(蒙古语为吉祥如意)，2000年毕业于黑龙江大学计算机系软件专业，目前定居杭州，典型的IT软件土鳖一个，外号“软件包工头”。

通用权限管理系统组件(GPM - General Permissions Manager)自2003年开始发布，目前是国内注册用户和免费盗版用户最多的权限管理系统，是各种信息管理系统开发中彻底的权限解决方案。本组件支持多种主流数据库（Oracle、sqlsever、db2、mysql），功能强大，使用方便，代码简洁，思路严谨，被广大支持者称为权限管理系统中的“走火入魔级权限管理系统”。

精心维护通用权限管理系统组件（GPM - General Permissions Manager）有8年多,3年的不断推广,20万行经典的业务逻辑积累,经过上万次的调试修正,经历了四百个付费客户,上百软件公司的实战开发。

11年以上开发经验，外企工作5年,上市公司3年,独立经营软件公司2年，主持研发部门管理工作4年以上。

将权限管理、工作流做到我能力的极致，一个人只能做好那么很少的几件事情。



QQ:252056973，Mail:jirigala_bao@hotmail.com

访问者分布


通用权限管理模块的严谨设计定位、精心编码实现、不断维护推广、持续优化改进，主要是为了实现一个可以高度重复利用劳动成果的工具软件并有偿提供给所需的人们，另想成为国人值得骄傲的知名软件功能模块。

可供国内管理类开发人员在日常工作中进行灵活二次开发利用的模块，开发管理类软件的必备工具之一，我们的目标就是让程序员早点儿回家休息。

淘宝店地址：http://jirigala.taobao.com