求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 
软件质量的分层控制方法
 

2010-11-11 作者:王哲 来源:王哲的blog

 

一、质量的相对概念

1、多数比较上进的程序员,都希望自己的代码作品是优雅的、高质量的、别人看到能赞赏不已的。但事实上,紧迫的进度压力使程序员没有太多时间思考,匆忙赶出功能后,赶快测试发布赶快交付给客户。因此有人提出需要重构,有人提出各种测试方法,计算“每千行代码缺陷率”,以追求“零缺陷”为目标。总之多数技术人员认为“质量越高越好”。这里有个典型例子《养成重构的习惯有多重要》,原文和后面的回帖都很有代表性。

2、现在我们假设一种场景,筷子的质量。

首先你到了五星级酒店,它的筷子必须是如象牙般优雅,笔直而对称,没有任何瑕疵斑点,有合适的重量手感,等等,也就是说五星级酒店对筷子的质量要求是很高的,否则客户会发飚。

然后你到了一家路边的快餐店,顺手拿过来一双“一次性筷子”,拆开后发现毛刺很多容易扎手,甚至筷子有点弯曲,但你还是凑合着用了,或者实在无法忍受就扔掉再拿一把,因为这是在路边快餐店,用户对筷子的要求是低的。

如果你把快餐店的筷子卖到酒店里会发生什么情况?质量太低客人无法接受。如果五星级酒店的筷子卖到快餐店会发生什么情况?用户不需要那么好,也不愿意付那么多钱。所以同样做一个筷子,却对质量有不同要求。

所以说:质量是相对的。

3、基于第2点,所以一味追求“高质量代码”,把“高质量目标”凌驾于“企业赢利目标”之上,是多数技术人员所犯的错误。

二、对质量目标进行逐级分解和控制

多数成熟度不高的软件公司会有一定的质量控制方法,但将其用于所有的项目和所有的软件层面。我认为这是一种资源浪费。适度降低对外围层次、用户需求弱相关、使用频度低模块的质量控制,会给项目带来进度和成本上的收益。

比如下面这个案例。这是一个比较成功的网游公司中,项目代码分层控制情况

  层次功能 质量要求 开发者 编程语言 代码开放度
5 任务脚本、战斗剧情、数值设定等外围脚本 逻辑正常,跑起来不会导致程序崩溃就行。手工测试 项目策划组的非编程专业人员,简单培训后即可编写 自定义的、类似python的低难度脚本 所有人可见
4 项目外围代码 详细设计由主程评审,代码未评审。手工测试 项目程序组的非主力人员,多数是普通大学本科毕业生 某种业内标准的脚本语言(商业原因不便透露) 所有人可见
3 跨项目使用的游戏主要逻辑,核心代码。如好友系统、聊天系统、帮派系统等 详细设计由技术总监亲自评审,部份模块有做单元测试. 项目程序组的主力人员,主要由重点大学本科生构成 同上,业内标准的脚本语言 所有人可见
2 跨项目使用的开源游戏引擎,研究/优化/集成/针对特殊需求进行二次开发 技术总监亲自带队,测试方法未知 研究部成员。基本都是211大学硕士或海归,计算机或数学专业 C/C++ 研究部成员及工程项目的经理、程序经理、测试经理可见。其余人员不可见
1 上面3/4层所用的脚本解释器、服务器分布式框架等 技术总监亲自开发和测试。测试方法未知 技术总监和几个创业元老,清一色海归 C/C++ 仅技术总监和公司股东/创业元老,及几个项目经理可见

大家特别注意每个层次的质量要求,从“不使程序崩溃、逻辑正确不使程序崩溃即可”,到“技术总监亲自开发测试,不许别人碰里面代码”分级管理,越是核心部分对代码质量要求越高,从开发人员的级别/背景/资历/审核人员级别/测试方法上可以体现出来。而4和5两层比较外围的代码, 只要实现功能就可以了, 我阅读了这些代码并在其中开发过一小段时间,里面到处充斥着“坏味道”的代码,程序员都是边改边骂,但这并不影响这个游戏有60万的活跃用户和300万以上的注册用户,给公司带来强劲的现金流。而这套对质量进行分级控制的方法,则是技术总监传授讲解给我的。

(表格中代码开放度仅供参考,小公司是输不起的,看看pudn.com上那些把老东家代码拿出来开源的人渣就知道了)

大家知道项目的时间-质量-成本铁三角, 如果把上面5层代码的铁三角列个表格出来,大致如此(我们假设在每个软件层面投入的成本是一致的)

层次 质量 进度 成本
5 5 1 3
4 4 2 3
3 3 3 3
2 2 4 3
1 1 5 3
平均 3 3 3

越是核心层(1层), 其需要修改的代码越少,但是对代码执行的时间和空间开销越小, 稳定性要求越高. 越外围的代码(5层), 针对需求而开发和改动的代码量越大. 选取上表中的1层、5层、平均画图来表示是这样的:

因此,精益求精、重构只适用于靠近核心的代码层;而对于外围代码层, 由于赶工而导致代码质量低、放松测试条件,则是完全合理的。

三、结论

所以,在做软件工程的质量控制时,应该把握软件的关键层面,抓住质量控制的瓶颈。横向而言,就是开发框架、引擎、核心功能之类的层级;纵向而言,就是用户使用频率最高的模块、和竞争对手做差异化竞争的功能等。对于外围代码和次要模块代码,前者一般不容易出错得太离谱(被开发框架限制住),后者使用频度低,则可以适当牺牲质量以求开发速度。

因此,处于外围代码开发的兄弟们就不要成天抱怨、不要提出各种重构要求了。我也曾经在“坏味道”的代码,确切地说是“粪坑”中扑腾,深知其中感受。但就像魔兽世界里组队打某些副本BOSS,有的人职责是拉住BOSS的仇恨(拉住客户),有的人职责是砍BOSS(解决核心模块),有的人则需要群杀不断刷出来的小怪(快速开发外围逻辑)。如果不是这样的配合,那就会团灭;如果不是这样的配合,下个月的工资可能就发不出来,不是吗?

著作权声明:本文由www.Walzer.cn原创,欢迎转载分享。请尊重作者劳动,转载时保留该声明和作者博客链接,谢谢!



论软件项目质量管理
软件质量保证(SQA)
有效的软件质量管理
评审的主要优点
同行评审常见问题解答
软件测试过程和质量的度量
更多...   


CMMI体系与实践
软件开发过程指南
软件开发过程中的质量管理实践
以"我"为中心的过程改进
软件质量管理
量化项目和过程管理


某航空研究所 CMMI体系实践
某知名软件服务商 代码评审
中国气象局 CMMI ML3实践
北京 CMMI体系与实践
电讯盈科 CMMI体系与过程
ADI-美国模拟器件 CMMI实践
更多...