2.RUP就是“杂物箱”
      我也许总是在批评RUP，但是不得不承认它是对前人在软件过程思想方面的高度包容。请注意我用“包容”这个词，而不是按照语言习惯那样用“概括”。因为如果是“高度概括”，那就应该把目光投向瀑布模型，而RUP其实就像一个杂物箱一样“包容”了全部的已知理论。
      可以把RUP定制成其它任何模型所表述的过程形态——RUP本身的特质决定了这一点——因而它也如同一个杂物箱一样放满了各种希奇古怪的东西：你可能从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者是一根钓杆……
      面对“软件开发”这样的需求，钓杆能有什么作用呢？在你扔掉它之前，请转换一下思维：钓杆可能带给你的团队以精神上的激励。如果你能意识到这一点，那么它将立即转化为生产力——请把钓杆挂在开发部的墙上。
      RUP能不能被用起来，将取决于你刚才那个挑挑捡捡的行为，以及在你拿到“钓杆”后的辨识能力与组织能力。

3.UML与甲骨文之间的异同
      在你真的打算用“甲骨文”来写项目文档之前，请先弄明白UML与甲骨文之间的异同。在本书里，它们都被做为沟通的工具。因此，目标是沟通，而不是“选用工具”。更进一步的推论是：即使你因为个人喜好而选择了甲骨文，也不要试图在结绳记事的原始人面前去用它。UML与甲骨文都是符号文字，都具有像形含义。然而，这并不表明UML符号本身能表达多么丰富的含义。如果要像甲骨文一样用几代人、上千册的论著去解释它，那么UML图的价值也就只剩下象征性意义了。
      出于沟通的必要，UML语言的象征意义在一个图中应当被表述得足够准确和详细，以致对于不同的阅读者来说都提供了充足的信息。然而，一方面UML的规范中没有提供一个标准来衡量“怎样的UML图是描述充分的”；另一方面，UML作为一个语言，也无法直接在某个硬件平台中被语法检错和调试。所以在工程中使用UML图，应该有相应的文字来描述它。而且，这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的将是无异于甲骨文出土时的困境。好在做UML图的那个工程设计人员(在辞世之前)还有机会为这些古怪符号写下规约。

4.经营者离开发者很远，反之亦然
      使我第一次意识到EHM模型反应了角色所关注的不同视角的人，是我的老板。
事实上，他是一个完全不懂软件技术的老板。在EHM模型中，他所处于的位置在最右端，而开发者在最左端，在二者之间没有相同的关注界面(关注点)。EHM真实地反应了“老板不懂技术”的合理性，同样也真实地反应了“开发者转型为老板”的道路将是相当地漫长与艰难。
      于是，担任中间角色的项目经理就有了一种使命：协调经营者与开发者之间的沟通。例如招来一名开发高手，对于公司的运作并不会有深入的影响(当然，如果你招来了Anders Hejlsberg就另当别论)。因此，我甚至不需要与BOSS讨论这名高手的来历及作用。同样，与一个技术分析人员讨论一个产品的技术价值、市场价值之间的差异，以及市场运作方式与技术实现手段的无关性是毫无必要的。
你要理解这种根源：角色的关注层面完全不同。

5.矛盾：实现目标与保障质量
      在需求阶段我们会面临“目标”的问题,然而在大多数时候，与此相反的是我们会在项目交付和试用时才会碰到客户在质量上的投诉。
      需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚或者变更的没完没了。如果正巧需求和开发都是由同一个人或者同一小组来做的，那么他们便会开始埋怨客户的苛刻以及工期的紧张。
总之一件事，没有人会跳出来说：我们原本就错了。然而，事实上根本问题可能是：我们把目标定错了。
      可以看到，在项目的平衡三角(时间、资源和功能)中讨论的是目标问题，但并不讨论质量问题。也就是说，经典教材中总是关注如何更快的完成项目，并减少资源占用，以及实现更多的功能。但是，即使平衡了这种关系，项目的结果仍可能产生一个天生的残障。因为目标可能在平衡中确立，但质量却要在过程中控制。即使在时间、资源和功能三者中取得了平衡，并且客户、项目组和公司同样满意于这个平衡“目标”，但它仍然有可能是“不能实施”的。
      如果原定的目标本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保障不了质量。
      问题是：又有谁愿意在最初签订协议的时候，就降低或者放弃协议标准呢？

6.枝节与细节
      前面说到目标和质量的问题时，提及“平衡时间、资源和功能三者的关系”。这其实是一个实施过程中的细节。或者说，它是一个具体的方法，而不是目的。
      所以我们通常所说的细节，其实是对实施方法的一些有限量的描绘。比如“软件工艺”概念本身的提出，就是考究“细节问题”的。从这个角度上来说，我并不反对“细节决定成败”的观点。但请注意一个前提：这是技术或方法的细部。
      我在前文中一再地混用了“细节”与“枝节”这两个词。枝节是事实发展的次要的分枝，它不涉及行为本身，也不是对行为本身的考量。因此我在前面的文字中说到“跳出细节”，本意是“跳出枝节”——细节只有做到何种程度的问题，而并不是关不关注(或做不做)的问题。
大多数情况下，管理人员有责任去审核、评估其它成员的工作成果。这个时候可以讨论“细节决定成败”类似的问题，因为这决定了产品的最终质量，而质量是工程的目标之一。
      而在另一些情况下，例如管理人员做事件决策的时候，就必须要学会忽略枝节问题。
      混淆这两个名词的使用，其根本原因在于一大部分读者并不能区分“细节”与“枝节”。从惯于“实做”的程序员一路走来的工程人员，很难分清自己什么时候是在“工作”，而什么时候是在“决策”。
      因此我只好用最笨的方法提示管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点回头。
      用脚趾去感觉，有时比用头脑去思维来得有效。

7.灵活的软件工程
      并不像现代人想象的那样，古诗词一定是“逐字论平仄”的。变化或者变通，其实是常见之事。因此古词谱中，才常会见到冠以“摊破”、“减字”、“添字”等字的词格。然而古人在词格上的这种变通，是基于“音律”的。通常说的词律是指词格，这与音律是两回事。词律(格)是平仄，音律则是乐器、音调与歌舞。古词中用来吟唱与歌舞的词牌就不能混用，律不同，调不同，如是之。然而古词的音律(亦即是律谱)已经失传了，也就是说，今天的词是用来读的，不是唱，也不是舞，甚至连吟哦也不是。所以今人总是拿普通话中的一、二声作为平声，三、四声为仄声来填词，并以此论平仄，而全然不想词的格律的根基是“词律”与“音律”这两个部分的融合。
      我曾经参与过一个讨论，叫“古人是如何说话的”。在我看来，古人做文章和说话是两回事，文章中之乎者也，日常交流中还是市井俚语的。因此评论中会说“以俚语入词”。也可见填词做文章与说话毕竟是不同。再者，说话也存在方言的问题，因此方言之间平仄音调也不尽相同。古代的歌妓是要求会“官话”的，这相当于现在“普通话”的地位，她们歌唱起来，也是用的“官话”。
      更进一步的推论是：古代的词律中的平仄是以官话为基础的。然而如今的普通话毕竟不是古时的“官话”。也就是说，即使我们以普通话的四声为基础讨论平仄，在古人看来，也是可笑的，这样做出来的词依旧不可唱，也不可读。因此今人做词的标准是应该重定的了，除了词格(这里仅指字句的格式)和用韵之外，其它的部分是无法遵循的了。在各自的平仄以及句式上，应当以“能通顺”和“能品味”为准，风格上则以古雅为益。
      仅此而已。
      对于我这样的格律观点，一位网友曾有一句“未蕴而变，自欺也；知律而变，智者之道也”，实为良言。变向不变求。不变者，万变之所源，亦万变之所归。习诗词之法度，若蚕虫之结茧，若无结茧于前，何有破茧于后？故，知律而变，智者之道也。
      “知律而变”中的“律”字，若解释为“规律”，便是可以用于软件工程中了。“道”是规律，如果明“道”，而可以变化无穷，这样做软件工程才是活的。就如同今人难于填词一样，不明道，则不明智，不明智则无所以为，因而在软件工程实施中不可避免地盲目与停滞。
      “知律”的另一层意思，是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题，大多数人不知究竟地使用着技巧和方法，而一旦出了问题，则归咎于这些技巧和方法的不好。而真正的问题在于，这些人(我们通常叫做Copy&Paster)并不知道这些技巧、技术和方法的原理，因而不知道变通，也不知道回避错误。
      死读一本《软件工程》的人不会做真正的软件工程，所以我写了本书，聊做软件工程实践者的思想之著。