架构思维是从架构师的角度看待事物——换句话说，从架构的角度来看待问题。理解某个特定变更可能如何影响整体可扩展性，关注系统中不同部分如何交互，知道在特定情况下哪些第三方库和框架最为合适，都是架构思维的体现。
能够像架构师一样思考，首先需要理解什么是软件架构，以及架构和设计之间的区别。接下来，还需要具备广泛的知识，以便看到其他人无法察觉的解决方案和可能性；理解业务驱动因素的重要性，并知道如何将其转化为架构方面的考虑；以及理解、分析并协调各种解决方案和技术之间的权衡。
在本章中，我们将探讨架构师思维的这些方面。
架构与设计
花一点时间在脑海中想象一下你理想中的房子。它有多少层楼？屋顶是平的还是尖的？它是一个大而广阔的单层牧场式房子，还是一个多层的现代化房子？它有多少间卧室？这些因素定义了房子的整体结构——换句话说，就是它的架构。现在花一点时间想象一下房子的内部。它是铺地毯还是木地板？墙壁是什么颜色？是地灯还是吊灯？这些因素与房子的设计相关。
类似地，软件架构更关注系统的结构，而不太关心系统的外观；而设计则更多关注系统的外观，较少涉及其结构。例如，选择使用微服务定义了系统的结构和形态（即架构），而用户界面（UI）屏幕的外观和感觉则定义了系统的设计。
但是，像是否将一个服务拆分成更小的部分，或者决定使用哪个UI框架这样的决策呢？不幸的是，这类决策大多处于架构与设计之间的某个光谱上，因此很难确定哪些应该视为架构的一部分。
以下标准可以帮助确定某个问题更多是与架构相关，还是与设计相关：
- 它是更具战略性质，还是更具战术性质？
- 需要多少努力来更改或构建它？
- 权衡的意义有多大？
这些因素如图2-1所示，展示了架构与设计之间的光谱，帮助确定决策所处的位置以及应该由谁负责。
战略性决策与战术性决策
决策越具有战略性，它就越与架构相关。相反，决策越具有战术性，它就越可能与设计相关。战略性决策通常是长期的，而战术性决策通常是短期的，并且通常与其他行动或决策无关。
一个判断决策是否更具战略性或战术性的方法是考虑以下问题：
这个决策涉及多少思考和规划？ 一个需要几分钟思考的决策更可能是战术性的，因此更多是关于设计的；而需要几周规划的决策则更可能是战略性的，因此更多是关于架构的。
有多少人参与了这个决策？ 一个由个人或与同事一起做出的决策更可能是战术性的，属于设计方面；而需要与多个不同利益相关者开会的决策更可能是战略性的，属于架构方面。
这个决策是长期愿景还是短期行动？ 一个很快会改变的决策通常是战术性的，更可能与设计相关；而一个会持续很长时间的决策通常是战略性的，更可能与架构相关。
尽管这些问题有些主观，但它们有助于判断某个决策是战略性的还是战术性的，从而决定它更多是关于架构还是设计。
努力程度
在他著名的论文《谁需要架构师？》中，软件架构师马丁·福勒写道，架构是“那些很难改变的东西”。一般来说，越难改变的东西，所需的努力越大，这使得该决策或活动更倾向于架构的范畴。相反，需要最小努力来实现或改变的东西，则更倾向于设计的范畴。
例如，从单体分层架构转向微服务架构需要大量努力，因此更多的是关于架构的决策。而在屏幕上重新排列字段所需的努力很小，因此更多是关于设计的决策。
权衡的意义
分析特定决策的权衡有助于判断它更多是关于架构还是设计。权衡越重要，决策越趋向于架构。例如，选择使用微服务架构风格能够提供更好的可扩展性、灵活性、弹性和容错能力。然而，这种架构非常复杂，成本高，数据一致性差，由于服务耦合，性能也较差。这些都是相当重大的权衡。我们可以得出结论，这个决策更偏向于架构方面，而不是设计方面。
即使是设计决策也有权衡。例如，将一个类文件拆分成多个部分可以提供更好的可维护性和可读性——但代价是需要管理更多的类。相比微服务的权衡，这些权衡并不特别重大，因此这个决策更多是偏向设计方面的。
技术广度
与开发人员不同，开发人员需要具备较深的技术深度来完成他们的工作，而软件架构师则需要具备较广的技术广度，以便从架构的角度看待问题。技术深度主要指对某个特定编程语言、平台、框架、产品等的深入了解，而技术广度则是指对很多不同领域的知识有所了解。
为了更好地理解这种区别，考虑图2-2所示的知识金字塔。它概括了世界上所有的技术知识，可以分为三个层次：你知道的东西、你知道自己不知道的东西，以及你不知道自己不知道的东西。
你知道的东西 包括技术人员日常工作中使用的技术、框架、语言和工具（例如，Java程序员知道Java）。他们在这些领域非常熟练，甚至是专家。请注意，这一层的知识（图金字塔的顶部部分）是最小的，包含的内容最少。这是因为大多数技术人员必须选择自己要深入发展的领域——没有人能在所有领域都成为专家。
你知道自己不知道的东西（金字塔的中间部分）包括技术人员略有了解或听说过的事物，但在这些领域缺乏经验或专业知识。例如，大多数技术人员听说过Clojure，并知道它是基于Lisp的编程语言，但无法用Clojure编写源代码。这个层次的知识比顶部的层次要大得多。这是因为人们可以对更多的事物有所了解，而不像在某个领域中发展专业技能那样有限。
你不知道自己不知道的东西 是知识金字塔中最大的部分。它包括所有可以完美解决问题的技术、工具、框架和语言，只不过尝试解决问题的技术人员并不知道这些解决方案的存在。在个人的职业生涯中，目标应该是将“你不知道自己不知道的东西”转移到金字塔的第二个区域——“你知道自己不知道的东西”——并且当需要专业知识时，将这些内容从金字塔的中间部分转移到顶部：你知道的东西。
在开发人员的职业生涯早期，扩展金字塔的顶部（图2-3）意味着获得宝贵的专业技能。然而，你知道的东西 也是你必须保持的东西——在软件领域，没有什么是静止不变的。如果开发人员成为了Ruby on Rails的专家，但几年不再关注Ruby on Rails，这种专业知识就会过时。保持金字塔顶部的知识需要投入时间去维持专业知识。这一部分代表了个人的技术深度：他们非常熟悉的内容。
然而，随着开发人员转型为架构师，知识的性质发生了变化。架构师的价值很大一部分来源于他们对技术的广泛理解，以及如何利用这些技术解决特定问题。例如，对于架构师来说，知道有五种解决方案可以解决某个问题，比仅仅在其中一种解决方案上拥有深厚的专业知识要好。对于架构师来说，金字塔的最重要部分是顶部和中间部分；中间部分深入底部部分的程度代表了架构师的技术广度，如图2-4所示。
对于架构师来说，广度比深度更为重要。因为架构师必须做出与技术约束相匹配的决策，广泛理解各种解决方案是非常有价值的。因此，对于架构师来说，明智的做法是放弃一些辛苦获得的专业知识，将时间用来扩展自己的知识面，如图2-5所示。一些专业领域可能会保留下来，特别是在自己喜欢的技术领域，而其他领域则可能会逐渐退化。
我们的知识金字塔展示了架构师和开发者角色之间的根本区别。开发者在整个职业生涯中专注于磨练专业知识。而转型为架构师意味着视角的转变，许多人会发现这种转变很难。这个转变通常会导致两种常见的功能障碍：首先，架构师尝试在多个领域保持专业知识，但没有在任何领域取得成功，反而把自己累得筋疲力尽。其次，这表现为过时的专业知识——错误地认为过时的信息仍然是前沿的。我们在大公司中经常看到这种现象，其中创办公司的开发者已进入领导岗位，但仍然使用陈旧的标准做技术决策（参见“冰冻穴居人反模式”）。
冰冻穴居人反模式
反模式是程序员Andrew Koenig定义的那种，在开始时看似是好主意，但最终会导致麻烦的做法。在实际工作中常见的一种行为反模式就是“冰冻穴居人反模式”，它描述了架构师对每种架构的执念，无法摆脱自己的一些不合理担忧。例如，Neal的一位同事曾参与一个中央化架构的系统设计。每次他们将设计交给客户的架构师时，都会被问到：“但如果我们失去意大利怎么办？”几年前，由于一次通讯问题，客户总部无法与其在意大利的门店进行沟通，造成了很大的不便。尽管这种情况再次发生的可能性极小，但架构师们已经对这一特定架构特性产生了执念。
通常，这种反模式表现为那些过去由于糟糕决策或意外事件而受过伤的架构师，他们对与此相关的任何事物变得特别谨慎。虽然风险评估很重要，但也应该是现实的。理解真正的技术风险和感知到的技术风险之间的差异是持续学习过程的一部分。要像架构师一样思考，就需要克服这些“冰冻穴居人”的想法和经历，看到其他解决方案，提出更相关的问题。
架构师应该专注于技术广度，以便拥有更多的工具可供选择。转型为架构师的开发者可能需要改变他们看待知识获取的方式。平衡自己知识深度和广度的组合是每个开发者在整个职业生涯中都应该考虑的问题。那么，架构师如何获得技术广度呢？接下来的章节提供了一些有助于发现“你不知道自己不知道的东西”的技巧。
20分钟规则
正如图2-5所示，技术广度对架构师来说比技术深度更为重要。那么，如何在全职工作、发展事业、与朋友相聚以及照顾家庭的同时，保持对最新趋势和流行词汇的了解呢？
我们使用的一种技巧是20分钟规则。这个方法的核心是每天至少花费20分钟学习新东西，或者深入研究一个特定的主题。图2-6展示了一些值得花20分钟的好地方，比如InfoQ、DZone Refcardz和Thoughtworks技术雷达。你可以通过查找不熟悉的流行词汇，将这些知识从“你不知道自己不知道的东西”提升到“你知道自己不知道的东西”。你甚至可以花时间阅读像本书这样的书籍。关键是要在忙碌的日常生活中挤出一些时间，专注于拓展你的技术广度，从而推动你的职业发展。
许多技术人员在首次接受这一概念时，通常会把20分钟安排在午餐时间或下班后；然而，根据我们的经验，这些时间段通常不太有效。午餐时间很容易被用来赶工作，而不是休息；而晚上则更糟，长时间工作后，社交计划、家庭时间等让你很难专心。相反，我们强烈建议你将20分钟安排在早晨的第一件事上——喝完一杯咖啡或茶后，重要的是，在查看电子邮件之前。检查电子邮件后，早晨就结束了，全天的工作也开始了。在大脑清醒、还没有受到干扰的时候，利用这段时间来进行20分钟的学习。
遵循20分钟规则将增加你的技术广度，并帮助你开发和保持成为一名有效软件架构师所需的知识。
发展个人雷达
在90年代和00年代初，作者之一曾是一个小型培训和咨询公司的首席技术官。刚开始时，公司的主要平台是Clipper，这是一种用于构建基于dBASE文件的DOS应用程序的快速应用程序开发工具。直到有一天它突然消失了。公司注意到Windows的崛起，但商业市场仍然是DOS系统……直到它突然不再是DOS系统。一位同事感叹，他们无法将自己大量现已无用的Clipper知识换成其他东西。这位同事不禁思考，历史上是否有哪个群体像软件开发者一样，在自己的一生中学习并丢弃如此多的详细知识？这段经历给我们留下了深刻的印象：忽视技术的进步，将会付出代价。
它还教给我们一个关于技术泡沫的重要教训。当开发人员、架构师和其他技术人员深度投资于某一特定技术，并将我们的工作和思考投入其中时，我们往往会生活在一个模因泡沫中。在这个泡沫中，所有人都像我们一样知道并关心这项技术。我们可能甚至看不到来自外部泡沫的真实评价，尤其是在泡沫最初是由技术供应商创造时。当泡沫开始崩溃时，直到为时已晚，才会意识到它已经开始破裂。
我们在泡沫中缺少的是技术雷达：一个活文档，帮助我们评估现有技术和新兴技术的风险与回报。雷达概念来自Thoughtworks，在那里，Neal担任导演和软件架构师。在本节中，我们将描述这一概念的形成过程，并展示如何创建个人雷达。
Thoughtworks技术雷达
技术顾问委员会（TAB）是Thoughtworks内部的一组高级技术领导者，协助首席技术官（CTO）就公司的技术方向和战略做出决策。为了保持前沿，这个小组开始发布现在已成为每年两次的《技术雷达》。
这带来了意想不到的副作用。当Neal在会议上发言时，听众们开始主动向他致谢，感谢他帮助制作了《技术雷达》，他们还常常补充说他们的公司也开始制作自己的版本。Neal还意识到，这回答了在会议发言人小组讨论中常常被问到的一个问题：“你们是如何跟上技术发展的？你们是如何决定接下来要追求什么的？”答案显然是，所有发言人都有某种形式的内部雷达。
部分内容
Thoughtworks雷达由四个象限组成，试图涵盖软件开发领域的大部分内容：
- 工具
从开发工具如IDE到企业级集成工具。 - 语言和框架
计算机语言、库和框架，通常是开源的。 - 技术
任何辅助软件开发的实践，包括流程、工程实践和建议。 - 平台
技术平台，包括数据库、云供应商和操作系统。
环圈
雷达有四个环圈，按从外到内的顺序列出：
- Hold（暂停）
最初，“暂停”环的含义是“暂时搁置”，代表那些技术还太新，无法合理评估——那些尽管引起了很多关注，但尚未被证明的技术。现在，“暂停”环已经演变为表示“不要再用这种技术进行新项目”。在现有项目中使用它没有害处，但对于新的开发项目，要三思而后行。 - Assess（评估）
“评估”环表示某项技术值得探索（例如通过开发实验、研究项目或会议讲座），以查看它如何影响组织。例如，当移动浏览器变得流行时，许多大公司在制定移动战略时，明显经历了这一阶段。 - Trial（试验）
“试验”环是指值得追求的技术。如果某项能力在这个环内，就意味着理解如何构建它很重要。现在是进行低风险项目试点的时机。 - Adopt（采用）
Thoughtworks坚信，行业应该采纳“采用”环中列出的项目。
在图2-7中展示的雷达视图示例中，每个“闪烁点”代表不同的技术或技术实践。虽然Thoughtworks使用雷达来广播其对软件世界的集体观点，但许多开发人员和架构师也将其作为结构化技术评估过程和组织思维的一种方式，帮助他们决定将时间投入到哪些领域。对于个人使用，我们建议将象限的含义改为以下：
- Hold（暂停）
这不仅可以包括要避免的技术和技术，也可以包括你想要摒弃的习惯。例如，如果你是来自.NET领域的架构师，可能习惯于阅读论坛上关于团队内部的最新新闻和八卦。虽然这些内容可能很有娱乐性，但它们可能是低价值的信息流。将其放入“暂停”环中，提醒自己要避免这些低价值的习惯。 - Assess（评估）
使用“评估”环来处理那些你听说过好评的，但还没有时间自己评估的有前景的技术。这个环是为未来更深入的研究提供一个过渡区。 - Trial（试验）
“试验”环表示活跃的研究和开发，例如在较大的代码库中进行实验性测试。这些是值得花时间去深入理解的技术，帮助你有效地进行权衡分析。 - Adopt（采用）
你个人的“采用”环代表那些你最感兴趣的、最能解决特定问题的最佳实践。
大多数技术人员在选择技术时，都是基于某些偶然的因素，比如某项技术是否很酷或他们的雇主正在使用什么技术——但对于你的职业生涯来说，采取“自由放任”的态度对待技术组合是危险的。创建技术雷达可以帮助你规范自己的技术思维，平衡相互对立的决策标准。（例如，专注于“更酷”技术的工作可能更难找，而更成熟的技术可能有一个庞大的就业市场，但所提供的工作可能不那么有趣。）
将你的技术组合视为金融投资组合：多样化！选择一些需求量大且普遍受欢迎的技术和/或技能，并跟踪这种需求。但你也可能想尝试一些技术冒险，比如生成式AI或嵌入式物联网设备。关于开发人员通过在深夜进行开源项目的工作，最终这些项目变得流行并最终被收购的轶事比比皆是。这也是为什么专注于广度而非深度的另一个原因。
构建个人雷达为扩展你的技术组合提供了一个良好的框架——但最终，这一过程比结果本身更为重要。创建雷达可视化为你提供了一个借口，让你从繁忙的日程中抽出时间思考这些问题，而这往往是完成这种思考的唯一途径。
虽然构建个人雷达最重要的部分是它所引发的对话，但它也能产生一些非常有用的可视化效果。在技术人员广泛要求自己构建雷达可视化后，Thoughtworks发布了一个名为“Build Your Own Radar”的工具。通过输入Google表格，它可以生成显示个人雷达的可视化图形。我们鼓励每个技术人员都利用这个工具。
分析权衡
像架构师一样思考，就是在每个解决方案中看到权衡，不论是技术性的还是其他方面的，并分析这些权衡，以确定最佳解决方案。之所以这成为架构师的关键活动之一（因此也是架构思维的一部分），正如Mark（其中一位作者）所说的这段话所体现：
架构是你无法通过Google搜索或问LLM得到的东西。
——Mark Richards
架构中的每一项都是一种权衡，这也是为什么对于宇宙中每个架构问题的经典回答是“取决于情况”。尽管这个答案可能令人恼火，但不幸的是，它是事实。你无法通过Google搜索答案，或者问一个AI引擎或大型语言模型（LLM），是否REST或者消息传递更适合你的系统，或者微服务是否是你新产品的正确架构风格，因为答案确实取决于多个因素。它依赖于部署环境、业务驱动因素、公司文化、预算、时间框架、开发者技能等几十个其他因素。每个人的环境、情况和问题都会有所不同。这就是为什么架构如此困难的原因。引用Neal，另一位作者的话：
架构中没有对错之分——只有权衡。
——Neal Ford
例如，考虑一个物品拍卖系统（如图2-8所示），在该系统中，在线竞标者对正在拍卖的物品进行竞标。竞标生产服务会生成一个竞标金额，并将该金额发送给竞标捕获、竞标跟踪和竞标分析服务。
对于这个系统中的异步行为，架构师可以选择以点对点消息传递方式使用队列，或者使用发布-订阅消息传递方式使用主题。他们应该选择哪一种？他们无法通过Google搜索答案。架构思维要求他们分析每个选项的权衡，并根据具体情况选择最佳（或最不坏的）选项。
物品拍卖系统的两种消息传递选项如图2-9所示，图中展示了使用发布-订阅消息模型中的主题，而图2-10则展示了使用点对点消息模型中的队列。
图2-9中显而易见的优势（以及看似显而易见的解决方案）是架构可扩展性。Bid Producer服务只需要与一个主题建立连接。而与之相比，图2-10中的队列解决方案，Bid Producer需要连接到三个不同的队列。如果要向系统中添加一个名为Bid History的新服务（用于提供每个竞标者所有竞标的历史记录），则不需要对现有的服务或基础设施进行任何更改。新的Bid History服务只需订阅已包含竞标信息的主题即可。
然而，对于图2-10所示的队列选项，Bid History服务将需要一个新的队列，并且Bid Producer需要修改以添加与新队列的额外连接。重点在于，使用队列意味着添加新的竞标功能需要对服务和基础设施进行重大更改，而使用主题的方法则不需要对现有基础设施进行任何更改。此外，Bid Producer在主题选项中与系统的耦合度较低，因为Bid Producer不知道竞标信息将如何被使用或由哪些服务使用。而在队列选项中，Bid Producer清楚地知道竞标信息将如何被使用（以及由谁使用），因此与系统的耦合度更高。
到目前为止，这种权衡分析似乎清楚地表明，使用发布-订阅消息模型的主题方法是显而易见且最佳的选择。然而，引用Clojure编程语言的创建者Rich Hickey的话：
程序员知道所有事物的好处，却对权衡一无所知。架构师需要理解两者。
Rich Hickey
架构思维不仅是看到给定解决方案的好处，还要分析相关的负面影响或权衡。继续以拍卖系统为例，软件架构师会分析主题解决方案的负面影响以及正面影响。在图2-9中，可以看到使用主题时，任何人都可以访问竞标数据，这引入了可能的数据访问和数据安全问题。然而，在图2-10所示的队列模型中，发送到队列的数据只能由接收该消息的特定消费者访问。如果有恶意服务监听一个队列，相应的服务将不会收到这些竞标，并且会立即发送关于数据丢失（以及可能的安全漏洞）的通知。换句话说，窃听一个主题非常容易，但窃听队列则不容易。
除了安全问题，图2-9中的主题解决方案仅支持同质化契约。接收竞标数据的所有服务必须接受相同的数据契约和竞标数据集合。在队列选项中，每个消费者可以有自己的契约，专门针对其需要的数据。例如，假设新的Bid History服务需要当前的要价和竞标，而其他任何服务都不需要这些信息。在这种情况下，契约需要被修改，这会影响所有其他使用该数据的服务。在队列模型中，这将是一个独立的通道，因此是一个独立的契约，不会影响任何其他服务。
主题模型的另一个缺点是它不支持监控主题中的消息数量，因此不能支持自动扩展能力。然而，使用队列选项时，每个队列可以单独监控，可以对每个竞标消费者应用程序化负载均衡，从而使其能够独立地进行自动扩展。请注意，这个权衡是技术特定的：高级消息队列协议（AMQP）能够支持程序化负载均衡和监控，因为交换机（生产者发送的对象）与队列（消费者监听的对象）之间是分离的。
基于这一更全面的权衡分析，哪个选项更好呢？
这取决于！表2-1总结了这些权衡。
表2-1. 主题的权衡
| 主题优势 | 主题劣势 |
|---|---|
| 架构可扩展性 | 数据访问和数据安全问题 |
| 服务解耦 | 无异构契约 |
| 监控和程序化可扩展性 |
同样，软件架构中的一切都有权衡：优点与缺点。像架构师一样思考意味着要分析这些权衡，然后提出像“哪个更重要：可扩展性还是安全性？”这样的问题。架构师的选择总是取决于业务驱动、环境和其他一系列因素。
理解业务驱动因素
像架构师一样思考还意味着要理解系统成功所需的业务驱动因素，并将这些需求转化为架构特性，如可扩展性、性能和可用性。这是一个具有挑战性的任务，要求架构师具备一定的业务领域知识，并与关键业务利益相关者保持良好的协作关系。我们在本书中专门用四章内容讨论这一话题：在第4章，我们定义了各种架构特性；在第5章，我们描述了识别和评估架构特性的方法；在第6章，我们描述了如何衡量每个特性，以确保系统的业务需求得到满足；最后，在第7章，我们讨论了架构特性的范围以及它们与耦合的关系。
平衡架构和动手编码
架构师面临的一个困难任务是如何平衡动手编码与软件架构的工作。我们坚信每个架构师都应该编码，并保持一定的技术深度（见“技术广度”）。虽然这看起来是一个容易完成的任务，但有时确实难以实现。
对于任何力求平衡动手编码与作为软件架构师角色的人，我们的第一个建议是避免“瓶颈陷阱”。瓶颈陷阱反模式发生在架构师负责系统的关键路径代码（通常是底层框架代码或一些更复杂的部分），并因此成为团队的瓶颈。这是因为架构师并非全职开发人员，因此必须在开发工作（如编写和测试源代码）与架构师角色（绘制图表、参加会议，以及，嗯，参加更多的会议）之间找到平衡。
避免瓶颈陷阱的一种方法是，架构师将系统的关键部分委派给开发团队中的其他成员，然后专注于在未来的一个到三个迭代周期内编写一个较小的业务功能（例如服务或UI界面）。这样有三个积极的效果。首先，架构师通过编写生产代码获得了实践经验，同时避免成为团队的瓶颈。第二，关键路径和框架代码被分配给开发团队（它们应该属于开发团队），赋予团队对系统难点的所有权，并帮助他们更好地理解系统的复杂部分。第三，也是最重要的，架构师编写与开发团队相同的业务源代码。这有助于他们更好地了解开发团队在流程、程序和开发环境中的痛点（并希望能够改进这些问题）。
然而，假设架构师无法与开发团队一起编写代码，他们如何保持动手能力并保持一定的技术深度呢？以下是一些希望继续提高技术能力的架构师的技巧和方法：
频繁的概念验证 进行频繁的概念验证（POC）要求架构师编写源代码；它还可以通过考虑实现细节来验证架构决策。例如，假设架构师在选择两种缓存解决方案之间遇到困难。一种有效的决策方法是，在每个缓存产品中开发一个工作示例并比较结果。这使架构师能够亲自查看实现细节以及开发完整解决方案所需的努力。它还允许架构师更好地比较不同缓存解决方案之间的架构特性，如可扩展性、性能和总体容错性。
架构师应尽可能编写最佳的生产质量代码。我们推荐这种做法有两个原因。首先，许多“试验性”的概念验证代码往往会进入源代码库，并成为他人遵循的参考架构或指导示例。任何架构师都不希望他们的粗糙的临时代码被当作代表其典型工作质量的代码。其次，编写生产质量的概念验证代码意味着能够练习编写质量好、结构清晰的代码，而不是通过编写快速、草率的POC来养成不好的编码习惯。
解决技术债务 架构师保持动手操作的另一种方式是解决一些技术债务，从而释放开发团队去处理关键的功能用户故事。技术债务通常优先级较低，因此如果架构师没有在某个迭代周期内完成技术债务任务，通常不会影响该迭代的成功。
修复bug 类似地，在迭代过程中修复bug是保持动手编码技能的另一种方式，同时帮助开发团队。虽然这不一定显得光鲜亮丽，但这种方法可以让架构师识别代码库中的问题和弱点，甚至可能揭示架构中的问题。
自动化 通过创建简单的命令行工具和分析器来帮助开发团队处理日常任务，利用自动化是保持动手编码技能的另一个好方法，同时还能提高开发团队的效率。架构师可以寻找开发团队执行的重复性任务并加以自动化。开发团队会感激自动化带来的便利。一些示例包括自动化源代码验证器，以帮助检查其他lint测试中找不到的特定编码标准，自动化检查清单和重复的手动代码重构任务。
自动化还可以以架构分析和适应性函数的形式来确保架构的活力和合规性，这是保持动手编码的另一种好方法。例如，架构师可以在Java平台上使用ArchUnit编写Java代码来自动化架构合规性，或者编写自定义的适应性函数以确保架构合规性，同时获得动手经验。我们将在第6章讨论这些技术。
做代码评审 作为架构师保持动手操作的最后一种方法是进行频繁的代码评审。虽然架构师没有实际编写代码，但至少可以保持参与源代码的工作。代码评审的进一步好处包括确保架构合规性并识别团队中的指导和辅导机会。
架构思维的更多内容
本章构成了开始像架构师思考的基础部分。然而，像架构师思考远不止本章所描述的内容。架构师的思维包括理解系统的整体结构（我们将在第3章讨论这个主题）、理解业务关切并将这些关切转化为架构特性（我们将用四章内容讨论这一主题），最后，通过系统的逻辑组件——系统的构建模块来审视一个系统（我们将在第8章讨论这个主题）。
