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

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



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

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



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

例如，在开发阶段能修改的错误，例如开发阶段修补错误花费的成本是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



导读：
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 如何控制用户显示的菜单权限
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 在页面中的调用权限讲解
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 数据集权限的调用权限讲解
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 分级管理
疯狂.NET 通用权限设计 C/S后台管理，B/S前台调用源码样例程序源码下载之 --- 操作权限
疯狂.NET 通用权限设计 C/S后台管理，B/S前台调用源码样例程序源码下载之 --- 角色权限
疯狂.NET 通用权限设计 C/S后台管理，B/S前台调用源码样例程序源码下载之 --- 数据集权限



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

posted on 2010-09-03 01:27 吉日嘎拉 不仅权通用权限 阅读(2741) 评论(22) 编辑 收藏

评论

1909500

#1楼 　回复　引用　查看　 Code Review
从制度、制度培训、人工检查到自动检查，有意思。

2010-09-03 07:31 | 个人知识管理

#2楼 　回复　引用　查看　

补充一点：
如果是软件项目，做得越好，一般越没钱赚（当前国内的大环境而言，不管是ZF项目，还是企业项目）
2010-09-03 07:32 | 个人知识管理

#3楼 　回复　引用　查看　

在国外，在领导心中，速度永远是第一位的，质量虽然也很重要，但是领导们的都很短位，我们单位最近做了解个900万的项目，质量不好，接下来的几年，估计是不止尽的维护。
2010-09-03 07:39 | K·T

#4楼 　回复　引用　

100个工时(开发部) + 21工时(测试部)+ 7个工时（开发部修正错误） + 40个工时（实施部实施+测试部测试+开发部修正） == 161工时（总共）
2010-09-03 08:39 | ..[未注册用户]

#5楼 　回复　引用　查看　

软件行业要走出作坊式，需要从源头上提高代码的质量，要走出浮躁的心态
2010-09-03 08:40 | marr

#6楼 　回复　引用　查看　

做什么软件都会遇到不可预知的错误..没有那么绝对的时间..
只有控制时间范围...
2010-09-03 08:42 | 小刚qq

#7楼 　回复　引用　查看　

让开发人员代码检查，更多的是只是注重表面，更多小的细节不会被检查出来。只能让代码少出现问题，但不能保证程序不出问题。更多的问题还是需要专业的测试人员才能更好的发现
2010-09-03 08:44 | 风游西瓜

#8楼 　回复　引用　查看　

我愿意做CodeReview,持续集成，可是还没这个环境。在国内哪有那个自由的彼岸呀？！
2010-09-03 08:53 | ITLOVER

#9楼 　回复　引用　查看　

说到容易做到难，希望你带领的团队能按照这个思路顺利进行
2010-09-03 08:57 | 专业评审

#10楼[楼主] 　回复　引用　查看　

@专业评审

这些年，我也遇到了很多困难，但是一直在坚持这个 代码检查 工作的，从来没放弃过。

2010-09-03 09:24 | 吉日嘎拉 不仅权限管理

#11楼 　回复　引用　查看　

我想起早先杂文上一个笑话，说植树节领导去种树，新来的同事都很不理解，因为树种的东倒西歪的，根本活不下去，于是就问领导，领导说，你懂个X，如果今年这树种好了，明年到哪种去？

还有一个说法是，如果今年种好了，那明年种树的地方会比这还远。

类似腐败问题，当年满清人入关那会对于大明朝遗留的官员，也只能是睁一只眼闭一只眼而已。
2010-09-03 09:37 | aspnetx

#12楼 　回复　引用　查看　

引用ITLOVER：我愿意做CodeReview,持续集成，可是还没这个环境。在国内哪有那个自由的彼岸呀？！
可以从自己做起，从而影响别人
2010-09-03 10:10 | 涉谷猫猫

#13楼 　回复　引用　查看　

我搞不明白，文章说的很有道理啊，还有人反对，为什么总是有人跟你过不去啊.......我觉得这类人要么才出来时间不长，要么本身就没达到一定的阅历。
做技术的如果那么自负的话，估计这辈子就这样了 ，连包容的胸怀还没有还能做好Teamwork么。

2010-09-03 10:16 | Ringgo.Yao

#14楼 　回复　引用　查看　

Code Review 很重要，除非做的东西是一次性的东西
2010-09-03 10:37 | oec2003

#15楼 　回复　引用　查看　

一个公司真若做到每个阶段的代码Review,那这个公司一定会做大,做好.
2010-09-03 10:47 | sinfiasong

#16楼 　回复　引用　查看　

没办法,都是先做吧,最后再改吧.然后就....时间一天天过去
2010-09-03 10:55 | thestarmm

#17楼 　回复　引用　查看　

测试部经理找你谈话的原因是因为作为开发部的头头或者重要开发人员，你的代码被他测出很多问题？
还有你左侧的列表太长了，每次的博文标题都超长。
2010-09-03 13:43 | 兆子

#18楼 　回复　引用　查看　

贱人又发什么垃圾贴，见你一次就想骂一次
2010-09-03 14:37 | 冰品羽扇

#19楼 　回复　引用　查看　

@sinfiasong
坚决赞同，不过国内这样的公司真是凤毛麟角.....
2010-09-03 15:49 | 镜涛

#20楼 　回复　引用　查看　

支持吉日，说的很有道理。如果每个人都有好的心态，好的意识，估计软件产品也就不会有那么多bug了。
2010-09-03 17:27 | John Liu

#21楼 　回复　引用　查看　

吉日哥，就是我们程序员的“灵魂导师”，多么的朴实、真诚。
2010-09-06 12:04 | 不觉流年似水

#22楼 　回复　引用　查看　

@K·T
但愿数据库设计能更合理、程序架构搭建能尽人意，否则好痛苦啊。