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

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

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

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

例如，在开发阶段能修改的错误，例如开发阶段修补错误花费的成本是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前台调用源码样例程序源码下载之 --- 数据集权限