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

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

感谢@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�