80. Don’t Be a Problem Solver by Eben Hewitt

【不做解题机】

作为一个架构师，要处理的问题是方方面面的。不要在开发人员一遇到编程问题就帮他们解答。很多问题往往他们自己可以查资料找到答案。帮助他们解答简单的问题是放弃了处理更复杂问题的机会。

作为一个架构师，要知道解决问题的最好方式就是避免发生问题。不要对所有问题一概接收，要使用成熟好用工具，一开始就避免发生问题。没有问题，比解决问题好。

81. Choose your weapons carefully,relinquish them reluctantly by Chad LaVigne

【在恰当的时候，鸟枪换炮】

架构师的武器库中，有自己历经大小战役的各式武器。新武器纷纷出世，该换的时候就得换。但换武器也得考虑时机。

一要评估风险：新武器是否适用于眼前的项目?

二要评估成本：掌握新技术所花费的人力物力是否负担得起?

三要评估形势：看中的武器是昙花一现还是大势所趋?

82. Your Customer is Not YourCustomer by Eben Hewitt

【客户的客户，才是我们的客户】

当讨论需求的时候，不要只顾着听客户的陈述。客户也许不了解他的客户想要什么。而找出他的客户(系统的终端用户)的真实需求，是系统成功的必要条件。所以说，客户的客户，才是我们的客户。要关心客户的客户。

83. It will never look likethat by Peter Gillard-Moss

【系统不会是设计的模样】

在一个永恒变化的世界中，设计是一个持续进行和经验实证的过程。无论当初设计如何深入细致，系统永远不会像设计的那样变成现实。某些情况总会发生，某个外部因素总会影响系统，甚至内部某个人的代码也会出现异常。或者设计依赖的某些信息出错，或者推论不正确，或者混淆了某些概念的细微差别。也许需求变了，也许技术更新了，也许某人找到了比你更好的方法。这些微小的变化促使你修改设计，从一个版本到另一个版本，直到你不堪忍受。

84. Choose Frameworks that playwell with others by Eric Hawthorne

【选择好搭配的框架】

在选择框架的时候，不仅要看它是否在自己擅长的领域做得好，还要看它是否容易和其它框架搭配。对框架的要求是：谦虚、简单、专业。所谓谦虚，是指不妄想包揽自己不擅长领域的工作，不和其它框架重叠。

85. Make a strong businesscase by Yi Zhou

【搞定一个强大的业务专案】

以下五步，助你做成一个强大的业务专案。

建立价值提议：你的新软件架构有什么价值?和其它架构相比如何提高生产能力和效率?

制定量化指标：带来的丰厚回报包括哪些合理的数据指标?

换成传统标准：把这些数据指标换算成传统的业务标准——金钱，它们是多少?

了解何处停手：向项目干系人了解，这项提议在哪些业务上应用以后，能够适可而止?

寻找恰当时机：什么时候用户比较能接受我们的提议?比如另一个架构惨遭失败的时候。

86. Pattern Pathology by Chad LaVigne

【模式病】

模式是为了交流和理解而总结的设计方法。在设计上使用模式，要考虑实用、高效。如果为了炫耀自己关于模式的知识，在设计中塞入大量模式，那就犯了模式病。要以高效的解决方案为中心，只采用那些的确能解决问题的模式，避免犯模式病。

87. Learn a new language by Burk Hufnagel

【学习新语言】

要学习业务部门的业务语言，才能和他们有效沟通。

要学习编程人员的技术语言，才能和他们有效沟通。

88. Don't Be Clever by Eben Hewitt

【不要聪明要愚笨】

做人，尤其是做架构师，确实是需要有思想、有知识、有远见。可是，我们设计的架构却应该反过来，不要聪明，要愚笨。所谓愚笨，就是简单，坚持一个组件只能在确定的条件下做一件事。聪明的组件造价高昂，维护艰难。愚笨的组件开发容易，维护简单。聪明的架构在现实面前往往脆弱不堪，愚笨的架构却生命长久。

89. Build Systems to be Zuhanden byKeith Braithwaite

【建造应手的系统】

应手(德文zuhanden)和在手(德文vorhanden)是哲学家海德格尔创造的概念。应手的东西是人在达成他的目标时随手可用的工具，它近乎成为人身体的一部分而不需要关注，只需要使用。在手的东西是需要人时刻关注的工具，它要显示自己的存在，要强调自己的权利，以致于主人因注意它而难于接近目标。我们建造系统的时候，容易把系统看得太重，建造出在手的系统。但一个真正好的系统，应该是应手的系统，对于用户越透明越好。

90. Find and retain passionate problemsolvers by Chad LaVigne

【寻找和挽留有激情的问题解决者】

组建一支好的开发团队，要靠出众的开发人员。开发人员不仅要有丰富的知识，更要有解决问题的热情和技能。选人的时候，不要太关注知识，而忽略了热情和技能。

91. Software doesn’t really existby Chad LaVigne

【软件无形】

软件工程和传统的土木工程比起来，具有产品无形的特点。无形意味着我们可以不按土木工程那样的顺序来建造，这是它的好处。可是，无形也有坏处。用户容易产生误解，以为软件可以随便修改、可以中途大幅度地变更需求。

92. Pay down your technical debtby Burk Hufnagel

【偿还技术债务】

一个使用中的系统，总有一天会出现BUG或者要增加新特性。这时候有两种相反的意见。客户要求尽快解决，而开发人员却要求慢慢设计、修改、测试。面对这样的矛盾，架构师就会想，不如走条捷径，把问题应付了事。但是，在技术问题上，没有捷径可走，该做的工作总要做。捷径不仅有快的一面，也有脏的一面。把脏东西放到系统中，增加了系统的不稳定性，提高了将来运行维护的成本。第一次不做好，以后就要付出利息。所以，要看客户的要求到底有多急迫，是否值得付出技术上的利息而做那种匆匆忙忙的发布。如果一定要尽快发布，也不要发布了就止步不前。要马上投入新工作，提供良好技术解决方案，尽快偿还欠下的债务。

93. You can't future-proofsolutions by Richard Monson-Haefel

【不能做面向未来的方案】

人不能预测未来是一条普遍的真理。未来不是十年二十年那么漫长的时间，未来就在这确定的一刻之后。周一活生生见面的人，周二却传来撞车的噩耗，这便是未来不确定的例证。今日选择的语言会成为明日的COBOL，今日选择的框架会成为明日的DCOM。要弄明白今日的需求已是不易，想知道明日的需求终归徒劳。不如务实一些，就提供对今日需求的最佳解决方案吧。

94. The User Acceptance Problem byNorman Carnovale

【用户接受问题】

人们往往难以接受一个新系统或者大升级。究其原因，有以下几种：

(1) 有的人担心新系统替代老系统后功能无法使用，自己失去影响和权力。

(2) 有的人害怕未经检验的新技术。

(3) 有的人担心成本/预算。

(4) 有的人只是不喜欢变化。

针对不同的担忧，用培训、演示等方式与用户分享新系统带来的好处、新系统的局限，促进用户接受新系统。

95. The Importance of Consommé by Eben Hewitt

【清汤的重要性】

美味的牛肉清汤需要精心制作，要剔除众多杂质才能得到。据说有的烹饪学校的老师把十美分硬币放在碗底进行检验，能透过汤看清硬币上的日期的，才算好汤。软件架构也需要反复提问、反复调整，需要去除各种杂质，直到只剩下简单、可核实的关于系统真实特性的描述。

96. For the end-user, the interfaceis the system by Vinayak Hegde

【对于终端用户，界面就是系统】

不管你的系统有多先进和与众不同，如果它的用户界面让人痛苦，就等于系统让人痛苦。有很多好系统被坏界面给遮蔽了。要把用户界面当作软件项目中的重要决策之一来对待。

97. Great software is not built, itis grown by Bill de hora

【伟大的软件不是建造出来的，它是生长出来的】

虽然软件要进行架构设计，也从建筑和工程中借鉴了很多比喻，可伟大的软件不是建造出来的，它是生长出来的。一开始就建造庞大的软件，很容易失败。我们要有宏大的远景，但是必须要在小处下手。先做一个小的系统，再慢慢演化升级，向心目中的远景靠近。