“品质在于构建过程”吗?

今天在微博上看到几位敏捷爱好者探讨敏捷测试和质量保证问题,我忍不住也加入了讨论:

 

Z先生原帖:我刚才看到一个大会演讲稿,谈到敏捷测试六大指导原则:1.仅靠测试人员不可能获得高质量的软件,质量是整个研发团队的责任;2. 场景是不可穷举的,测试活动必须是风险驱动的,关注于高风险的场景;3.分层自动化测试是唯一出路;4.在正确的位置进行恰当的测试是自动化的关键;【待续】

S先生回复:品质在于构建过程。检验贯穿构建过程,提供及时反馈。

我回复:什么样的构建过程才能出Unix这样的品质呢?迭代?快速反馈?TDD?

S先生回复:据说stroustrup听到重构时的反应是,我们从七十年代就这样做了。推荐《UNIX编程环境》,了解大师的编程方式。

我回复:您偷换了概念。不能说大师用了重构,C++和UNIX的品质就是靠重构或某种构建过程得来的。厨师做菜用到了勺子,不等于菜好吃是因为勺子。

S先生回复:我没有概念。我们看到一个果,就问因是什么。其实是泛因果,无因果,一切是机缘凑巧。

我回复:“品质在于构建过程”难道不是一个明白的因果描述吗?

S先生回复:品质在于构建的人。我说话时没因果,你看到了因果。

我回复:欢迎敏捷爱好者围观!

 

很高兴几个回合讨论下来S先生修正了先前“品质在于构建过程”的观点。什么重构、TDD、迭代、快速反馈等等构建过程都不是Unix品质的核心要素。我不但不认同“品质在于构建过程”、“测试是最好的设计方法”这类机械式的观点,而且也不满意把软件优劣归结于“人是根本”的简单回答。我们需要探索一个既非机械式的,也非简单地归结为某种理念的更深刻的答案。

 

像Unix这样优秀的软件,真正的核心要素到底是什么呢?我的答案是:模型,即人心中的软件。在看得见、摸得着之前,Unix的品质就已经存在于设计者的心中了,他们不会在Unix诞生后惊讶:“哇,Unix的稳定性这么好,7x24小时运行,从来不蓝屏”。模型一定是设计者心中最美的东西,为什么我们阅读操作系统源代码会像进入迷宫一般理不清头绪,而作者自己却觉得头头是道呢?因为作者早已“胸有成竹”,我们以为他几十万行代码敲很辛苦,实际上在他自己看来是按部就班一步步向目标靠近。

 

模型是软件的灵魂,存在于设计者的心中,而软件的构建过程正是心中的世界向现实世界逐渐投影。模型可以是完美的,而现实却非完美,或许有时候我们很幸运地到达了,或许有时候我们不得不向现实妥协,改变心中的世界。试图制造灯泡的爱迪生可能会一时找不到熔点极高的发光金属而止步不前,企图制造永动机的人则根本无法实现。在不完美的现实中,我们明明想的是a+b,却敲成了a-b;我们以为某个API可以很快返回,没想到却等了5秒钟,为了不阻塞用户不得不改成了异步。Review、测试等构建过程在一定程度上弥补了现实的不完美,并对模型给予了反馈,但它却无法决定软件的特质。如果设计者心中没有Unix,即使每个实现环节都层层检验,拥有光速般的反馈,他有怎么能构建出Unix呢?Windows NT内核和Windows 3.1内核的品质差别不在于微软采用了两种不同的构建过程,而在于它们采用了不同的内核模型。灵魂与躯体的差别就在于此!虽然对于普通的软件开发通常有不少成熟的模型供选择,并不需要总是创造自己的模型,但理解模型间的差异,并在设计时选用恰当的模型仍然比采用某种构建过程更加重要。服务器架构采用Nginx似的异步IO模型,还是采用Apache似的每个请求一个线程的模型远比开发是否采用了TDD更为重要。

 

模型的产生是柔性的,主要源于灵感;过程的执行是刚性的,主要源于逻辑。苹果砸在牛顿的脑袋上能砸出万有引力模型,砸在我们脑袋上却只是“哎呦”一声;但一个苹果3元钱,两个苹果2*3=6元钱却在牛顿和我们面前是平等的。迷信灵感和迷信逻辑是两个错误的极端,孔子讲“天下国家可均也,爵禄可辞也,白刃可蹈也,中庸不可能也”,任何一项技能的高级阶段都是关于“度”的艺术。如同光具有波粒二象性,软件开发也具有艺术创作和工业生产的二象性,它包含了柔性的设计和刚性的过程。越是不成熟的前沿领域越表现出柔性特征;越是成熟的一般领域越表现出工业生产的特征。因此,一个以新产品为主的创业型公司应当更注重设计,更需要画家、诗人般的创造型人才;而业务成熟产品稳定的大公司应当更注重过程,更需要踏踏实实的生产线工人似的人才。但在当今这个瞬息万变的信息时代,即使是世界500强的大公司也越来越不稳定,越来越需要创新才能适应,所以即使大公司也不可忽视软件开发的柔性特征。同时,我们也不能迷信模型,过程同样可以成为企业的核心竞争力,比如:富士康。虚虚实实,实实虚虚,其妙无穷。老外做Nike品牌(虚),我们做代工生产(实),高额利润被老外拿走了;我们经营航空公司(虚),老外生产波音飞机(实)高价卖给我们,高额利润又被老外拿走了。靠虚取胜还是靠实取胜?这是个问题^_^

 

或许我对于模型柔性的描述不太让人满意,人们多习惯于有章可循的感觉,即便不是死板的知识,起码要找个“在某某思想的指导下”才觉得心里有着落。或许还有人说,模型的确重要,那么我们能不能有一个过程、模式或套路来推导出模型呢?比如,现在非常流行的从用户需求出发的分析模式,即“分析需求,抽象出共性,共性是本质的,本质是稳定的”,这类模式的特点符合人们希望找到套路的心理,一看就明白,容易操作,有成就感。我不否认这类模式的确可以得出可用的软件设计,沿用成熟的模型也未尝不可。但我们应该明白,心中的世界远比现实的世界更广大更美妙。世界是多元的,用户需求、成熟模型等直接可见的东西只代表了某几个维度的视图,设计者心中应当有更多的维度!用户需要一个文本编辑器,是设计者心中的世界决定了他交出的作品是Vi,还是Emacs,亦或是Notepad。亨利·福特说:“如果你问用户需要什么,他会告诉你一匹更快的马”。汽车源于福特心中的世界,这是一个比只有马的世界更多彩的世界。乔布斯是一个不重视市场调研的人,iPod,iPhone,iPad都不是发个问卷,做个市场调查看看用户需要什么的结果。Apple是乔布斯心中的世界在现实中的投影!所以,请打破“从用户需求出发”,“从模式出发”的迷信,释放你的想象力,让自己心中的世界去包容现实的世界吧!

 

每个人心中都有一个属于自己的世界,牛顿运动定律是牛顿心中的世界,相对论是爱因斯坦心中的世界。哪一个才是本来的世界呢?有没有本来的世界呢?本来的世界是什么样子呢?… 老子给我们启示“道可道,非常道”,说得清,道得明,想得到的都不是永恒的真理,所以真理不可言说,对真理的探索永远没有止境……

标签: agile

posted on 2011-10-15 21:30 Todd Wei 阅读(3023) 评论(19) 编辑 收藏

评论

#1楼 2011-10-16 00:00 rhs      

不错的文章!
像Unix等操作系统是根据操作系统原理来设计,可以说系统虽然复杂但模型是相对比较稳定。大师之所以大师,除了天才的设计、想象能力还有一流的代码能力,他写出的系统当然很稳定。反之我们一般人(特别是企业应用,业务逻辑差异大、变化大,没有固定的模型),只能不断的重构以提升代码质量和系统构架质量。神秀说:“身是菩提树,心如明镜台,时时勤拂拭,勿使惹尘埃。”慧能说:“菩提本无树,明镜亦非台,本来无一物,何处惹尘埃。”
 回复 引用 查看   

#2楼 2011-10-16 09:45 518      

"迷信灵感和迷信逻辑是两个错误的极端" 这句很赞同。
但下面lz又在走向一个极端, 好的东西要符合当时的社会现状才可能成功,
完全脱离需求的产品会有很大的风险,除非开放人员不追求商业利润。

不过蛮喜欢LZ的哲学思想。
 回复 引用 查看   

#3楼[楼主] 2011-10-16 09:48 Todd Wei      

@518
谢谢!我的观点是:包容需求,而非脱离需求。用户的需求是文本编辑器,你的作品可以是Vi也可以是Notepad,这都是对需求的包容。
 回复 引用 查看   

#4楼 2011-10-16 14:40 MeteorSeed      

我认为:对于一个项目的成功,其思想是核心,技术是基础,管理是保障。质量管理一定要贯穿项目始终,因为越早发现缺陷,修复成本越低。  回复 引用 查看   

#5楼 2011-10-16 22:26 NewObject      

哈哈, 浩哥也来此了啊。  回复 引用 查看   

#6楼 2011-10-17 11:27 水月之舞      

感觉楼主是站在领域驱动设计的角度上来说的,的确一套系统中最为关键的部分就是和各种业务逻辑紧紧相关的模型,但是也不可完全否定XP和TDD,因为正因为有迭代开发和大量测试保证,才能让我们逐步精炼模型  回复 引用 查看   

#7楼[楼主] 2011-10-17 12:43 Todd Wei      

@水月之舞
>>感觉楼主是站在领域驱动设计的角度上来说的

不是的。假如做一个文本编辑器,我感兴趣的是Vi/Emacs/Notepad本质的差别是什么?怎么来的?而这并不是领域驱动设计所关注的内容。换句话说,领域驱动设计学得再好也不能保证你能设计出Vi和Emacs,不过或许Notepad可以。
 回复 引用 查看   

#8楼 2011-10-17 16:08 历程      

引用MeteorSeed:我认为:对于一个项目的成功,其思想是核心,技术是基础,管理是保障。质量管理一定要贯穿项目始终,因为越早发现缺陷,修复成本越低。
 回复 引用 查看   

#9楼 2011-10-19 20:04 jinspire      

我同意楼主的观点,特别是重视创造的柔性这一点。一旦一种解决问题的方法提出如敏捷方法论,其实必然就走向了刚性,但是过程管理方法也是人通过柔性创造力想出来的。所谓“物壮则老”,而世界的需求是不断变化的,敏捷方法论也有他到头的一天或不适应的环境。这时柔性就会创造出新方法。所以我不否定敏捷,但不能过于强调敏捷是适用于一切环境的。在适用环境下,刚性方法论给人一个明确的过程,柔性思考不是每个人都能想到的,不是么?  回复 引用 查看   

#10楼[楼主] 2011-10-19 20:49 Todd Wei      

@jinspire
说得很好,学习成熟的方法是刚性,而创造方法是柔性。
 回复 引用 查看   

#11楼 2011-10-22 06:41 meng0819      

看来博主对道德经,孔子都有研究啊。。。
感觉你这里过于关注人,你不能要求每个人都像乔帮主一样有创意,而且那么固执。。。
过程,技术,人三个因素对品质都很重要。CMMI,SCRUM等等软件工程方法都是调节这三者间的平衡关系。
 回复 引用 查看   

#12楼 2011-10-28 16:32 ahl5esoft      

楼主是陈浩吗?
这篇文章应该是酷壳上的吧
 回复 引用 查看   

#13楼[楼主] 2011-10-28 22:45 Todd Wei      

@ahl5esoft
不是,酷壳转载的这边的。
 回复 引用 查看   

#14楼 2011-10-29 11:34 CodeWorkers      

强人,已经上升到哲学的境界了  回复 引用 查看   

#15楼 2011-10-30 22:18 独孤青      

@meng0819
CMMI,SCRUM还是其他的也好,只是为了一个目的,就是造出符合客户要求的软件,却造不出iphone,框架下的东西只能如流水线的生产一线,按照模子生产出一样的东西。一个产品只有注入了开发者或者设计者的感情在里面,才能有灵魂,才能称之为具有优秀品质的产品
 回复 引用 查看   

#16楼 2011-10-31 17:01 wancy86      

学过道德经的都是高人!  回复 引用 查看   

#17楼 2011-11-05 21:20 不知鱼      

能把自己心中的“模型”表述出来的,应该是大师了,能用简单的数学模型表述出来的,应该是大师中的大师了。  回复 引用 查看   

#18楼 2011-11-06 15:06 小知了了      

品质在于构建过程的说法其实是移植自工业工程中的“过程决定质量”一说,而“过程决定质量”中的质量主要是指统计学意义上的良品率,这个含义在软件产品上根本不存在。欢迎移步我的帖子探讨这个话题:
http://www.cnblogs.com/xrunning/archive/2011/11/05/2237256.html
 回复 引用 查看   

#19楼 2011-11-25 14:56 Richeir      

好文章不得不顶  回复 引用 查看   

公告

微博:@weidagang
昵称:Todd Wei
园龄:3年9个月
荣誉:推荐博客
粉丝:90
关注:24

统计

  • 随笔 - 61
  • 文章 - 10
  • 评论 - 724

常用链接

技术博客

良师益友

我的作品

积分与排名

最新评论

阅读排行榜

评论排行榜

推荐排行榜