分类：知乎

敏捷的本质，是承认软件开发的复杂性。而且承认，这种复杂性，达到了这样一种程度：“无法通过足够充分的前期准备，而消除后续的风险。甚至于，前期准备得越是充分，后续的风险越大。”

往往有很多人，将建造大楼与软件开发做简单的类比，以说明前期设计的重要性。但事实上，我们无法想象，一幢大楼，在接近完工的时候，有新需求出来，要求整个设计从从一幢四边形的楼，变成一幢六边形的楼。

但是，在软件开发领域，就是会出现这样的需求，而且，这种需求虽然会被所有的开发人员痛骂，但却“实际上具有其合理性”。

如何理解需求的复杂性、易变性？

软件的出现，还不到100年。建筑的历史，则至少有5~6千年了吧。人类对于建筑的需求，已经足够稳定（相对于软件而言）。另一方面，软件的可能性，又实在是太强大了，至少重力因素软件可以毫不考虑。

软件开发这个领域，还太年轻，大家都没有足够的经验。年轻到了，甚至现在去急于总结经验，都是错误的！

来源于Christopher Alexander《A Pattern Language: Towns, Buildings, Construction》曾经给予Gang of Four以巨大的启发，所以他们写出了著名的《Design Patterns: Elements of Reusable Object-Oriented Software》。

但是，现在看来，设计模式的流毒真的不少…

所谓敏捷方法，不过是一种需求发现与谈判策略

过去的思路，认为需要尽可能发现所有的需求，并且做好设计，然后再开始开发。现在大家已经意识到，一边做，一边确认，一边发现，一边纠正。从总体成本上衡量，反而会更加低。

但是，在实际施行敏捷的过程中，“一边做，一边确认，一边发现，一边纠正”，也同样可能存在巨大的浪费。而且，因为披上了敏捷的外衣，反而变得无可指责了。

本质上，这是一种对于开发方，而非需求方，更加有利的谈判策略。

总结陈词

我们现在还缺少一系列量化的手段，去衡量需求的复杂度，开发的效率以及各种流程方法的优劣。（不要跟我提Function Point Estimation，那种教授坐在书桌边发明的方法~~）

因为缺乏这种量化，所以大师满天飞，却让人无所适从。

外一篇：“设计模式的荼毒”体现在何处？

可以从两个角度来谈这个问题：

1. 建筑里的结构工程师，如何设计结构？

我们都知道，建筑设计中的结构工程师，非常重要，而且，他们必须非常深入的了解数学这门学问。

在结构设计出来之后，他们还需要做一些模拟与演算，以确保他们设计的结构，能够承载整个建筑。

再进一步，一个敢于设计结构的结构工程师，有很长的一个学习阶段，以了解前辈大师的经典结构与数学模型。

可以说，建筑结构学，是一门科学，是一门以数学模型和科学实验为基础的严谨的科学。

2. 中医如何看病

中医，也有一套理论：阴阳呀、五行呀、相生相克呀，等等等等。在这套理论的基础上，也有上千年的经验积累，什么药吃了能治什么病，大概是什么计量。

但是，说到底，这是一门「经验科学」，或者直白一点说：「这不是一门科学」。

声明一下：我不是中医黑，虽然我也不是中医粉，至少中医的确有大师，他们真的治好了很多病人，这个我绝不会否认。

毕竟：疗效的好坏，还是很难伪造的。

3. 软件架构师，如何设计架构？

架构师，看起来很像结构工程师，但是：他们没有科学基础，只有一些「设计模式」和「架构模式」。

那些「模式」的有效性与适用范围，并无严谨的证明，只有一些模模糊糊的「实践案例」。

「听说设计模式是好东西」，就像「听说人参大补元气」一样。真正的中医，尚且不敢给病人乱开人参，但是架构师，他们真敢把所有的「设计模式」都用上。

中医再怎么不靠谱，真是把病人给治死了，医生也会吃不了兜着走。但是，我们什么时候听说过一个项目的失败，是因为架构师不合格呢？

还有个更大的罪魁祸首「需求变动」顶在前面呢。

4. 总结陈词

一种「理论」却没有严谨的理论支撑，一门「手艺」却难以客观的评价手艺高低，随便看两本模式的书，就敢开整。没有流毒，就怪了。

两本都是好书，都值得分别为他们写一篇读书心得，只是这里想谈谈的是两本书中，相通的部分——「架构的力量」。

• 端对端原则

在《思想的未来》中，作者回顾了互联网的架构设计思想：
「这一原则是由网络设计者Jerome Saltzer、David Clark、David P.Reed在1981年首次提出的，被称为端对端(end-to-end argument, e2e)，用以指导网络设计者们开发网络协议及应用程序。」
「端对端原则认为，网络的智能不应当放在网络内，而应当位于网络的端点，即网络内的计算机只是履行应用程序所需的基本功能，而一些特殊功能应由网络边缘的计算机来实现。」
「据RFC 1958所述，虽然因特网社区中许多成员会认为因特网不存在架构，但是，社区成员普遍相信，因特网的目标是连通性，工具是因特网协议，智能位于端对端而不是隐藏与网络之中。网络的任务是尽可能灵活有效地传输数据包，而其他的一切都应该靠边站。」

由这样的架构原则，作者总结出了三个要点：「应用程序在网络边缘的计算机上执行，任何种类的应用都可以立即被运行；网络没有为任何特定应用程序做优化设计，对于任何创新都是开放的；由于网络平台的中立性，网络无法做到歧视某种特定的新设计。」

在我看来：互联网最初的设计者，因为足够谦逊，所以对于「平台将会如何被使用」未做任何假设，他们的架构仅仅专注于最为简单的目标，而这也是互联网取得如今这样巨大成就的根本原因。

• 不要尝试预测未来

在《简约之美》中，作者极力向读者阐述：架构设计简洁的价值，因为随着时间的不断增长，软件的研发成本的绝大部分，会产生于后期维护的阶段。越是简洁的架构，就越是能够为今后的维护，节约大笔费用。

另外一个值得注意的事实是：「程序员犯的最常见也是最严重的错误，就是在其实不知道未来的时候，去预测未来。」

而作者给出的策略是：「最安全的情况是，完全不尝试预测未来，所有的设计决策都应当根据当前确切知道的信息来做。」

在我看来，当年的互联网设计者，就是那种最伟大的程序员/设计师，他们未做任何假设，仅仅专注于解决信息传输的需求。

• 一个可能的误区

不去尝试预测未来，根据当前确切知道的信息来做。这样的逻辑，可能会让人偷懒。
1. 「啊，我们这就开始干吧！」
2. 「我们不要做太多的假设！(不必想那些设计的事情)」

架构是存在的，设计是需要的，需求要尽可能的去搜集与分析。在做到这三个要点之后，才能谈及「不要假设」，「不要过度设计」。在此之前，还是不要放松为好。

架构是有力量的，简洁的架构，往往会产生的惊人的力量。当然，「无架构设计」不在其列。

在上一篇文章里，有两张图，提及了三组关系：

研发效率→速度提升与流程优化；

研发能力→特性丰富与质量提升；

研发活力→成果重用与研发创新；

这三组关系，左边是本，右边是末；也可以说左边是因，右边是果。好的企业，会追求左边，进而得到右边的那些好处。糟糕的企业，却会盲目追求右边的那些成效，结果导致一些悲伤的结果。

这种事情，一般来说在企业里，不太会发生（不过的确是有这种企业，尤其是某些特别有「追求」的企业）。

这种情况，其实也比较罕见，我能够想到的例子，是某些声称要生产银弹的企业。

这倒是绝大多数研发企业的通病，速度快了，质量就下降。勉强把质量搞上去吧，就必须要缩减功能了。

据说，那些能够过CMM5的企业，都是具有高额利润的企业，否则根本承受不了那种流程浪费啊。

很多时候，我们都了解码农的苦，因为产品经理为了拉订单，答应了太多的功能特性。

听说，伟大的游戏总是会延期……

总之，舍本逐末的害处，实在是太多了。如何才能正确的追求研发实力的提升呢？

<未完待续>

1. 眼花缭乱的铁三角

在维基百科英文版 Project management triangle 我们可以找到很多不同版本的项目管理铁三角：这些图，要细细讲解起来，每一个都可以大说一番道理。但是，若是想要究其本质，其实无非是一句话：「老板，您不能什么都想要啊！」

那么，有一个挥之不去的问题，就出现了：如果多种要素，无法全面追求，那么优秀的研发团队与低劣的研发团队，区别何在呢？项目一旦失败，因为有铁三角护身，我们就总能够抱怨：老板什么都想要，所以bla…bla…

有没有可能，通过一系列的手段与努力，提升研发团队的实力呢？有没有可能存在一个优秀的研发团队，能够在多种不同的追求方向上，都获得令人满意的结果呢？

2. 概念梳理后的金三角

为何要将这样一个图，称之为金三角呢？有几层含义：

Schedule（调度）：通过提高单项工作的速度，可以提升效率，通过流程优化，进度合理安排，可以提升整体效率，因此将效率目标分解为：速度与控制力。

Requirement（需求）：用户的需求有非常多，主要可以划分为特性需求与质量需求。

Profit（利润）：在IT企业中，研发团队通常不是利润来源，而是成本中心，但是研发创新与研发成果重用，同样可以降低成本，甚至给企业带来利润增长。

仅仅将以上的概念归并，还不足以称之为「金三角」，再看下面这张图：

efficiency（效率）：要做到足够好的调度Schedule，我们需要追求更好的「研发效率」；

ability（能力） ：要满足用户的需求Requirement，我们需要追求更强的「研发能力」；

energy（活力）：要追求更高的利润Profit，我们需要激发足够的「研发活力」；

而能力提升促进效率改善；效率提升增加空余时间，使得研发活力有可能增加；研发活力的提升，则能够增进研发能力；以上三种要素之间的互相促进，构成了一个「使能环」，而这样一个使能环，就是研发管理金三角的真意！

<未完待续>

这些都是我最感兴趣的内容，原来， 我注定就是个搞 IT 的。

这是一本非常宏大的书，同时又是一本非常有趣的书，宏大的历史场景与有趣的历史细节，被巧妙的交织在一起，读来颇令人感到兴趣盎然。

举个例子：

非洲的鼓语，是什么原理？外国人很难明白，因为他们的语言没有平上去入的声调变化，但是中国人应该一听就能明白了。我们小时候常常玩的一个游戏：发出一连串「一姨以易」的四声，让别人去猜我说的内容。而聪明的非洲人，将声调用鼓声来表达，同样也可以让人猜出鼓声背后的语言。更进一步的道理是：越是冗长的一串声调，越是不容易被人误解。

而这样一个现象背后，蕴含着一个重要的信息学公式：H=n log s，H表示讯息的信息量，n 表示讯息中的符号数，s 表示语言中可用符号的总数。这表示着：可用的符号越少，为表示出给定信息量所需传递的符号数就得越多。

这是本书常见的表达手法：讲一个有趣的故事，引申出一个简单的道理，然后再推广出一个影响深远的理论。典型的「深入浅出」！

再举另一个例子：

电报发明之后，由于费用高昂，人们通过缩减字数，以减少费用。进而出现了「电报体」这样的新文风。安德鲁·温特写道：

电报体让任何形式的礼貌说法都无容身之地。『May I ask you to do me the favour』（劳驾）这么一句话，传输五十英里的距离就要六便士。这个可怜的人要把类似温文尔雅的形容词砍掉多少，才能将他的信函开支降到一个合理的水平呢？

于是，各种缩略语、密码本开始大型其道，1885年，W.H.比尔公司出版了一本畅销的《电报编码口袋书》，定价一便士，其中包含了「三百多条只需一个单词的电报」。

随着讲解的深入，密码学、布尔代数、逻辑学，被一一介绍给了读者。这就是深入浅出的魅力所在。

当然，这本书最吸引我的是《第4章：将思想的力量注入齿轮机械》 ，因为在这一章里，介绍了世界上第一个程序员，而且还是第一位女程序员：爱达·拜伦（Ada Byron）

很小的时候，我就读到了一本介绍巴贝奇的书，但是那本书里，竟然几乎完全没有提到 Ada 的存在。而在信息简史一书中，我发现 Ada 是一个比巴贝奇更加惊人的天才！引用几段 Ada 的文字吧：

我的头脑不是凡间之物，这一点时间将会证明（只要我的呼吸以及某些其他部位没有太快地奔向死亡）。

没人知道在我那瘦小的系统中潜藏着多少尚未被开发但几乎让人惊叹的能量和力量。我说它让人惊叹，是因为你可以想见在某种情况下它可能爆发出怎样的力量。

爱 达对于未来也有一个最后的梦想：「我以我自己的方式迟早会成为一名独裁者。」在她面前将集结起一个个军团，对此即便是地上的铁腕统治者们也只能乖乖让路。 那么她那些军团由什么材料构成呢？「我现在可不会说。但我希望，它们将是纪律严明、异常和谐的军队——由大量的数构成，伴着军乐以势不可挡的力量行进。这 听来岂不是十分神秘？显然我的军队必须由数构成，否则他们也就根本不可能存在……但如果进一步问，这又是些什么数？这则是一个迷——」

最后，我想说：如果你拿起这本书，翻开任何一个章节，都能够津津有味的读下去，那么你也注定是个搞 IT 的！

1. 从《失灵》说起

前段时间，我正好读了一本奇书《失灵 (豆瓣)》， 作者是一位出生在南非的犹太移民，后来到美国读物理学博士，然后又转行华尔街，作为宽客，创作了业界广为采用的某某局部波动率模型。这本书谈到了南非种族 隔离、犹太复国运动、物理学发展史、还包括叔本华和斯宾诺莎的哲学与伦理学。其主旨却是为了探讨：为何看来可靠的模型最终都会失效？

作者在这本书里，谈论了非常非常多的东西，但是其核心思想，是站在一个物理学家的立场，吐槽所谓的“模型”，特别是“经济学模型”。

作者在谈论模型时，这么说到：“模型是隐喻，并不是真实物体本身……模型就像一幅漫画，突出某些特点，而忽视了其他特点……模型减少了世界的维度，将多维世界缩小为更易理解的空间。”

与此相对的，则是理论。作者将其与模型做了对比：“模型是类比，借助别的事物来描述目标物体，因此模型需要解释。相反，理论不需要借助别的事物，只需要证实而不需要解释。理论阐释的是事物的本质，理论如果成立，就是事实。”

“如果理论成立，则能非常精确的描述其对象。”与此相对的：“模型经不起推敲”

接下来，不再引用书中的内容，说说我的理解：理论，尤其是物理学的理论，是非常“坚硬”的，与现实一对照，要么几乎一模一样，要么撞的粉碎。而物理之外的那些所谓的模型，看起来也是些数学公式、图表，像模像样。但却是柔软的，易变的，可以不断通过修正来修补和再解释的。
在软件工程领域，却正好充斥了种种隐喻构成的所谓模型。

2. 从隐喻到定论

在9年前的2005年，我曾经在 JavaEye 现在的 ITEye 连载过一篇文章，名叫《定论——软件开发的方法论探讨》。在那篇文章里，我提出了与《失灵》相当类似的看法，先摘录几段在下面：

事实上，所有的隐喻都不够好，都会扭曲软件开发过程的真相，都会使我们对软件开发的过程产生误解。

为 什么会这样呢？为什么一个挺像软件开发的隐喻会最终误导我们呢？原因在于一个隐喻是一个完整的场景，这个场景中有很多相互交织的“概念要素”。当这些要素 有很多在软件开发中出现时，我们就会认为这个隐喻很贴切，而当一个隐喻越是贴切时，这个隐喻中的其他一些在软件开发中不存在的要素，或者与软件开发相矛盾 的要素，就会打扰我们的分析，干扰我们的判断。使得我们不再思考软件开发本身，而是将思考建立在某个隐喻的场景中。这样思考得到的结果，肯定存在着误导的 可能。再由于不同的隐喻互不相容——你无法想象一群工匠去建设现代化的高楼大厦，他们最多只能造些平房——因此，建立在各种隐喻基础上的软件开发，至今没 有找到适合自己的方法论，倒是不同的隐喻之间互相打得火热。

软件开发有那么多方法，有那么多过程，那么多“最佳实践”，但是却从来没有定论，为什么没有定论呢？因为软件开发的“方法学”还处于蒙昧的“隐喻时代”，各家各派，都从自己的隐喻出发来看问题，所谓“鸡同鸭讲”，指的就是这种情况。

我们的目标，不应该去寻找各种隐喻，而应该须寻求定论！所谓的定论，应该建立在坚实的理论基础之上，而不是靠各种猜想与比喻来搞那些「高科技迷信」。

但是，当年我写的那篇文章，事实上却草草收场，并没有写完，因为见识不足，思考无法深入下去了。在当年那篇文章的结尾，我写了三个观点：

1、现有的软件开发方法，都不是定论，不过是你说你的好，我说我的好罢了。要能够得到定论，必须要有一种能够判断方法好坏的方法。也就是说，能够判断一个方法，用或不用，有多少好处。几个方法比较，哪个能够胜出的“检验标准”。

2、要能够检验软件开发方法的优劣，必须基于对于软件开发本质的正确认识，这样才能量化两个因素：软件需求的复杂程度以及软件开发的实际工作量。而现在的软件复杂度的度量，并未区分“需求”与“实际”的不同，或者“代码行数”，或者“功能点”，都是如此。

3、在能够正确度量需求复杂度与实际工作量之后，我们会发现，过去那么多号称是为了保证软件顺利开发的手段，往往只会坏事，耽误事。但是，完全不提前设计的方法，也并不可取。

3. 真实的研发究竟是怎么样的？

现在看来，当年我写的这三条结论，既有正确的成分，也有不足之处。

• 真实的研发过程，不仅仅是一个团队，在一个特定的时间段里，满足一组特定的需求。
• 真实的研发行为，不仅仅是通过量化需求的复杂度与实际开发工作量，来做出描述。
• 真实的研发行为，不能仅仅考虑这些，他们必须关注更多……

<未完待续>

ps: 附上当初《定论》的几个 link

定论——软件开发的方法论探讨(1)

定论——软件开发的方法论探讨(2)

定论——软件开发的方法论探讨(3)

定论——软件开发的方法论探讨(4)

定论——软件开发的方法论探讨(5)

定论——软件开发的方法论探讨(6)

定论——软件开发的方法论探讨(7)

定论——软件开发的方法论探讨(完)