“品质在于构建过程”吗？
感谢@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...
《“品质在于构建过程”吗？》的相关评论
写得真好，是有价值的文章。
关于“虚实”“二象性”的举例展开写得很好~
直达本质。
只要涉及创造性的劳动，人永远是核心。工业界更关心的是，在没有那么多高素质的人的情况下，如果保证产品的基本品质。
你不能希望一个工业界的模型，产生一个一个大师级/革命性的产品。这不是工业界要做的事情。
写的很好，有些感悟
找个茬：unix最初只有几千行–接近一万行–代码
原来软件工程就是将自己的固有结界投射到现实世界上
想法和sein_tao一样，良好的构建过程可以提升品质，不能要求每个人都牛B的一塌糊涂，毕竟是软件工程。
alert(0)
同意作者的观点：模型是对软件的结构和行为的描述，想做出架构优美、运行良好的软件，肯定是需要有一个优秀的模型与之对应。
而模型的优劣可以反映出创造者的知识、技能和经验的水平。所以我想：要想做出优秀的软件系统，作者至少需要拥有很高的知识、技能和经验水平。方法当然也很重要，但我不认为优秀的方法论+平凡的工作者也可以产生高品质的软件。优秀的方法论至多让工作者做出具有和他们技术水平齐平的品质的软件。
个人观点。另外很喜欢TODD的那个“二象性”的比喻！
规范的生产过程可以保证产品的质量，许多日本企业的产品之所以质量高，成本低，就是有一套完善的生产过程控制规范。但和软件相比，这些产品唯一缺少的是创造性的劳动，而这部分创造性的劳动是无法“完全”使用一定的规范和过程来指导的。这个问题其实就是品质的内涵的问题。
但是软件的开发活动绝不全是这些创造性的活动，而且一旦创造出的有价值的东西，也需要找到共性，形成流程，以方便在再次遇到相似问题时能够快速完成。
现代软件规模越来越大，而竞争的压力导致产品开发周期越来越越短，如果在非关键依靠创造性劳动（比如界面，用户逻辑）的部分使用合理的构建流程，保质高速的完成任务，从而花更多的时间在软件的核心价值部分，使用创造性劳动，创建你所说的“优秀模型”,应该是更为合理的思路。
个人觉得必须要承认构建过程的重要性，在许多项目（甚至是大多数项目）中它的重要性是第一位的，毕竟不是每一个项目和软件都是用来改变世界或是你的工作领域的。做到了过程，你就是一个合格的coder，而合理的进行创造性开发的话，你就是一个出色的coder。
ps： 不过对于那一大撮别有用心地鼓吹流程和构建的论调，我觉得是应该坚决打倒的！
你说的模型应该是指心智模型mental model吧，
http://zh.wikipedia.org/wiki/%E5%BF%83%E6%99%BA%E6%A8%A1%E5%9E%8B
。构建方法和软件设计，就好像流水线和产品设计一样，流水线生产可标准化、可以复制，便于顾问公司在许多领域销售宣传，而好的设计却综合了太多人的认知因素，可遇而不可求。但是成功的工业产品确是二者缺一不可吧。
zhuangbility貌似比浩哥强一个等级，给“人”先带帽子再批判。不过@Todd还应用了辩证法和名人名言，辞藻优美，举例生动。文学功底很不错，应该是作者的灵感闪现，是其他人烂人再用TDD都无法重构出的美文。
zhuangbility貌似比浩哥强一个等级，不过@Todd还应用了辩证法和名人名言，辞藻优美，举例生动。文学功底很不错，应该是作者的灵感闪现，是其他人烂人再用TDD都无法重构出的美文。
zhuangbility貌似比浩哥强一个等级，不过@Todd还应用了辩证法和名人名言，辞藻优美，举例生动。文学功底很不错，应该是作者的灵感闪现，是其他人烂人再用TDD都无法重构出的美文。
不过能不能不要，给“人”先带帽子再批判。好好搞清楚敏捷到底用来干嘛的好吗。
一天到晚拿搞敏捷来YY自己，总让我想到小时候学的课文里的河伯。你们都是大师，不要再抛那种可笑的言论了。建议多写些《跟我一起些makefile》那种。
就是这个意思，#11楼我说了一大堆废话…
李敖—–「大道之行也，天下为公」人人会说，但「天下为公」是主张，要拿出办法才算。有主张、没办法，有个屁用？如果你的主张是「骂 XXX」，但你不敢牺牲、不敢坐牢、不敢设网站、甚至不敢用真名负言责，表示你只会主张「骂 XXX」而没办法「骂 XXX」。你会骂李敖，但骂李敖不能解决你无能，你脸红了。
@Mic，人家Todd是在讨论事，而你是在骂人了，对人不对事。你看，你脸红了。
聆听自己内心的声音，打破传统和迷信，真实书写自己的“作品”！
浩哥自发和转发的N多有关敏捷的文章，根本不是在谈论相关的技术。首先都是先给敏捷和TDD戴个帽子：能实现完美设计。然后就开始批判了。然后给出观点到底什么能做到完美设计呢，原来不是方法而而是天才的灵感，是解决具体问题的具体能力，是手中无剑心中也无剑的大师们。哇，作者的洞察力和对本质把握的牛逼真是让人内心的敬仰犹如滔滔江水。
可是人家敏捷本来就不是要实现完美设计或高品质的。是你们强加的。
而且既然好的设计都是取决于个人的，那么烦请浩哥发个文到底什么样的人可以做完美设计。出了浩哥和他经常提到的几位大牛意外，我实在不知道怎么样去判断。不适合的还是早点去转行，不要误了人生。
@陈皓
他真的是在讨论吗？看他贴出来的对话。人家卖勺子的在说勺子可以帮助你炒菜。他不指出勺子本身有些什么质量问题，而是说你错了，如果你丫很挫，用了勺子也炒不出好菜。你看，人家周星驰煎荷包蛋用的是“火云掌”，可没用勺子。你如果人厉害就算用jb也能炒出好菜。哇塞，很有道理很牛逼。
你说的东西很有道理可问题是：
1.人家说的和你说的压根不是一回事，不是一个范畴。还说人偷换概念。逻辑如此混乱就不要用专有名词了。
2.你说的东西虽然很有道理但是跟没说一样。
3.如果你是餐厅经理，请了厨师烧菜。在不清楚这些厨师“火云掌”是不是练到十级的情况下，给他们买个好勺子（不要用中国的山寨品牌诸如TW云云）也是可以的。
@陈皓
浩哥，不要急啊。我哪里骂人了。我相信回帖的这些人里，一部分是明白我的意思的。
1.你们的言论都是有道理的，但其实说了跟没说一样。自己做出好的设计，很软件工程的控制方法目的是不同的。
2.你们骂敏捷根本骂得不在点子上，很搞笑。而一直反复如此，只是下意识自己感觉很牛而已，根本没什么意义。
创造性的工作（最典型的就是建立模型），肯定是无法工程话的；事务性的工作（如类似项目的开发），能工程化肯定是好控制
这个世界，当我们不以金钱为追求，才能创造出真正的好的东西，或者产品。
这个观点我非常同意。我再在你这个观点上再进一步——以解决改善社会问题，以做事业的心态才可能会有好的东西。
@陈皓
这个我也同意，但是跟没说一样。
其实，那个“度”很关键啊！
这个赞同，说这些虚的，没用。
在说得天花坠，boss看重的是是否能盈利，作为软件工程研究的话，看重的是是否有可操作性，真的对生产活动有指导意义。
说那么多，文言与外语并用，故事与例子齐飞，对到底该怎么操作，完全没有任何信息。没有一点意思
一年前还不是很明白所谓的敏捷，特别是他的原则，后来看了一些心理学的书，发现，原来他们在造神。
PS：部分东西还是可以吸收一下的
我以前都不知道什么叫敏捷开发，最近看了很多博主对于敏捷开发的讨论，呵呵。
其实我发现这没什么好争的，博主对程序员的要求太高了，但是针对的都是大公司，大项目。
或者程序员自己就是老板的公司。
而敏捷开发适合于小公司，小项目，想快速盈利的一些工程。
产品经理又不懂技术的情况下，我认为这种开发方法很合适。
有些项目，就连客户都不清楚自己想要一个什么东西，而你的预算和时间又很有限，怎么可能花很多时间给他造出一台汽车来？
看了此文，对于软件设计很多形而上学的东西突然像刀劈斧剁般料理清楚了。
一切伟大的产品，在最初的思想混沌中，需要有高度净化的创作世界，类似禅宗一般清僻肃穆。一个人的境界影响他心中的模式，模式定义着工业的每个枝节，细节规范流程来驾驭普通人的劳动内容，最终创造出工业的极致。
理想的工业设计应该是这样的吧，映射到现实，投资人的意愿、公司经营者的建议、短期利润的刺激、各种需要规避的技术专利、市场营销相关部门的反馈，全部结结实实的扔在设计师的脸上。设计最终成了参照期望案例的流程与规范的制定。
想到这里，再一次明白了乔布斯精神的可贵，并对他离世表示哀悼与敬意。
Linux和Unix之类的系统开发和一般的Business/Application开发实际上会有很大的不同。关键的一点在于Linux和Unix的开发者非常了解他们所开发的系统，他们就是这个系统的用户，他们就是需求的提出者；而一般的Business/Application开发，开发/设计人员却经常不了解这个领域，无法理解需求。因此两者在开发流程上很自然会不同。
说的真好，软件工程看的我头晕，这篇文章坚定了我走自己路的想法
做到把心中的模型，现实化，让人们接受他，我想这就是成功，一个软件工程师的追求吧，但是不是每个人心中的模型都是那么清晰和正确，甚至没有，呵呵
灵感决定品质的上限，而逻辑用来验证品质的下限。
保证品质在于构建过程， 我想他是这个意思。毕竟大师也不能保证每次都是完美的产品。
好文章~犹如醐醍灌顶~谢谢啦~
觉得你挺没劲的，人家一个技术博客，讨论技术，你在此搞人身攻击。你不觉得很惭愧吗。任何一种方法都有一定的优点，但是也不可避免的存在缺点，人家从缺点的角度谈谈看法，你犯得着攻击人家吗？
也许敏捷 测试驱动开发是个好经，被你们这种偏执的和尚搞得和邪教似的，至于吗。大家都是搞技术的，不是搞传销的。如果靠忽悠人来发财，你睡得安稳吗。如果不是忽悠人，真金不怕火来炼，你何必在乎人家一点点理性的批评。
每个人对自己的代码要负责，起码要通过自测，所以测试还有必要的，充分测试验证开发是合理的，但是测试驱动开发就有点说不过去了，测试怎么驱动开发？个人比较讨厌这种玄之又玄的理论，还想很有道理，有那闲工夫不如自己写代码。没有五万十万行代码的经验，不要瞎扯什么理论。
不懂敏捷，TDD，我惭愧的飘走
我的问题是好的模型从哪里来？从书本上来吗？看过设计模式书的人多了去了，未见得有几个人能做出Unix这样优秀的系统来。这样看来软件的好坏最终还是决定于人。
说的好。
好比作家写书，其实敲字之前，他已经“写”完了。
我以后要多提模型这个词，以显得我很牛逼。ps，@mic 的话糙理不糙。
模型？归根到底是“数学”的理论突破。NB的还得是数学。
太受教了！
说明一个道理：不管什么时代，天才就是天才，英雄就是英雄。纯正的智慧不可能被过程取代
FaceBook和iPod，并非讨好大众，而是领着大众往前走
今年本科生，刚上班，深感所学不足，还是回去考研究生吧
我理解作者的意思是：产品的品质出于设计者的内心，外在的需求调研、开发测试管理流程、开发工具等都是辅助性的
让自己心中的世界去包容现实的世界吧！这句话按我的理解可以改下更好:让自己心中的世界成为现实的世界吧！
世界上没有包治百病的神药,也没有放之四海皆准的准则.
我个人认为,软件开发其实也分很多种情况.比如每一个项目的为谁开发?开发来做什么用?用在哪里?用多久?这些问题的答案也是不一样的.而且软件从业者的目的和原因也是不一样的.有一个故事,是说三个砌砖工人,第一个说他正在建一座气势恢宏的教堂,第二个说他是在挣钱养家,第三个说我在彻砖.这三个人的人生态度和目的是不一样的,但是谁也并不比谁高尚.现实中第一类人很少,大多是二,三类人,其实二三类人,特别是第三类人,就很需要规范,流程,操作执行,工具,甚至师傅调教,严格的验收等等具体,可操作的,行之有效的方法了.
没有银弹，敏捷不是，你说的软件模型也不是。他们都有一定的应用场景和适用范围，如果需求不是很明确，需要逐步明确，那可能敏捷更适合一些。如果像你说的unix，已经想好要做什么了”Unix的品质就已经存在于设计者的心中了”，那就搞模型。其实对任何都没必要一棒子打死，存在即是合理的，敏捷必然有他的用武之地