软件架构或许注定是抽象的追求，但它并不是把抽象思维直接变成代码。良好运转的架构实践，会通过一组工具与流程把思维转化为代码，并在此过程中产出一系列中间制品（artifacts）。这些制品既帮助架构师开展工作，也帮助架构团队管理活动，还促进与其他职能、组织与管理者之间的协同与沟通。
本章将介绍这些关键的架构实践并探讨其运作方式。这些实践既支撑前几章讨论的变更、设计与决策活动，也引入它们所能启用的一些新方面与新行为。第 8 章将进一步给出如何创建、组织与使用这些制品的指导。
这里提到的工具只按功能引用，而不涉品牌或厂商。可用工具的版图持续演进，任何具体的推荐都可能很快过时。不同团队还需要结合所在行业、雇主、法域等因素考虑工具可得性。无论如何，你并不需要某个特定的工具才能取得成功。
充分利用团队已有的工具往往更明智，尤其当这些工具对你的团队与干系人都已熟悉时。如果架构团队执意使用一套与产品经理、工程师等合作伙伴不同的工具，就会把自己与一些最关键的同事隔离开来。这并不是说要剥夺团队使用高效工作工具的权利；然而，如果你确实要采用不同的工具，应把重点放在那些能带来有意义差异化的工具上。
Backlog（架构待办）
如第 4 章所述，架构团队应以“架构待办”（architecture backlog）的形式记录当前、过去与未来的工作。将待办按“一组变更提案（change proposals）”来组织，可以把流程与管理对齐，从而简化管理。决定接受或拒绝某个变更提案，就能直接体现在待办更新上。反过来，查看待办也能直观得知正在推进多少项变更、多少尚在等待，等等。
变更提案并无理想的固定体量或范围，因为变更本身大小不一。一个简单提案，可能只是给现有 API 调用增加一个新的可选参数（如果该 API 或参数受架构团队治理，这依然属于架构变更）。一个复杂提案，则可能要求重构某个现有服务或新增一个子系统。稍后我们会讨论能随变更规模伸缩的流程。就待办而言，关键是把每一项都记录下来。
相关提案应彼此建立关联。比如，你可能提出了三个各自给应用新增同一功能的不同方式；选择其一就意味着拒绝其余。通过在待办中维护这些关联，你可以清晰地看见并管理每个决策的影响。
如果把团队的所有工作都建模为变更提案，待办的效用会更大。打算更新架构愿景？记录一个变更提案。正在讨论是否采纳一条新的架构原则？记录一个变更提案。想要更换维护待办所用的工具？也记录一个变更提案。当你养成用这种方式组织全部工作的习惯后，不仅可以统一地应用工具（如待办），也能一致地运用你的流程与决策能力。
人的思维在处理某个变更时，总会不断冒出相关念头。有些是日常杂念；比如忽然想到很晚了、还没倒垃圾。有些是相关但会分心的想法；比如意识到刚识别的问题也会影响下一个要做的变更。还有时会产生出人意料的联想——这正是大脑内在创造力的体现。不论平常还是灵感，这些关联都可能让你偏离当前手头的任务。
待办当然是一个记录“要做什么”以及“下一步做什么”的机制。但待办最妙之处常在于：它形成了一个集体的外部记忆库。当新想法冒出来，就把它加进待办，然后把它忘掉。一旦把想法从大脑中提取并记录到待办，就可以把它放到一边，把注意力拉回到当前任务上。这就是“作为记忆的待办”的力量：它让团队得以“忘却”事情——至少暂时。而且它“记忆力完美”；人的记忆显然更易出错。
繁忙的架构团队在待办里拥有数百条项目也很常见——它们静静“待机”，不妨碍团队聚焦重要事项。合适的工具应支持至少这一规模，并为每条记录提供优先级、状态等独立字段，便于搜索或排序。问题跟踪类工具经常很适用。
关键在于：当条目被记录时，要写清楚。我们抱着“以后再看”的意图记录它，但不确定是几天、几周还是几个月后。只写一句无法提供上下文与细节的短语，作为记忆就太薄弱，日后可能帮不上忙。这并不意味着每条都要写成小论文，但一段完整的文字往往比一句残句有用得多。
同样重要的是：团队必须养成使用该工具的习惯。团队中的每个人都会不时想到应该加入列表的事项，这在日常工作中时时发生。人们往往会当场讨论——比如走到你桌边、或群发一封邮件。这些打断可以用一句“好主意——加到待办里吧”来引导。
把每一项都加到待办里，我们既把它留痕，也把评估的需求延后。不论你觉得它至关重要还是完全无关紧要，都先加入待办。等回头再评估——那时就能在不受当下干扰的情况下，冷静理性地判断。
当然，要让待办有用，就必须定期回访。第一次回访就发生在你添加新条目时。你正兴冲冲地想“我们应该做 X”，并开始创建新条目前，在点击添加之前，请先搜一下列表里是否已经有“做 X”。（此处任何工具的基础搜索能力都很有帮助。）如果已经存在，就打开看看；也许你能补充论据、修订描述或增加清晰度。无论如何，避免重复能让待办保持整洁。
此前考虑过并否决的事项也应留在待办里——不要删除！如果能用支持“已关闭/已解决”状态的工具，就能快速区分已处理与未处理。也许“做 X”去年提过被否了。这并不意味着它不能重提；但此时你可以借助团队外化的集体记忆来判断是否值得重启——若值得，为什么。
对正在进行的那部分待办项，应随着工作推进及时更新，并定期审阅。此时具备状态跟踪的工具最理想。有了准确的状态，管理者就能每周查看在制项的进展：某个提案快完成了吗？也许需要预留时间评审。某个提案久未推进？也许需要了解一下阻碍在哪里。对在制项，团队可以依赖这份外化记忆来保持对日常进度与变更的感知。
你还需要跟踪下一个要做的条目。从几百项的大待办里挑出来，这个清单通常不超过 5～10 个变更。如果你的项目按更大的规划节奏运转，或维护着路线图，那可能已经足够指明下一步该做什么。否则，你也许需要每月左右花点时间策划“下个一批”。不管采用什么方式，目标都是：当架构师准备好接手新任务时，团队提前准备就绪。
还需要定期“大扫除” 。我喜欢每年挑三四次，留出时间与团队一起回顾所有既不在进行、也不在“下一批”的条目。（其它条目我们平时已在看，就不必再过一遍。）逐条回顾时，问自己几件事：
- 它还 relevant 吗？ 也许系统演进了，或其他决策已让它过时，可以据此关闭。
- 要不要现在就做？ 当初记录它，是觉得“总有一天要做”；也许这一天已到，应该把它移入“下一批”。当然，同时激活的数量有现实上限。
- 它与哪些条目相关？ 尽管我们在添加时会尽量查重，但回顾中仍常能发现“簇状”的相关事项——有时甚至来源各异。此时可以合并成一个更大的条目，或把它们相互链接，以便未来回到其中任何一个时能被提醒到其它相关项。
这些周期性回顾还能强化一个共识：把条目“归档”到列表里，不是把它打入冷宫。大家对“这些事项会被重新审视”的信心，是让待办机制生效的关键。
在规划活动之前查看这份清单也很有价值——无论是纯架构性的规划，还是更广义的产品/平台规划。规划周期给了架构团队一个识别并安排自己工作内容的机会。如果你把这些想法都认真沉淀进了外部记忆库，那么当你需要它们时，它们就会“整装待发”。
Catalogs（目录/资产目录）
待办本质上就是变更提案的目录。同理，为架构团队维护软件组件目录与数据模型目录同样有用。
软件目录记录系统的组件及其关系。具体到你构建的系统，这些组件可能是库、服务、应用、框架、数据库等。至少，每条目应包含该组件的元数据，如类型、技术依赖、与其他组件的关系；链接到文档、责任人、运行手册等也可能相关。
数据模型目录记录系统所涉及的数据类型、实体类型及其关系。视你的系统与所用技术而定，这些可用抽象的数据建模语言、模式（schema）或格式规范来描述。
软件与数据模型目录为系统当前状态提供了额外的文档化支撑。也就是说，它们补充了支撑变更流程的任何非结构化系统文档，对“现状”进行结构化记录。
由于这些目录既没有待办那样频繁变更，也不收集相同类型的元数据，你不必使用与待办相同的工具来创建与维护它们。不过，若能在目录条目与相关变更提案之间维护链接则更理想。在许多工具中，每个条目都有唯一 URL，只需在相关项里记录该 URL，就能轻松维系这些关系。
Templates（模板）
一个高效的架构团队，大部分时间都会花在变更上。反过来，团队能否高效完成变更，对生产力的影响最大。
包含相关图表在内的变更提案都应以书面文档记录。在大型项目中，团队在短短几年内可能就要撰写数百甚至上千份此类文档。任何能提升这类文档编写与审批效率的方法，都会对团队整体生产力产生倍增效应。
把这些文档按统一模板来结构化，可以加速流程的每个环节——不仅是撰写与评审文档，甚至连设计本身的创建与修改都会更高效。模板通过提供结构来加速写作，作者不必再为“如何组织文档”投入不必要的精力，从而把时间与注意力释放出来，专注于记录设计。
在评审阶段，模板同样带来优势。文档被阅读的次数远多于被撰写的次数，因此我们要为评审者的时间与精力做优化；更重要的是，要让这份精力聚焦在设计本身，而不是去辨认文档结构。当每份文档都遵循相同格式时，就能降低评审者的认知负担。
更为重要的是，一个好的模板会充当工作清单。作者按模板逐段推进时，相当于对设计的各个方面逐一“打勾”。因此，模板应当提示架构团队期望关注的每项属性。具体条目可以不同，但安全、隐私、可依赖性以及其他质量属性，往往都会出现在这些模板中，正是出于这个原因。
无论对作者还是评审者而言，模板带来的一致性都会让形式“退到后台”，把提案的核心细节“带到前台”。下列是此类文档应包含的基本部分——也就是清单项：
- Status（状态） ：凡是在文档库里翻找过、却分不清哪些文档是最新、过时、进行中或已废弃的人，都会体会到准确维护状态信息的重要性。该部分应置于文档最前，以便让不想追溯“五年前已放弃设计”的读者直接略过。
- Summary（摘要） ：每份文档都应以简要摘要开头，说明动机与概念性做法。换言之：我们要解决什么问题？准备怎么解决？ 摘要应简明而完整；余下内容只是“细节”。
以上两节足以覆盖动机/概念阶段的变更。进入详细阶段时，应考虑以下部分：
- Terminology（术语） ：无需重复记录项目既有术语（应记录在术语表，见第 8 章）。但若本次设计引入了新术语，应先在此定义，再在后文使用。
- Detailed Design（详细设计） ：本节用于展开细节，并应针对每个主要设计要素各写一节。简单文档一节即可；单份文档最多可达六节左右。若内容远超此范围，考虑把变更拆分为多个变更。
- Dependability（可依赖性） ：这是涵盖可靠性、韧性、性能、扩展性等目标的总称，即系统在多大程度上可被依赖去正确履行其职能。本节应说明可依赖性的目标水平以及实现方式。
- Security and Privacy（安全与隐私） ：架构师必须始终、且越来越多地考虑安全以及适用的数据保护与隐私问题。本节应描述相关关注点及其应对方式。
- Efficiency（效率/经济性） ：对云服务尤为相关，本节应审视系统在预期规模下的经济性。随着使用增长，单位成本会保持不变、上升还是下降？
- Compatibility（兼容性） ：多数文档描述的是对既有系统的变更，因此需要阐述这些变更与现有软件要素与数据的兼容性。这既包括系统内部（可通过相关变更与数据迁移来实现），也包括系统外部，比如依赖现有接口的客户端。
- Impacts（影响面） ：以清单或表格概述本次变更影响到的组件与其他制品。本节不应引入新内容，只是将其他部分的要点高亮汇总，便于一眼获取。
- Signatures（签名/批准） ：多数文档需要某种形式的批准。根据我的经验，让审批人在文档中留名，是促使其认真对待职责的最佳方式之一。也许没有“约翰·汉考克”的潇洒签名那么有范儿，但确实有效。
使用模板时，请记住它是清单。也许你的文档对“兼容性”无话可说——比如你描述的是一个全新组件，兼容性并不适用。清单不是表单，不要求你把每个空格都填满。清单的意义在于迫使你逐项思考；若某项确实不适用，那就说明不适用即可。
前文已提到，变更的规模差异巨大。模板不应给小变更施加不必要的负担。经验法则：模板应允许架构师在不到一小时内完成对一个小而明了的变更的记录；而在另一端，模板也应支持包含若干主要设计要素的复杂设计。
模板并不只适用于变更提案，尽管它们在这里最有用。你可能也会发现，在愿景文档、目录条目等场合使用模板也很便利。
把你的模板视为组织维护的标准。首先，它们的使用应是强制而不是可选。偶尔使用，清单/模板的价值就打折。如果发现“每次用都很费劲”，那就修正模板。
把模板设为标准还有一项好处：模板也会受与你做其他一切事务相同的变更流程约束。如果模板不好用，有人就应该提出变更提案来解决问题；把这个提案记入待办，并起草标准的修订版——当然要用模板来起草！
Reviews（评审）
你的变更评审流程会把变更推进到“已批准”状态；有时也会走向“被拒绝”——这同样是合理、尽管不那么令人愉快的结果。一个可预测且高效的评审流程，有助于提升团队的整体效率。
设计系统架构的能力，当然是架构师的核心技能。但我逐渐意识到，参与评审的能力同样重要。做变更时，架构师应渴望获取能改进与澄清变更的评审反馈，并保持足够的谦逊去征求并接纳反馈；作为评审者，架构师能以建设性的方式分享自己的技能、知识与经验，从而更广泛地产生影响。评审本身创造不了变更，但没有评审，变更很难达到最佳状态。
一个有效的评审流程，结合了四个关键要素：共同基线、思考时间、讨论时间与多元思维。
- 共同基线：参与评审的人都应对工作达成相同理解，包括变更的动机与概念性做法。最好的方式是基于书面说明来开展评审。其一，写下来（最好用模板）会促使作者全面而精准；其二，只有书面文档才能确保所有人依据相同信息开展评审。标准且定义清晰的术语也能进一步支撑高质量的写作。
- 思考时间：评审者拿到变更提案后，需要时间来思考。我建议评审流程的第一阶段采用异步方式（也就是不在会议中进行）。许多组织的团队分布在不同地点与时区；异步流程让每个人都能在方便的时间参与。对一些参与者而言，异步也更舒适，因为他们可以花更久来组织回应，而不是在会上被“临场点名”。
- 工具支持：应通过支持线程化评论与通知的系统（如 wiki）来分享变更提案。这些是异步评审的关键能力，在众多工具中都很常见；没必要缺少它们——坦率说，没有这些能力，评审难以做好。文字处理器、wiki、代码仓库里都能找到所需能力。并且，虽然没必要强迫所有人对每个变更都发表评论，但有理有据的评论是判断文档是否清晰、评审者是否投入理解的最佳信号。
- 评论管理：异步评审最大的挑战是捕获并解决每条评论。为尽量简化，每条评论应独立成帖，且只讨论一个点。即便反馈相关，也要克制住“往一个帖里不断追加”的冲动。这些行为对所有人来说都不一定是直觉，需要对作者与评审者明确引导如何有效地使用评论功能。
处理评论的建议：
- 若评论提出了修改且作者同意，作者应完成修改并简要回复；评审者确认修改后，若无异议，关闭评论。建议设定一个到期时间——比如5 个工作日——到期后作者可以关闭评论，流程不能被忙碌的评审者所拖累。
- 若建议是琐碎且明显的（比如错别字），可考虑赋予评审者自行修正的权限。我倾向于这条规则，因为就一个错字开线程成本太高，同时也能培育对提案的共同所有权。最终，提案既代表作者，也代表评审者；没人希望它留下拼写或语法错误。
- 有些评论较难解决，有时评论内容偏题或超范围。出现这种情况时，请把问题记录到架构待办里，并把评论标记为已解决。问题本身当然还没解决，但重点是避免让一个提案背上其它议题的包袱，而这些议题会在不同时间线被处理。
- 还会有代表重大分歧的评论。如果一个评论线程往返超过四五轮，就应把讨论移出评审流程。通常，需要召开一次评审会议。
召开评审会议是对异步评审的实时补充，主要有两个目的；根据进展，你可能需要各开一次：
- 如上所述，当异步评审难以在合理时间内解决一个或多个问题时，现场讨论能显著加速共识的形成。
- 提升参与度。会议在日程上的安排，本身就会鼓励大家参与——在明确“请带着准备来的”预期下，那些尚未阅读设计的评审者也会被促使去阅读。这也是你面向所有尚未评论或尚未贡献的人主动征求意见的机会。
会议还能用来鼓励多元思维，这非常可取，但需要谨慎引导。没有强有力的主持，会议很容易被那些更善于公众发言或反应更快的人主导。主持人可以逐一点名来主动征求每位与会者的反馈。注意，此前的书面设计文档与异步评审已经为每位参与者提供了充分准备所需的一切。
开展评审会议时，要关注会议氛围。评审会议不应过于剑拔弩张；争论应围绕设计，而不是围绕个人。同时，评审的目标也不是“增进感情”。事实上，若大家相处得过于融洽，反而可能降低提出不同观点的概率。良好的团队关系很重要，但它需要在评审会议之外单独投入来建设。
Status（状态）
由于一个团队可能同时推进许多变更提案，良好的记录与管理能让所有人受益。我建议把一个项目的所有变更提案集中放在同一处，并将进行中与已完成的提案分开。进行中的条目数量较少，应当易于访问，以便大家能迅速找到；已完成的提案则应保留作参考，但挪到一边——例如放进单独的文件夹。随着时间推移，你会积累大量已完成提案；按日期排序有助于保持整洁。
务必在文档本身中注明并维护其状态，并在提案模板中包含状态字段。至少需要追踪四种取值：进行中、评审中、已批准、已拒绝。你也可以根据需要增加更细的状态。例如，有的团队会使用“搁置（on hold）”来表示暂时放到一边、但预期将来会回来的提案。
上一节描述的评审流程适用于处于中间状态的提案：评审中。虽然我鼓励大家开放式工作，但“进行中”状态表明作者尚未准备开始评审流程。此时设计可能不完整，或仍在剧烈变动——无论哪种情况，都可能让评审者白白耗费时间。
同样重要的是，要让参与者知道：一旦文档被批准，它就不再接受评审。这条规则会让一些人不舒服——他们希望继续修改，无论是增加新功能，还是纠正他们眼中的错误（无论这些错误是否真实存在）。提醒他们：流程是迭代的；若要继续修改，应通过新的变更提案来进行。
你的评审流程还应在每次评审中明确参与者及其角色。显然，每次评审都有作者，对设计负责；同时至少需要指派评审者（reviewers）与批准人（approvers） 。
秉持开放协作的精神，我建议评审者角色对所有人开放，即任何人都可参与。偶尔会有人滥用这项权利，但严格遵守评审流程会限制其影响。尽管如此，你可能知道某个人必须评审某个设计——也许因为其经验或对主题的熟悉度——此时就需要明确指派。
不过，你的大部分精力应放在选择批准人上。批准人是在设计完成前必须签字放行的人。与评审者不同的是，当批准人的意见与作者不一致时，作者不能简单地“各执己见”——至少在批准人也对结果满意之前不行。
批准人名单应由对变更成败负有责任的人组成。举例来说，当我团队里的人撰写某个变更，尤其是那些对系统架构有重大调整的变更时，我常常会作为批准人。通过为变更承担责任并签字，我不仅是在批准变更，也是在承诺投入精力将其推动到成功落地。
关键在于让批准人意识到：批准即承诺结果。人们常误解这个角色，把批准当作对变更的纯评估（“够好了”），或当作走流程（“打勾勾”）。当后来出现问题，而批准人声称自己从不喜欢这个变更、从未同意过，或者——最糟糕——根本没读过，这就是对你、对他们、对项目都是糟糕的结局。
因此，一个良好的批准人组合通常由三到四位对落地有切身利益的人构成。具体人选取决于你的组织结构。至少应包括一位对实施负责的人；可以是工程师或架构师。而且，如前所述，架构领导者对这些变更也有利益相关。
基于同样的理由，我不建议超过四位批准人。超出这个数量，会稀释责任——也就是那种“把变更推进到底”的承诺。批准人会更倾向于只关注“自己的那一块”，而非整体变更，这对所有人都不利。即使实施牵涉到一个大团队，这里我们要的也是一两位负责人的承诺。
你可能会发现，这种模式会给工程与架构领导者带来压力，因为他们需要批准大量变更。领导者可以且应该把评审工作委派给团队成员。委派不仅有助于管理他们的工作量，也能让对结果有利害关系的团队参与进来。
Velocity（节奏 / 速度）
产品组织受到进度表与预算的约束。架构团队应通过可预测的工作方式来支撑这些目标。要抵制把进度、预算与人员视为“随意的限制”的冲动。
相反，这些因素应当纳入你的流程。在开发一个新服务时，团队的目标不应是找到“最佳”架构——在缺乏明确标准时，这个标签并无意义；而应是找到满足需求且在项目给定参数下可实现的架构。应在设计过程中同时考虑架构成本、实现成本与运维成本。
估算过程可能被过度使用，尤其是在追求不现实的精确度时。启动一个变更时，知道它需要几天还是几个月是有帮助的；知道实现需要一个月还是一年也很重要。但既然只是估算，那么30 天与31 天的差别就毫无意义。
粗略估算无需耗费太多时间；这里历史数据很有帮助。动机与概念阶段花费的时间波动很大，不太适合跟踪。相反，重点记录详细设计何时开始、评审何时启动、何时获得批准。如果观察到跨度很大，可以按变更的大致体量把它们分到三类左右。
当你启动一个新变更时，与其拍脑袋，不如参考这套数据：过去哪些变更与这次类似？它们在范围上算小/中/大？历史上它们完成所需的时间区间是多少？如果一路上你都有收集数据，完成这项对照用不了五分钟。
用区间思考是有益的；我建议把这作为估算的一般做法——无论估的是时间还是成本。比如，你的数据表明“中等”变更通常需要4–6 周。那么对一个类似规模的设计，估算为4–6 周比估成5 周更好。当人们只拿到一个数字时，会把预期锚定在那个点上；这对测量合适，但估算不是这样。给出区间（两个数）会迫使听众意识到不确定性，而区间的宽度也传达了不确定性的大小。
每个团队都有不同的节奏与组织方式，因此不可能给出普适的“典型时间”。我只能以我参与的项目为例。
以此为前提，在我负责一个项目的架构期间，我们详细记录了每个变更提案的详细设计阶段所耗时间。一个“典型”的设计可以在4–6 周内完成。基于这些数据，我既能为新设计设定预期，也能轻松计算团队吞吐量。（一般每位架构师同时在做两份设计。）
把进度与预算纳入流程真正迷人之处在于：它会形成反馈回路。例如，在我们测量了设计时间并把4–6 周确立为“典型”之后，详细设计阶段变得更可预测。我认为有两个因素促成了这种效果：
- 明确区间会设定预期。也就是说，当开始一份新的详细设计时，作者不会忽视预期时间，或以为自己有数月可用。任务不再是“完成这份详细设计”，而是“在大家公认的时间范围内完成这份详细设计”。确立区间能让人聚焦。
- 清晰的“典型值”让偏差更显眼。假设做了四周，显然近期仍完不成。与其稀里糊涂地继续，我们就有了明确的预警，提示某些地方出了问题。原因可能很多：更高优先级的打断、工作块过大、需求未定等。重点不在于我们马上知道哪里错了，而在于红旗已升起，促使我们去追查。
无论如何，都要避免把架构与合理的进度对立起来的陷阱。如果你的概念性方案需要三个月的详细设计，而手头只有一个月，就寻找另一种方案。这并非总是可行，但如果选择更昂贵的路线，必须有强有力的理由。一个动辄选择更慢、成本更高路径的架构实践，是没有效率的。
Thinking（思考）
产品开发是团队协作的成果，因此我们会花大量时间在协同（借助工具与流程）与沟通（书面与口头）上。然而，归根结底，真正的工作仍来自个人基于思考能力做出的贡献——而思考需要时间。
架构从本质上说，就是协调不同系统组件。因此，大多数架构师总有写不完的文档、评不完的文档、聊不完的讨论。这些时间消耗并非架构所独有；这里要指出的是系统中存在一种偏向：我们很容易意识到必须把时间花在这些活动上；但要识别并预留出专注思考的时间却似乎更难——尽管思考正是这一学科的核心活动。
当我们规划个人日程、管理日历时，往往把它们当作与他人协调的工具。谁没有经历过在四个时区之间为十几个人排一个会的“乐趣”呢？许多日历程序充斥着让此事更容易的功能——这会诱使我们以为时间管理=会议排程。
然而，要成为高效且有产出的架构师，必须留出思考时间。注意：尽管把内容写下来是必要的，但一上来就写反而可能妨碍思考。等思考凝结成型后再写会更容易；而边想边敲字会拖慢你的思考。如果写作不顺，最好的办法可能就是——先离开键盘。
你的团队也可以像为会议预留时间那样，在日历上为思考划块。鼓励——甚至要求——每个人都锁定一段“专注时间”（focus time） 。（团队可能需要约定一个共同时段以便执行。）我力求每天的工作日历上都有专注时间。要是整天都被会议塞满了，我还怎么完成工作？
如果你发现工作日渐渐被会议占满，就要做优先级取舍。使用时间管理矩阵等工具，判断每一项是重要/不重要、紧急/不紧急。
- 不重要，就别做！ 这听起来显而易见，但常常难以践行。毕竟，不重要的事有时也有趣、好玩或能分散注意力。判断某事是否不重要，我喜欢问自己：如果我忽略它，会发生什么？ 如果答案是“不会有坏事发生”，那忽略它就是最佳选择。
- 力求把重要且紧急的工作维持在最小。在这个象限里压力最大，也最容易出错。这类事项永远不可能降到零，因为它们常常是外生的、难以预见的。但出现得越少，你就越能从容应对。
- 能避免“重要且紧急”的方式，是为“重要但不紧急”的工作留出充足时间。在这个象限，你能在危机发生之前就超前布局。我把这类工作理解为：准备一套方案并归档备查。当紧急请求来临时，我只需在“虚拟文件柜”里取出现成方案。
我并不想淡化达成上述状态的难度；许多组织主要都在“重要/紧急”象限运转。与此同时，架构有一项特定职责：面向未来思考，预判那些尚未紧急但终将紧急的事项。这写在架构定义的最前面：支配系统设计与演进的原则。如果“演进原则”不是预先思考，又是什么呢？
Summary（小结）
软件设计工作无法像工厂装配线那样以恒定、可预测的速率产出成品。尽管如此，一个有效的软件架构团队会遵循一组实践，以支撑组织“在正确的时间交付正确的产品”这一更广泛目标。
这些实践始于架构待办（backlog） ：以变更提案目录的形式捕捉团队已考虑、已完成、已拒绝及未来可能要做的全部变更。待办跟踪当前工作，帮助设计与评审按轨道推进；它也是潜在后续工作的可靠记忆，帮助团队把这些事项暂时放到一边；同时它为团队节奏管理提供数据。
软件组件目录与数据模型目录帮助记录当前系统，从而加速设计。模板进一步加速：既让撰写新的、完整的设计更容易，也让评审更顺畅。
评审是设计流程的关键组成部分。评审流程应同时覆盖异步与同步两种模式，并由合适的工具与流程支撑。跟踪并可视化每份设计的状态，以及每位评审参与者的角色，让评审顺利运行。
通过管理好这些实践——并预留出用于设计与评审所需思考的时间——软件团队就能划定范围、做出估算；凭借这些能力，他们能与工程团队及其他伙伴形成强有力的协作关系。
