1. Don't put your resume ahead ofthe requirements by Nitin Borwankar
【需求先于履历】
身为架构师要平衡客户、公司和个人的利益。用时兴的技术为个人履历增光添彩固然重要，但应该把客户的长远需求放在首位。约束技术偏好，能够使客户、团队、自己和家人都多些快乐。在未来的工作中，客户的口碑是比个人的履历更加宝贵的东西。
2. Simplify essential complexity;diminish accidental complexity by NealFord
【简化先天复杂性，避免后天复杂性】
任何业务问题都有其复杂性，简化复杂性是客观需要。但为此采取的工作很可能带来新的复杂性。了解代码中真正用于处理业务的比例，从实践中发展出恰当的系统框架，避免随意添加框架。后天复杂性的积累会使系统越来越难以维护和升级。
3. Chances are your biggest problemisn't technical by Mark Ramm
【技术不是最大问题】
聪明的架构师能够选择最恰当的技术，而有效的架构师则还要说服开发人员理解他的选择。软件是由人开发的，人心不齐才是最大的问题。有时人的问题导致项目失败，却让技术来背黑锅。必要时应进行平等的对话、理性的分析、耐心的解释。
4. Communication is King; Clarityand Leadership its humble servants byMark Richards
【沟通为王，澄清和引领为仆】
闭门造车、发号施令的架构师必将被反抗的开发者所推翻。架构师应就项目的宗旨和目标与开发人员沟通。有效沟通的要点是简明和垂范。抛开长篇大论的Word文档，使用清晰易懂的Visio图形;讨论时使用白板，对重要的内容拍照记录。与QA、PM和开发人员密切合作，让他们了解架构过程，洞悉架构全景，引领他们走出迷茫。
5. Architecting is aboutbalancing by Randy Stafford
【在平衡中进行架构】
架构工作包括模块划分、接口定义、职责分配、模式应用、性能优化等传统技术活动，也要考虑安全、可用性、支持、发布、开发条件等问题，更要照顾管理人员、操作人员、维护人员等有关各方的关切。要在平衡各方关切的过程中开展架构工作。
6. Seek the value in requestedcapabilities by Einar Landre
【鉴别客户要求中的价值】
客户往往把他们的思考作为解决他们所面临的问题的方案。但客户要求未必都是对解决实际问题有价值的。架构师应当提出更好、更节约的解决方案。这一目标可以通过和客户进行讨论达到。和客户讨论时，多从业务角度问问为什么，少使用软件术语，不要假定客户具有软件方面的知识。
7. Stand Up! by Udi Dahan
【站着说话】
架构师和项目组成员的沟通，不应象过去和机器打交道一样随意。当你的听众超过一个人时，自己就应当站着说话。站着说话的好处是有指挥整个房间的气势，增加了你的权威和自信，别人更不容易打断你的话。站着说话还能使用眼神交流、肢体语言，也有助于控制声音。站着说话，能提高沟通效果。
8. Skyscrapers aren't scalable byMicheal Nygard
【摩天大楼不可伸缩】
把软件工程比喻成盖楼，有好的一面。从荒芜的工地到耸立的高楼，过程漫长。每一段时间中，每一个工人都要各尽其责，每一个未完工的构件都要稳稳当当才行，值得软件工程学习，这就是一次一个组件的增量部署。这个比喻也有不恰当的一面。摩天大楼在造成以后就不可搬迁、不可加层。而软件则可以反复调整，这就是“及早发布”(Early release)。
9. You're negotiating more oftenthan you think. by Michael Nygard
【谈判多过你的想象】
我们作为工程师，更愿意与人协作。而项目负责人作为控制项目成本的人，更在乎削减成本。我们看到的是谈话，他看到的是谈判，所以我们常常遭受预算打击。如果你提了冗余、备份之类的东西后，他问你“这个东西必须要有吗?”,千万不要让步。不要说“没有也行，只是会在故障恢复期间不能运行”这样的话。反而要说：“事实上不仅要两套，要四套才能确保万无一失。没有这个，每天就至少会有三次出问题，而且不排除当你正在给董事长做演示的时候出问题。”
10. Quantify by Keith Braithwaite
【量化】
需求必须量化。“快”、“好”、”伸缩性”、“可用性”、“灵活”、“极少”、“大量”等都不是需求，因为它们不可量化，这些词找不到客观的衡量标准。谈需求的时候，必须说明数目、时间、来源、去向，不能准确给出数值的，必须指明一个具体的范围。例如：最大响应时间1500毫秒，平均响应时间为750至1250毫秒。
11. One line of working code isworth 500 of specification by Allison Randal
【一行正确代码胜过千言万语】
设计说明是宏观描述，代码则是微观实现。可是如果设计说明脱离了编码实现，犹如违背物理学原理的大楼设计，纵使它美轮美奂，也会转眼间土崩瓦解。架构师做设计时，要时刻想着编码人员如何实现它。设计完成后，如果程序员提出质疑，往往就是设计有问题，至少是设计不清晰。对设计进行再修改是正常的事情。
12. There is no one-size-fits-allsolution by Randy Stafford
【没有通用解决方案】
一双鞋难合千人脚，过去积累的经验未必适合现在具体的应用情景，架构师要坚持锻炼自己的情景意识，按照新的情景进行设计。想要打造一个通用的解决方案往往造成过度设计，添加大量无关宏旨、甚至影响性能的不合理要求。
13. It's never too early to thinkabout performance by Rebecca Parsons
【尽早考虑性能】
用户通常只会提出功能需求。架构师要尽早考虑非功能需求。性能测试也要及早展开。
14. 14.Application architecturedetermines application performance byRandy Stafford
【软件系统架构决定性能】
如果架构不良，性能就不会良好。资源不是无限的，动用再多的性能调优手段，到头来也是束手无策。
15. Commit-and-run is a crime. by Niclas Nilsson
【带错提交是祸害】
下班时间到了才写完最后一行代码，干脆省略了编译、测试的过程，直接提交代码，迅速奔赴约会。这种做法使得隐藏的错误随着项目组其他开发人员更新代码而扩散，导致其他人不敢更新代码，打乱了大家的工作流程。个别开发人员把自己该做的工作留给他人是错误的。当然，架构师也应考虑给开发人员创造好有利的环境。比如，自动构建工具、自动测试工具、测试驱动开发实践、持续集成服务器等。
16. There Can be More than One by Keith Braithwaite
【世界并非千篇一律】
技术上能做到强求统一，实现一套数据模型、一种消息格式、一套收发系统，如此等等。可是业务世界往往是不一致、多侧面、甚至模糊的。统一的设计未必能满足各种业务要求，应当要允许那些互相矛盾、重复或交叉的非功能特性存在。
17. Business Drives by Dave Muirhead
【业务决定技术】
为了建设一个系统，架构师必须把技术部门和业务部门团结在一起。但要明白二者的立场是不同的，避免技术人员作出业务决策。建造系统通常都是讲求投资回报的，从开工到投产要不断遇到各种技术上的决策，要一直以满足业务部门的要求为准则，才能获得最大的投资回报。如果业务部门对技术部门的提问迟迟不予答复，那么可以视为委托开发团队考虑。即使这样也不能直接将问题交回给技术人员，因为业务问题是宏观问题，技术决策是微观问题。架构师应当组织讨论并拿出答案。
18. Simplicity before generality,use before reuse by Kevlin Henney
【先简化再泛化、先使用再重用】
用户掏钱买的往往不是什么通用的功能，大多数时候他们只看重其中自认为重要的部分。设计的产品要先满足具体的要求，经过实践并简化掉那些不必要的东西，才能进行泛化推广;要先有使用的机会，才能带来重用的机会。如果一开始就以通用、重用为目的闭门造车，结果很可能是无用、难用、弃用。
19. Architects must be handson by John Davies
【架构师必须是注重实践】
架构师不是空谈家，他必须在数据库、软件编程、数据信息、网络等某一领域有专长并且通晓其它领域，换句话说，他要想带领团队就必须知道团队成员需要知道的技术。架构师和项目经理，好比飞机上的副驾驶和驾驶。飞机常常是副驾驶操纵，可是关键时刻得看驾驶的。项目经理忙于日常任务安排、资源调配，而架构师看似清闲，而在技术决策中要提出重要的意见，对保证项目的质量和按期交付起着很大的作用。
20. Continuously Integrate by Dave Bartlett
【持续集成】
过去软件项目中提倡及早构建、及时发布，以便尽早发现风险、避免风险。随着自动构建技术日趋成熟，现在已经能够做到持续集成了。持续集成(CI)工具可以自动构建、测试，在完成时还能向外发送电邮或即时信息。
#p#
21. Avoid Scheduling Failures byNorman Carnovale
【避免延期】
人的工作能力是有限的。同样的工期内要增加工作量，就难免延期。不增加工作量但是强求缩短工期反而常常导致延期。因为，赶工通常造成设计不良、缺陷数量上升、测试不足等问题，日后处理这些问题反而需要更多的时间。因此，碰到有人要求缩短工期，应坚决主张原定工期。确实必须缩短工期的，就要将部分非必需功能从开发任务中剔除，留待下一期开发中去处理。这是一个协商谈判的过程，架构师要有一定的技巧才能处理好。
22. Architectural Tradeoffs by Mark Richards
【架构中的取舍】
没有哪个系统能同时做到高性能、高可用、高安全、高通用。架构师要带领同事和客户开诚布公地沟通，先满足重要的目标，再满足次要的目标。
23. Database as a Fortress by DanChak
【数据库即堡垒】
开发团队的人员是流动的，用户的人员也是来来往往的，但是架构师要保证有一个东西不变，那就是数据库结构。从项目的第一天，就要抱着建造堡垒一样的态度设计数据库，使它能经历时间流逝和需求微调的考验。
24. Use uncertainty as adriver by Kevlin Henney
【以不确定为动力】
生活中人们期待有多种选择，可如果自己设计软件，却往往喜欢省事，在几个选项中只采用一个。如此一来，软件对用户就不那么平滑顺手。一个设计是否良好，是用修改所需的成本来衡量的。当遇到技术上的选择时，不要匆忙决定，要退一步想想有没有不进行选择的办法?只在是非分明、条件明确的情况下才需要选择。
25. Scope is the enemy ofsuccess by Dave Quick
【项目规模是成功的敌人】
架构师如果好大喜功，不切实际地扩充项目的范围，在时间、人力、物力、功能、质量等级、交付难度、风险系数、约束条件等方面不断加码，使项目变大、变复杂，那么就是在促使项目走向失败。当项目规模扩充时，失败的可能性也在以更快的速度增加。以下是避免规模增长的几个策略：
(1). 求真务实：真实的需求是什么(客户的底线在哪里)?
(2). 各个击破：这个项目不能再分解成几个各自独立的小项目吗?
(3). 主次有别：哪些是重要而稳定的需求?哪些是次要而易变的需求?
(4). 及早发布：错误是不可完全避免的，早点让用户见到作品就是给自己留下改正错误的时间。
26. Reuse is about people andeducation, not just architecture byJeremy Meyer
【重用要靠受过教育的人员】
一个设计良好、漂亮、可重用的框架或者代码库，只能由了解它、会用它、相信它的人来使用。
(1). 了解：没有人会去查找自己不知道的东西，只有在公司中将它的信息推送到开发人员和设计人员面前，他们才会了解它。
(2). 会用：一点便通的人很少，大多数人必须经过培训才会使用它。
(3). 相信：新来的人往往瞧不起旧的东西，他们倾向于通过重头编写来证明自己的才能，要设法让他们相信重用成熟稳定的组件框架胜过自己编写。
27. There is no 'I' inarchitecture by Dave Quick
【架构中没有“我”字】
不成熟的架构师爱犯的毛病是：以为自己比客户懂需求;把开发人员看作实现自己主张的资源;听不进和自己不同的意见。
以下认识有助于架构师的成长：
(1). 不是架构师决定架构，是完整准确的需求决定架构，因此要密切接触客户进行需求分析。
(2). 架构不是架构师一个人的，是整个团队的，架构师需要队员远胜于队员需要架构师，因此要从心底尊重他们、团结他们。
(3). 模型不算是架构，只有能用的模型才是架构，因此要和组员一起进行演练以便检查确认模型能支撑需求。
(4). 自我肯定、自我保护是人的天性，遇到压力便表现出来，因此要每天花几分钟审视自己：是否对他人表达了应有的敬意和谢意?是否冷淡了他人的善意?是否真的明白他人为何与自己意见不同?
28. Get the 1000ft view by Erik Doernenburg
【生成低空视图】
要了解地面的情况，需要适当的高度。在30000英尺的高空只能看到大块的轮廓，不能看到它的结构;在地面则迷失在身边的细节里而失去整体感觉;在大约1000英尺的低空，刚好能看清楚地面的结构。类似地，要了解软件系统的质量也要适当的距离。系统架构图太宏观，很多关系不清楚;源代码又太微观，关系太琐碎;只有在类和方法这一级生成图表，才能评估软件的质量。
29. Try before choosing by Erik Doernenburg
【试了再选】
选择哪一个框架?使用哪个代码库?架构师不能坐在象牙塔的顶端做出设计并颁布给开发人员使用。在做出技术选择之前，他应该放低身段，找开发人员商量，让他们对可选的几种方案分别实现，再提出各自的建议，最后由架构师综合分析决定使用哪一种方案。
30. Understand The BusinessDomain by Mark Richards
【了解业务领域】
软件架构既要采用高超的技术，又要深刻地反映业务领域的特点，才能实现业务目标。比如，保险业适用面向服务的架构，金融业适用基于工作流的架构。了解业务的最高标准，就是能用业务语言和公司的老总级人物交流。业务领域的知识是不断更新的，比如汽车保险业新出现的一种临时停车保险，就是一种新的业务动向。能够把握领域发展动向，就能未雨绸缪，当公司有需要时可以迅速提出解决方案。
31. Programming is an act ofdesign by Einar Landre
【编程是创意设计，不是照图施工】
汽车厂要出一辆新汽车，必须经历概念车创意设计、流水线生产这两大阶段。软件编程中，主要的工作是都是创意设计，很少照本宣科的。既然大家都知道设计新车型、开发新药物这样的工作往往不能按时完成，也不能确保成功，那么我们也不要指望软件编程可以精确预测。
32. Time changes everything by Philip Nelson
【时间改变一切】
随着时间的流逝，当初各路高手所设计的高瞻远瞩、机关算尽的框架、模式、范例、算法，有的如过眼云烟般消散得无影无踪了，有的则最终流传下来。历史带给我们三个启示：
(1). 坚持有价值的领域：如果我们熟悉的领域已经没有价值，要勇于探索新的领域，即便早期的尝试不成功，也要克服困难坚持下去，正确的领域总会有正确的方案，尽管它也许来得很晚。
(2). 简单规则：克服我们自身把问题复杂化的倾向，让方案保持简单。想一想，那些复杂的东西，如今哪个还在呢?
(3). 珍惜旧东西：虽然过去的东西不完全适合于现在的情景，可是把经历了时间考验的东西修一修，不是也很有把握满足新的需要吗?
33. Give developers autonomy by Philip Nelson
【让开发人员自治】
架构师的职责不是要对开发人员如何工作进行指点。架构师的责任是在开发人员致力于编制类和方法、进行单元测试、创建数据库时，保证这些部分合在一起能正常运行。了解他们的痛处，做出对应的改进。测试困难吗?那就改善接口并减少依赖。领域抽象性不够或过度?那就澄清它。开发顺序不清楚?做个计划吧。开发人员使用API时总犯相同的错误?那要把API的设计调整得更简单明白。人们真的理解设计吗?和他们交流阐述吧。不确定哪些地方需要伸缩性吗?去和客户交流并了解他们的业务模型吧。总之，架构师要给开发人员创造一个工作环境，而不是干涉开发人员份内的工作。
34. Value stewardship overshowmanship by Barry Hawkins
【做管家，不做演员】
管家是为雇主精打细算的人，演员是为观众哗众取宠的人。
架构师提出的解决方案，关系到公司的人力、财力、物力和时间。公司把架构师职责授予一个人，他就要替公司平衡投入和产出比例。正如理财师要对客户承诺收益率一样，架构师也要时刻考虑公司的收益，而不能把项目当成自己显摆的舞台。
35. Warning, problems in mirror maybe larger than they appear by Dave Quick
【问题可能大于表象】
项目中出现问题，往往得不到重视，最后难于收拾。原因主要有：
对问题习以为常的温水煮青蛙效应;
人们对新经历、新知识的畏惧心理;
开发人员不以为然的乐观主义倾向;
组员只关心个人目标不重视全局目标;
人都有盲点，尤其是对自己的缺点视而不见。
要克服以上不利因素，可以从这几方面着手：
建立组织级别的风险管理机制;
不搞少数服从多数，要鼓励悲观论调并进行讨论，进而提出中立的对策;
敞开心胸，不断听取客户意见;
让自己信任的人指出自己的盲点。
36. The title of software architecthas only lower-case 'a's; deal with it by Barry Hawkins
【软件架构师是新兴职业】
软件架构师是一门新兴的职业，可是它具有律师、医生、建筑师一样的精英特质。大家努力吧!
37. Software architecture hasethical consequences by Michael Nygard
【软件架构也有伦理后果】
说到人权、身份盗用、恶意程序等等，人们知道软件架构可以助人行善，也可以助人作恶。其实除了大是大非问题，平时很多地方都值得进行伦理思考。比如说，一个软件好用则千万个用户都省事，一个软件难用则千万个用户都麻烦，他们的轻松愉快或者垂头丧气不就取决于我们架构师吗?为了他们长久的简便，我们要承担一时的幸苦。软件影响太多的人了，不要设计违背伦理的软件，哪怕一点点都不要做。
38. Everything will ultimatelyfail by Michael Nygard
【万物皆会出错】
硬件会出错，所以用冗余来对付。
软件会出错，所以用监控软件来对付。可是监控软件也是软件啊，所以错误还是不可避免。
网络是由硬件和软件组成的，所以网络的错误就是难免的了。
怎么办?我们不能拒绝错误，我们必须接受错误。承认万物皆会出错，接着设计出适当的失败模式，才能让我们的系统安全地出错。例如，承认汽车是会撞车的，然后设计可压缩的部件来吸收撞击的能量，起到保护乘客的作用。在软件系统中，如果不设计失败模式，失败偏偏就会让你措手不及。
39. Context is King by Edward Garson
【情景为王】
情景为王，简单性是它谦恭的仆人。所谓情景，指的是业务驱动力、新兴技术和思想潮流。首先要敞开思路，关注情景中各种各样的因素，给它们排出优先级，然后才能制定出简单的解决方案。
40. It's all about performance by Craig L Russell
【处处都要考虑性能】
如果有一种车宽敞、舒适、省钱又环保，就一定卖得好吗?非也。一辆牛车即使达到这样的标准也未必有几个人去买。原因就在于它速度太慢了。软件设计也是一样，功能重要，性能也一样重要。性能不单单指系统响应时间，还包括用户操作步数、用户思考时间、用户输入时间等。性能还包括那些自动执行而不与人互动的部分，比如每日夜间处理任务。试想一下，如果一个每天夜间执行的任务到了第二天的夜间还没执行完，将会带来难以预料的后果。
#p#
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
【多用原则、公理和民意，少用观点和偏好】
架构师个人的观点和偏好需要结合项目的实际情况进行仔细分析、充分论证，才能作为架构设计的依据。而原则、公理和民意，相对可以直接地作为架构设计的依据。所以，要提高架构水平和提高效率，可以多用原则、公理和民意，少用个人的观点和偏好。
#p#
60. Start with a Walking Skeletonby Clint Shank
【从可行走的骨架开始】
软件开发中，越早发现问题，修改的代价越小。因此，要及早将各个部分联接起来，形成一套可行走的骨架，按照用户需求的优先级，先验证重要的需求。验证一轮后，进行下一轮开发，调整骨架、补充肌体，实现生长，等待后续的验证。通过这种迭代、演化的方式，保证项目向正确的方向前进。
61. Share your knowledge andexperiencesby Paul W. Homer
【分享你的知识和经验】
软件业是一个年轻的行业，每个人都需要学习和进步。和他人分享你的知识、经验，让我们大家都发挥出全部的潜力，让这个行业的明天更加灿烂。
62. Make sure the simple stuff issimple by Chad LaVigne
【简单事情简单办】
设计人员往往会炫耀自己的知识，对简单的问题设计复杂的解决方案。复杂的方案往往走向延期、成本超支甚至失败。把聪明才智留着对付真正复杂的问题吧，不要再把问题复杂化。今天的事情今天办，也不要把今天的问题拖到明天，以为和明天的问题一起解决是什么智慧。要知道，处理了今天的问题，才能通过反馈引出明天的需求。
63. If you design it, you should beable to code it. by Mike Brown
【只设计自己会编码的架构】
架构师总是想创造精巧而新潮的设计。可是这样的设计对项目其实是有影响的。如果使用了一些自己没有动手做过的框架或者模式，不仅不能准确地估计工作量，而且还带来开发人员学习周期不明、新元素隐藏的问题不明、削弱开发人员对架构师的信任、给项目带来不必要的风险等副作用。记住：架构师首先是开发人员。
64. The ROI variable by GeorgeMalamidis
【计算投资回报】
在软件项目中的每一项决策，都可以视为是投资。投资是讲求回报的，即便不是金钱上的回报，也要给项目干系人带来某种可见的好处，比如降低缺陷。把投入的成本和预期的回报相比较，计算出回报率，才能合理地确定是否要做某件事。
65. Your system is legacy, designfor it. by Dave Anderson
【系统即遗产，需要精心设计】
一个系统即便最业务前卫、技术先进，对于下一任负责人来说，也是一份遗产。当今软件的特点就是迅速淘汰。如果想自己的系统投入生产，存活哪怕只是几个月，也得接受一个现实，那就是维护人员需要修修补补。这意味着：
清楚——各个组件和类的执行条理清楚;
可测——系统各部分的特性容易验证;
正确——系统按设计或常规运行;
追溯——为不了解系统内部情况的人提供问题追溯信息，以便快速定位和修复缺陷。
要抱着为继任者留下遗产的态度来设计系统。
66. If there is only one solution,get a second opinion by Timothy High
【只有一个对策时，请教他人吧】
软件架构是在各种条件下对某个问题提出解决方案。如果只能想出一个对策，这个对策往往不是最佳的，因为很难用一个解决方案满足所有条件，通常有个按照需求的优先级进行取舍的过程。只能想出一个对策，也许是因为自己缺乏经验，或者自己的经验不适于新的问题领域。比如，一个长期设计三层结构的客户端-服务器应用的人，碰到的是浏览器-服务器领域的问题。去向其他处理过类似问题的人请教，才能获得更好的意见。
67. Understand the impact of changeby Doug Crawford
【理解变化的影响】
好的架构师能把复杂度降到最低，并能设计出通用程度足以经受变化考验的解决方案。所谓变化，表现为：功能需求变化、规模演变、系统接口修改、团队人员进出等等。软件项目中变化的广度和复杂度是无法预测的，不能避免前进道路上所有的波折。但架构师应该识别出那些事关项目成败的大波折。他不仅要管理变化，还要确保变化是可管理的。比如：一个高度分布的系统，对流程的变化是在所难免的，可是又要承载长期运行、有状态的事务，那么就必须要设计成能同时支持新老版本的过程。
68. You have to understand Hardwaretoo by Kamal Wickramanayake
【必须了解硬件】
架构师不仅要关注软件架构，也要关注硬件容量。硬件容量规划是系统设计中的一个重要部分。如何准确地预测用户数量及其变化趋势，如何评估硬件的发展，都是做容量规划的必备知识。
69. Shortcuts now are paid backwith interest later by Scot Mcphee
【现在节省的，将来加倍还】
在项目开发阶段，可能会省略哪些不产生直接价值的工作，比如单元测试，又比如设计优化。现在节省了一点工作，将来系统进入维护阶段以后，要改正隐藏的错误，要花几倍的代价。
70. "Perfect" is theEnemy of "Good Enough" by Greg Nyberg
【优秀是良好的敌人】
作为软件解决方案，做到良好就行了，不要为了追求优秀而过度设计。良好的东西，在功能性、可维护性、性能指标等方面都能满足一般要求。如果过度追求优秀，可能突出了某一方面，而损害了其它方面，为系统的长期运行维护带来不好的影响。
71. Avoid "Good Ideas"by Greg Nyberg
【别提“好点子”】
当项目在按部就班地前进的时候，大家都感觉良好。这时有人就会提出所谓的好点子。比如：
“如果在这里改动一下，就太酷了。”
“嗨，他们又发布那个框架的新版本了，我们得赶紧更新。”
“一边开发新模块，一边重构老模块。”
“这项技术太强大了，可以用在我们的项目上。”
“我帮你想了一下，发现一个好主意!”
这些好点子往往是项目杀手。一旦付诸实践，对项目造成的改动不是当初想象的那么简单。除了极个别之外，大部分会把项目慢慢地拖入深渊，有的甚至会让项目迅速失败。
72. Great content creates greatsystems by Zubin Wadia
【好内容成就好系统】
不管系统的需求分析、设计、开发、安全、维护做得多好，如果忽略了内容建设，则它都不会是一个好系统。对于那些以内容为基础的系统来说，内容就是成功和失败的分界线，FaceBook 对 Orkut， Google 对 Cuil，NetFlix 对 BlockbusterOnline，等等，都是以内容取胜的例子。评价内容时，考虑一下几个条件：数量是否足够?时间上是否及时?渠道上是否丰富(RSs、纸质表单、电子邮件等)?
73. The Business Vs. The AngryArchitect by Chad LaVigne
【业务人员与愤怒的架构师】
架构师是为业务人员服务的，要忍耐，不要和业务人员争吵。如果你和他们分歧实在太大，那就只有换个自己觉得轻松的地方了。
74. Stretch key dimensions to seewhat breaks by Stephen Jones
【撑大关键维度，发现破绽】
系统各方面的处理能力是有一定的前提条件的。这些前提条件在实际运行中有可能发生变化。对于系统的关键维度，要进行验证，看看如果运行负荷超出，哪些地方会被撑破。
75. Before anything, an architectis a developer by Mike Brown
【架构师首先是开发者】
架构设计要落实到开发工作。如果你设计它，你就要能够编码它。如果连你都不知道如何编码，别指望别人能编码。
76. A rose by any other name willend up as a cabbage by Sam Gardiner
【玫瑰不叫玫瑰，它就沦落到白菜的地位】
如果你不知道如何称呼一个系统，你就不可能编写它。如果你对一个系统三改其名，你最好先停下来想想到底要做什么，不要急于构建它。
77. Stable problems get highquality solutions by Sam Gardiner
【稳定的问题才有优质的解决方案】
现实世界的解决方案不是挑战有难度的学术研究。设计现实的方案时，要把问题划分为稳定、有限的小块，再针对明确的小块来进行解决。稳定的问题得到稳定的设计，稳定的设计得到优质的解决方案。
78. It Takes Diligence by BrianHart
【勤勉】
一招不慎，满盘皆输。架构师应当勤勉，认认真真做好每一项平凡的工作。
79. Take responsibility for yourdecisions by Yi Zhou
【对决策负责】
大约三分之二的项目是失败的，表现有工期延误、预算超支、用户不满等。失败的重要原因是架构不当。通过以下几条，可以做到对架构决策负责：
准备决策时，务必反复推敲;
进行决策时，务必决策有据(书面凭据);
做出决策后，做到定期自评;
有疑难问题，请教领域专家。
#p#
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
【伟大的软件不是建造出来的，它是生长出来的】
虽然软件要进行架构设计，也从建筑和工程中借鉴了很多比喻，可伟大的软件不是建造出来的，它是生长出来的。一开始就建造庞大的软件，很容易失败。我们要有宏大的远景，但是必须要在小处下手。先做一个小的系统，再慢慢演化升级，向心目中的远景靠近。
原文链接：http://article.yeeyan.org/view/194678/203297
译文链接：http://architect.97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-_The_Book
