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

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

感谢@weidagang (Todd)向酷壳投递的这篇精彩的文章。原文

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

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

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

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

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

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

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

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

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

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

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

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

模型是软件的灵魂,存在于设计者的心中,而软件的构建过程正是心中的世界向现实世界逐渐投影。模型可以是完美的,而现实却非完美,或许有时候我们很幸运地到达了,或许有时候我们不得不向现实妥协,改变心中的世界。试图制造灯泡的爱迪生可能会一时找不到熔点极高的发光金属而止步不前,企图制造永动机的人则根本无法实现。在不完美的现实中,我们明明想的是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是乔布斯心中的世界在现实中的投影!所以,请打破“从用户需求出发”,“从模式出发”的迷信,释放你的想象力,让自己心中的世界去包容现实的世界吧!

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

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (29 人打了分,平均分: 4.00 )
Loading...

“品质在于构建过程”吗?》的相关评论

  1. 仔细看了一下你这篇文章,对你有些观点不是特别认同!
    软件的品质在于构建过程,我是非常认同的,也非常认同敏捷开发,当然最终一个软件是否非常优秀卓越是要看这个软件基于的模型是否优秀。但是构建过程是一套工作流程工作方法,可以保证一个优秀的软件快速的开发出来并得到检验,如果没有合适过程方法论来保证一个软件的开发,你能够一定保证软件的品质吗?
    中国人喜欢探究自己认为的智慧,理念。比如你认为核心是模型的话,每一个软件的模型不一定完全相同,软件的规模也越来越大,含括的东西非常多,每一个子系统,模块关键是需要快速的构建出来?其实最关键的是工程方法论,我是原来做软件研发出身的,后面自己办软件公司,当公司上百人在做一个软件产品的时候其实最关键的是工程方法论,如何组织这个团队开发出优秀的东西来,其实软件的构成过程非常重要,当然模型非常重要,更多的时候可能取决于软件开发过程!
    技术的本质在于为人服务,为人改造自然服务,如果每一个人都需要了解里面的模型,这将是非常复杂的。
    包括我们软件技术的发展其实也是越来越简单,封装越来越多,越来越方便大家开发,原来在DOS下还要了解中断,控制中断,现在都不要了,技术得以迅速的发展。
    无论你承认也好不承认也好,未来软件就是朝软件工厂的方向进展,软件也不再是阳春白雪,都是生活消费品。
    大家不要在拘泥于技术的细枝末节了,特别想你这样研究过这么多技术的人,更多的是让更大的团队掌握这些技术,构建好的软件,掌握工程方法论是设计和把握软件品质的规则的可信。

  2. @技术讨论
    我觉得构建过程与软件设计之间的关系就好像实现与创意之间的关系。创意可以中庸,实现一流,创造出来的东西也是中上之品,但绝不可能成为真正一流的东西。如果说两者间谁更重要的话,确实是比较困难的。因为站在不同的层次,需求是不一样的。比如说你后面提到到底的软件的核心设计好还是软件工程方法好。就拿苹果和富士康两个公司来说,对苹果而言,它需要是的设计,它并不需要快速的创造出自己的IDEA,否则,苹果也不值钱了。但富士康不行,他的价值就在于批量生产,所以他会追求快速生产方法,也就是你说的工程方法。其实在博主的文章里是有这层意思的,不过你太注重工程方法而忽略了这些东西。

  3. 模型非常重要,更多的时候可能取决于软件开发过程!
    技术的本质在于为人服务,为人改造自然服务,如果每一个人都需要了解里面的模型,这将是非常复杂的。

  4. 写的很好,但是总觉得哪里不对,请问作者过去了好几年,你现在看这段文字是什么感觉?

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注