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)工具可以自动构建、测试，在完成时还能向外发送电邮或即时信息。