41. Engineer in the whitespaces by Michael Nygard

【设计空白处】

架构图通常由一些方块表示互相依赖的系统，它们之间用箭头连接，箭头边上写着小小的几个字，剩下的就是大片的空白。这空白处看似什么都没有，可是在现实中，有网卡、入侵检测系统、防火墙、消息队列服务、数据格式转换服务、通信设备，甚至可能穿越万水千山。因此，在这个箭头旁，还是要把一些重要问题考虑清楚：

(1). 调用方操作太过频繁怎么办?忽略、礼貌地拒绝或者竭力满足?

(2). 如果响应超时则调用方怎么办?重试、等待或视为接收方故障?

(3). 双方收到的数据版本或者格式与期待的不一致时怎么办?

(4). 两方中的任何一方短暂消失会有什么影响?

举个例子，假设有个箭头写的是“HTTP搭载的SOAP-XML”，它可能会有这样的注释：“期待每个HTTP请求包含一条查询，每个HTTP响应发回一条查询结果。每秒最多接受100次请求，在99.999%比例下请求响应时间小于250毫秒”。

42. Talk the Talk by Mark Richards

【入行说行话】

专业人士之间常用行话交流，而架构师最重要的行话就是架构模式。模式可以按照层次范围划分为四类：企业架构模式、应用架构模式、集成模式、设计模式。企业架构模式处理高层架构，设计模式处理组件内部的架构。常见的企业架构模式有事件驱动架构(EDA)、面向服务架构(SOA)、面向资源架构 (ROA)以及管道架构(PA)。应用架构模式是企业架构内部应用或子系统架构的模式，例如J2EE中的会话面(Session Façade)、传输对象(Transfer Object)模式。集成模式是在应用、子系统、组件之间共享信息和功能的模式，比如文件共享、远过程调用和各种消息收发模式。设计模式是最底层的模式，是架构师和开发人员交流的标准词汇。还要了解反面模式(anti-patterns)，也就是那些反复出现、起负作用、需要避免的过程。常见的反面模式包括分析麻痹(Analysis Paralysis)、委员会设计(Design By Committee)、蘑菇房管理(Mushroom Management)、死亡征途(Death March)等。了解架构模式何以让我们更清楚、简洁、高效地沟通，所谓入行说行话(walk the walk and talk the talk)。

43. Heterogeneity Wins by Edward Garson

【异构取胜】

在分布式软件系统中，通信协议已经发生了一个重要的演变，就是从二进制协议向文本协议转变。文本协议，比如用于Web服务的XML/SOAP、表述性状态转移(REST)、原子资源(Atom)、可扩展消息传递及呈现协议(XMPP)，使得通信更为简单灵活，系统的不同部分可以按照自己的需要选择不同的编程语言，以便发挥最佳的效果。由此形成的异构系统，必将超越过去由单一语言主宰的系统。

44. Dwarves, Elves, Wizards, andKings by Evan Cofsky

【小矮人、精灵、巫师和国王】

RandyWaterhouse在《Cryptonomicon》中将他遇到的人分为四类，他们是：

小矮人(Dwarves)： 他们在黑暗的洞穴中辛勤劳动，制作出漂亮的物品。他们的手艺名扬四方，他们的力量改变着大地。

精灵(Elves)：他们温文尔雅，终日创造美丽神奇的东西。他们天赋极高，能实现其他种族不可思议的东西。

巫师(wizards)：他们精通魔法，无比强大。

国王(Kings)： 他们是领袖，知道如何调遣其他角色。

架构师好比是国王，该熟悉各个角色，还要保证所设计的架构中具有这些角色的位置。只为个别角色设计架构，就只能吸引个别的角色，不能发挥大家的特长。一个好国王，会给大家树立追求的愿景，会让大家各司其责，共同学习，共同成长，实现目标。

45. Learn from Architects ofBuildings by Keith Braithwaite

【向建筑师学习】

“建筑是一种社会行为，是人类活动的物质场所。”—Spiro Kostof

(在建筑中要充分考虑人和社会的因素)

“良好的教育和丰富的心灵也许能造就伟大的头脑，却不能造就伟大的建筑。”—Frank Lloyd Wright

(不断尝试和改进才能接近完美)

“医生出了错可以将死人埋掉，建筑师出了错只能让客户种爬藤遮丑。”—ibid

(避免设计错误很重要)

“建筑师坚信，不仅要做上帝身边的助手，还应该伺机取得上帝的宝座。”—Karen Moyer

(要立志精通客户的业务)

“在建筑中和在一切操作艺术中一样，最后都要归于操作。操作的结果应当就是良好的建筑。好建筑有三个条件：有用、牢固、愉悦。”—Henry Watton

(好东西不经要有用、耐用，还要赏心悦目啊)

"建筑师一定是雕塑家或画家。如果他不是雕塑家或画家，他只能做个建筑工。"—John Ruskin

(美很重要)

"听起来有点矛盾、但它的确是一个重要的真理：没有哪个建筑能达到无瑕疵的崇高。"—ibid

(好作品也带有作者和时代的局限性)

46. Fight repetition by NiclasNilsson

【消除重复】

软件开发中有两条真理：抄袭是作恶;重复劳动降低开发速度。如果一个项目的软件大量存在复制、粘贴、修改的工作方式，或者不同地方都在处理验证、审核、日志、数据持久化之类的工作，那么就有严重的重复问题。消除重复是架构师的职责。完全顺序书写的代码只适合于给计算机执行，良好的代码是给人读的，要让人读起来清楚、高效、轻松，那么就要消除重复性。使用恰当的框架(包括面向方面编程框架)、对功能进行再抽象等，都是消除重复的方法。

47. .Welcome to the Real World byGregor Hohpe

【走进现实世界】

工程师喜欢精确，01世界的软件工程师尤其喜欢按部就班的顺序处理，喜欢是非分明。可是现实世界却是凌乱的。客户下单之后很快又要取消，支票被拒付，信件丢失，付款延期，承诺落空。用户不按要求输入数据，不按规定步骤操作。分布式系统带来了更多的不一致性：服务连不通，不发通知就改接口，没有事务保证。现实就是这个样子，早晚总会出问题，你得承认它。但也别太害怕。事件驱动编程、状态机模式、错误重试等这些都是可以采用的技术。只是，在现实世界里，你要记住：星巴克咖啡店不适用两阶段提交。

48. Don't Control, but Observe byGregor Hohpe

【宁观察、不控制】

过去的系统比较简单而固定，在架构上是实现设计模型，按模型控制构建过程。但是，21世纪的软件开发中，在松耦合的基础上对软件提出了随着时间演化的柔性(flexible)要求，因此就不再能够严格控制。针对这种情况，可以先不用设计静态的结构，而是在演化中持续观察，从观察所得到的数据中抽象出当时的模型，按照规则对模型进行验证，保证它没有循环依赖、空接收通道的消息发送等问题。

49. Janus the Architect by DaveBartlett

【向雅努斯学习】

雅努斯(Janus)是罗马神话中的门神，他有两个头颅，守卫着过去通向未来的大门。架构师要向雅努斯那样，能倾听客户的诉求、分析他们的趋势。他设计出来的架构既要满足眼前的需要，又要适应即将到来的变革，经得起时间的考验。

50. Architects focus is on theboundaries and interfaces by EinarLandre

【架构师关注边界和接口】

处理复杂系统的基本策略是“分而治之、各个击破”。架构师要将整个系统划分成若干情景(Context)，各个情景有自己明确的边界 (Boundary)，情景之间有组织归属、功能使用或者技术依赖关系，这些关系通过接口来具体实现。关注边界和接口的结果，是形成低耦合、高内聚的系统。

51. Challenge assumptions -especially your own by Timothy High

【不要想当然】

因为assume(想当然)=ass(蠢驴) +u(你)+me(我)，所以想当然会使你我与蠢驴为伍。

没有事实依据的道听途说未必正确，没有事实依据的主观臆断往往是错的。即使正确的结论，也因时势的变迁而发生改变。所以，在架构设计中，但凡要在几种选项之间做出取舍的地方(比如性能与可维护性、成本与上市时间等)，都要提供选择的理由。理由不能只是简单的论断，要有考查的要素(比如技术条件、人员技能、政策环境等)及其事实依据，。

52. Record your rationale by Timothy High

【记录你的理由】

在作出技术取舍的时候，都要提供选择的理由。提供理由的方式是把它记录下来。要说明做了什么决定、选择了什么、拒绝了什么，为何选这种而不选那种。这些文档可以让开发人员理解架构设计的内在逻辑、让客户理解为何某些部分要求更加昂贵的硬件设备、让将来条件改变以后对系统架构进行修改更容易。

53. Empower developers by Timothy High

【培养开发人员】

架构师要尽力培养开发人员。为他们提供足够的设备、网络、数据、资料。保证他们具有所需的技能，不足的就要安排培训。开发人员除了能动手实践，还要参与学术讨论，所以如果有出差经费的要让组员参加各种宣讲或会议，没有经费的也要加入技术性的邮件列表并参与本地的一些活动。平庸的团队不可能做出大事情，要尽可能参加选择开发人员的过程，寻找那些对技术好学上进并且善于与团队合作的人。在和软件设计的大目标不冲突的地方，要让开发人员自主决策。制定编码原则、编码规范。保护开发人员免受不必要的文字工作、办公室杂务等打搅。架构师虽然不是项目经理，但在软件开发过程方面要积极参与管理，消除各种障碍。

54. It is all about the data by Paul W. Homer

【软件都跟数据有关】

一般讨论编码的时候，都是站在面向指令的视角，讲命令、函数、算法。可是要理解一个复杂的系统(比如UNIX操作系统)，就很难在成千上万行代码中理出头绪。这时，如果我们关注代码下面的数据(比如UNIX系统的文件、进程等)，就相对容易理解些了。形成这种对比的原因是代码很庞杂，而数据则很简洁。后者就是面向数据的视角。大多数问题的核心是数据问题。关注数据，能更容易地处理复杂系统问题。要在系统建设早期完整地设计数据结构，避免在系统建设过程中或投入运行后再来修改数据结构。数据结构修改将导致大量的代码修改。

55. Control the data, not just thecode by Chad LaVigne

【控制数据，而不只是代码】

只有由代码自动构建程序的工具是不够的。手工或者编写脚本来修改数据库、添加数据不仅效率低下，而且容易出错。自动构建工具不仅要考虑代码的变化，还要考虑数据结构的变化，它们是不可分割的一个整体。

56. Don't Stretch The ArchitectureMetaphors by David Ing

【不要让比喻误导他人】

在描述抽象或新的设计时，架构师喜欢使用比喻。可是，比喻容易让人误解。比如，“一个游艇一样的系统”，言者可能指的是池子里的小船，而听者理解的是横跨太平洋的豪华游轮。又比如，“一个文件柜”，言者只是想表示内容是按字母排列的，而听者却想的是文件柜有六个面、上面还嵌入了一个钟表。只在开始的时候使用比喻，然后要迅速转入精确的描述，不能停留在比喻上。

57. Focus on Application Supportand Maintenance by Mncedisi Kasper

【关注应用支持与维护】

很多架构师出身于开发人员，因此他们过多地关注开发阶段而很少关注软件系统运行以后的支持和维护阶段。其实，一个软件系统的生命周期中，支持维护阶段超过80%以上的时间比例。所以，设计之初，就要关注支持维护。要注意，支持人员和开发人员不同，他们没有IDE工具，没有复杂的测试工具，也不能随意关闭和启动生产系统。系统要给他们提供足够的问题跟踪、审核、分析手段。只有系统管理员满意了，才会大家都满意。

58. Prepare to pick two by Bill dehOra

【学会三选二】

著名的Brewer猜想说：对于现代分布式应用系统来说，数据一致性(Consistency)、系统可用性(Availability)、服务规模可分区性(Partitioning)三个目标(合称CAP)不可同时满足，最多只能选择两个。

59. Prefer principles, axioms andanalogies to opinion and taste byMichael Harmer

【多用原则、公理和民意，少用观点和偏好】

架构师个人的观点和偏好需要结合项目的实际情况进行仔细分析、充分论证，才能作为架构设计的依据。而原则、公理和民意，相对可以直接地作为架构设计的依据。所以，要提高架构水平和提高效率，可以多用原则、公理和民意，少用个人的观点和偏好。