软件质量的分层控制方法
上一篇 / 下一篇 2012-07-16 10:33:19 / 个人分类：测试经验
一、质量的相对概念
1、多数比较上进的程序员，都希望自己的代码作品是优雅的、高质量的、别人看到能赞赏不已的。但事实上，紧迫的进度压力使程序员没有太多时间思考，匆忙赶出功能后，赶快测试发布赶快交付给客户。因此有人提出需要重构，有人提出各种测试方法，计算“每千行代码缺陷率”，以追求“零缺陷”为目标。总之多数技术人员认为“质量越高越好”。这里有个典型例子《养成重构的习惯有多重要》，很有代表性。
2、现在我们假设一种场景，筷子的质量。
首先你到了五星级酒店，它的筷子必须是如象牙般优雅，笔直而对称，没有任何瑕疵斑点，有合适的重量手感，等等，也就是说五星级酒店对筷子的质量要求是很高的，否则客户会发飚。
然后你到了一家路边的快餐店，顺手拿过来一双“一次性筷子”，拆开后发现毛刺很多容易扎手，甚至筷子有点弯曲，但你还是凑合着用了，或者实在无法忍受就扔掉再拿一把，因为这是在路边快餐店，用户对筷子的要求是低的。
如果你把快餐店的筷子卖到酒店里会发生什么情况？质量太低客人无法接受。如果五星级酒店的筷子卖到快餐店会发生什么情况？用户不需要那么好，也不愿意付那么多钱。所以同样做一个筷子，却对质量有不同要求。
所以说：质量是相对的。
3、基于第2点，所以一味追求“高质量代码”，把“高质量目标”凌驾于“企业赢利目标”之上，是多数技术人员所犯的错误。
二、对质量目标进行逐级分解和控制
多数成熟度不高的软件公司会有一定的质量控制方法，但将其用于所有的项目和所有的软件层面。我认为这是一种资源浪费。适度降低对外围层次、用户需求弱相关、使用频度低模块的质量控制，会给项目带来进度和成本上的收益。
比如下面这个案例。这是一个比较成功的网游公司中，项目代码分层控制情况
大家特别注意每个层次的质量要求，从“不使程序崩溃、逻辑正确不使程序崩溃即可”，到“技术总监亲自开发测试，不许别人碰里面代码”分级管理，越是核心 部分对代码质量要求越高，从开发人员的级别/背景/资历/审核人员级别/测试方法上可以体现出来。而4和5两层比较外围的代码， 只要实现功能就可以了， 我阅读了这些代码并在其中开发过一小段时间，里面到处充斥着“坏味道”的代码，程序员都是边改边骂，但这并不影响这个游戏有60万的活跃用户和300万以 上的注册用户，给公司带来强劲的现金流。而这套对质量进行分级控制的方法，则是技术总监传授讲解给我的。
（表格中代码开放度仅供参考，小公司是输不起的，看看pudn.com上那些把老东家代码拿出来开源的人渣就知道了）
大家知道项目的时间-质量-成本铁三角， 如果把上面5层代码的铁三角列个表格出来，大致如此（我们假设在每个软件层面投入的成本是一致的）
越是核心层（1层）, 其需要修改的代码越少，但是对代码执行的时间和空间开销越小, 稳定性要求越高. 越外围的代码（5层）, 针对需求而开发和改动的代码量越大。选取上表中的1层、5层、平均画图来表示是这样的：
因此，精益求精、重构只适用于靠近核心的代码层；而对于外围代码层, 由于赶工而导致代码质量低、放松测试条件，则是完全合理的。
三、结论
所以，在做软件工程的质量控制时，应该把握软件的关键层面，抓住质量控制的瓶颈。横向而言，就是开发框架、引擎、核心功能之类的层级；纵向而言，就是用 户使用频率最高的模块、和竞争对手做差异化竞争的功能等。对于外围代码和次要模块代码，前者一般不容易出错得太离谱（被开发框架限制住），后者使用频度 低，则可以适当牺牲质量以求开发速度。
因此，处于外围代码开发的兄弟们就不要成天抱怨、不要提出各种重构要 求了。我也曾经在“坏味道”的代码，确切地说是“粪坑”中扑腾，深知其中感受。但就像魔兽世界里组队打某些副本BOSS，有的人职责是拉住BOSS的仇恨 （拉住客户），有的人职责是砍BOSS（解决核心模块），有的人则需要群杀不断刷出来的小怪（快速开发外围逻辑）。如果不是这样的配合，那就会团灭；如果 不是这样的配合，下个月的工资可能就发不出来，不是吗？
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
我的存档
数据统计
- 访问量: 3340670
- 日志数: 1640
- 建立时间: 2011-12-07
- 更新时间: 2019-12-24
