权限管理、用户权限系统、开源用户权限系统、信息化建设标准基础数据管理平台
代码改变世界

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

2010-09-03 01:27 通用C#系统架构 阅读(...) 评论(...) 编辑 收藏

 

    

 

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

 

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

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

 

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

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

 



C# ASP.NET 通用权限设计、通用权限管理、通用权限组件、单点登录、集中式权限管理、统一授权体系、分级管理分级授权


微信扫一扫加好友