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

【处处都要考虑性能】

如果有一种车宽敞、舒适、省钱又环保，就一定卖得好吗?非也。一辆牛车即使达到这样的标准也未必有几个人去买。原因就在于它速度太慢了。软件设计也是一样，功能重要，性能也一样重要。性能不单单指系统响应时间，还包括用户操作步数、用户思考时间、用户输入时间等。性能还包括那些自动执行而不与人互动的部分，比如每日夜间处理任务。试想一下，如果一个每天夜间执行的任务到了第二天的夜间还没执行完，将会带来难以预料的后果。