你离成为优秀的架构师，就差这份超全路线图了
作者 | Justin Miller
译者 | 泓文
编辑 | 夕颜
出品 | CSDN（ID:CSDNnews）
几年前，有人问我：“你是如何成为一名软件架构师的？”我们讨论了必要的技能、经验以及积累知识所需的时间和投入。此外，我还详细介绍了我所采取的步骤，我积极使用或尝试过的技术，以及我在职业和非职业生涯中学到的知识。
什么是软件架构师？
在深入研究细节之前，我们先来看两个定义。
软件架构师是做出高级设计选择并指定技术标准(包括软件编码标准、工具和平台)的软件专家。
首席专家被称为首席架构师。(来源：Wikipedia：软件架构师)
软件体系结构是一个系统的基本组织，由它的组件、组件间关系和它与环境之间的关系以及决定系统设计和发展的原则来表示。(来源：软件架构手册)
架构层次
架构可以在几个抽象的“层次”上完成。这个水平会影响必要技能的重要性。存在很多可能的分类，我最喜欢的细分包括这三个层次：
应用程序层次：最低级的架构层次。专注于一个单体应用程序。非常详细的底层设计，通常在一个开发团队中进行沟通。解决方案层次：中级的架构层次。专注于一个或多个满足业务需求的应用程序(业务解决方案)。有些是高级的，但主要是低级的设计。多个开发团队之间的沟通。企业层次：最高级的架构层次。专注于多种解决方案。高层次的抽象设计，需要解决方案或应用程序架构师对其进行详细说明。整个组织的沟通。请参阅链接（https：//github.com/justinamiller/EnterpriseArchitecture）以了解更多信息。
有时，架构师也被视为不同利益相关者之间的“粘合剂”。三个例子：
横向：业务与开发人员或不同开发团队之间的沟通桥梁。
纵向：开发人员和管理人员之间的沟通桥梁。
技术：将不同的技术或应用程序相互集成。
软件架构师的典型活动
为了理解架构师所需的必备技能，我们首先需要了解其典型的活动。以下（非最终）是我认为最重要的活动：
定义和决定开发技术和平台
定义开发标准，例如编码标准，工具，评审过程，测试方法等
支持识别和理解业务需求
设计系统并根据需求做出决策
记录并传达架构定义，设计和决策
检查并核查体系结构和代码，例如，检查定义的模式和编码标准是否正确实施
与其他架构师和管理人员协作
指导和咨询开发人员
请注意： 架构是一个持续的活动，特别是当它被应用于敏捷软件开发时。因此，这些活动是反复进行的。
软件架构师的重要技能
为支持已安排的活动，需要特定技能。根据我的经验、阅读过的书籍和讨论，我们可以将其归结为每个软件架构师应具备的以下10种技能：设计、决策、简化、代码、文档、沟通、评估、平衡、咨询、市场。
让我们一一讲解。对于每项技能，我都提出了一些行动或见解，以进行后续改进。
（1）设计
什么是好的设计？这可能是最重要和最具挑战性的问题。我将区分理论和实践。以我的经验，两者兼备是最有价值的。让我们从理论开始：
了解基本的设计模式：模式是架构师开发可维护系统所需的最重要工具之一。使用模式，你可以重复使用设计，以通过可靠的解决方案解决常见问题。由“四人帮”（GoF）编写的《Design Patterns： Elements of Reusable Object-Oriented Software》一书是所有从事软件开发人士的必读书籍。尽管该模式已发布20多年，但它们仍然是现代软件体系结构的基础。例如，本书描述了模型-视图-控制器（MVC）模式，它已应用于许多领域，或者是较新的模式(如MVVM)的基础。深入研究模式和反模式：如果你已经了解所有基本的GoF模式，则可以使用更多的软件设计模式来扩展你的知识，或更深入地研究你感兴趣的领域。我最喜欢的应用程序集成书籍之一是Gregor Hohpe编写的《Enterprise Integration Patterns》。无论两个应用程序何时需要交换数据，无论是来自一些遗留系统的旧式文件交换还是现代微服务体系结构，本书都适用于各个领域。了解质量衡量标准：定义架构不是目的。它解释了为什么要定义、应用和控制指导准则及编码标准。这样做是因为质量和非功能需求。你想要一个可维护的、可靠的、可适应的、安全的、可测试的、可扩展的、可用的系统。实现所有这些质量属性的一个方法是应用好的架构工作。你可以在维基百科上了解更多关于质量衡量的信息。理论很重要。如果你不想成为象牙塔架构师，那么实践同样重要，甚至更为重要。
尝试并理解不同的技术堆栈：我认为如果你想成为更好的架构师，这是最重要的活动。尝试(新的)技术栈，并了解它们的兴衰。不同或新技术具有不同的设计领域和模式。你很可能不会从仅仅翻阅抽象幻灯片中学到任何东西，而是通过自己尝试来亲身感受。一个架构师不仅要有广博的知识，还要在某些领域有深厚的知识。掌握所有的技术并不重要，重要的是对你所在领域最重要的技术有一个坚实的理解。还可以尝试一些你不熟悉的技术，例如，如果你对SAP R/3有很深的了解，你应该尝试JavaScript，反之亦然。尽管如此，双方都会对SAP S/4 Hana的最新进展感到惊讶。例如，你可以自己尝试并免费参加openSAP的课程。保持好奇心，尝试新事物。还可以尝试一些几年前你不喜欢的东西。
分析和理解应用模式：查看当前的任意框架，例如Angular。你可以在实践中学习很多模式，例如，可观察的模式。尝试理解它是如何在框架中应用的，为什么要这样做。如果你是真正的专业人士，请更深入地研究代码并了解它是如何实现的。
保持好奇心，关注用户群。
（2）决策
架构师需要能够做出决策，并指导项目或整个组织朝正确的方向发展。
知道什么是重要的：不要把时间浪费在不重要的决定或活动上。了解重要的事情。据我所知，没有一本书包含这些信息（如果你知道的话，请告诉我）。我个人最喜欢的是这两个特征，我通常会在评估某些重要事项时考虑这些特征：1）概念完整性：如果你决定用一种方式去做，那就坚持下去，即使有时候用不同的方式去做会更好。通常，这会导致一个更直接的整体概念，易于理解和维护。2）一致性：例如，如果你定义并应用命名约定，它就不是关于大小写，而是以相同的方式将其应用于所有地方。优先级：有些决定非常关键。如果没有及早采取足够的解决方案，就会造成日后不太可能消除的问题，对维护来说是一场噩梦，或者更糟的是，开发人员只是在做出决定之前停止工作。在这种情况下，做一个“糟糕的”决定甚至比没有决定更好。但是在这种情况发生之前，考虑一下优先处理即将做出的决定。有不同的方法可以做到这一点。我建议先看看加权最短作业(WSJF)模型，它在敏捷软件开发中被广泛使用。特别是时间临界性和风险降低的度量是评估体系结构决策优先级的关键。了解你的能力：不要决定那些不在你能力范围内的事情。这是至关重要的，因为如果不加以考虑，它可能会严重破坏你作为架构师的地位。为了避免这种情况，你应该和你的同事明确你的职责和角色。如果有不止一个架构师，那么你应该尊重你当前部署的架构级别。作为一个较低层次的架构师，你最好为更高层次的架构提出建议，而不是做出决策。此外，我建议经常和同事一起检查关键决策。评估多个选项：如果涉及到决策，则始终要布置多个选项。在我参与的大多数案件中，都有不止一个（好的）选择。只有一个选择是不好的，在两个方面：1）似乎你没有做好你的工作；2）它妨碍作出正确的决定。通过定义度量标准，可以基于事实而不是直觉（例如许可证成本或成熟度）比较选项。这通常会导致更好和更可持续的决策。此外，可以轻松地将决策出售给不同的利益相关者。此外，如果没有正确评估选项，则在讨论中可能会遗漏参数。（3）简化
请记住解决问题的奥卡姆剃刀原则，即更喜欢简单。我把这个原则解释为：如果你对问题有太多的假设而无法解决，则可能会出错或导致一个不必要的复杂解决方案。为了得到一个好的解决方案，应该减少(简化)假设。
检验解决方案：为了简化解决方案，常常需要“shake”解决方案，从不同的位置观察它们。尝试通过自上向下和自下向上的思考来形成解决方案。如果你有一个数据流或流程，那么首先考虑从左到右，然后再从右到左。问这样的问题：“在理想环境中，你的解决方案会发生什么变化?”或者：“公司/个人X会怎么做?”(X可能不是你的竞争对手，而是GAFA公司之一。)这两个问题都迫使你按照奥卡姆剃刀的建议减少假设。后退一步：经过激烈而漫长的讨论，结果往往是高度复杂的涂鸦。你永远不应该把这些看作是最终的结果。后退一步：再次查看全局(抽象层次)。这还说得通吗?然后在抽象层次上再次进行重构。有时停止讨论并在第二天继续讨论是有帮助的。至少我的大脑需要一些时间来处理和想出更好、更优雅和更简单的解决方案。分而治之：通过将问题分成更小的部分来简化问题。然后独立解决。然后验证小块是否匹配。退一步以查看总体情况。重构并不是坏事：如果找不到更好的解决方案，那么从更复杂的解决方案开始重构是完全可以的。如果解决方法遇到麻烦，你可以稍后重新思考解决方法并应用你的学习。重构并不是坏事。但是在你开始重构之前，请记住(1)准备好足够的自动化测试，以确保系统的正常功能;要了解更多关于重构的知识，我建议阅读Martin Fowler的著作《Refactoring. Improving the Design of Existing Code》。（4）代码
即使作为企业架构师(最抽象的架构级别)，你仍然应该了解开发人员在日常工作中所做的事情。如果你不明白这是怎么做到的，你可能会面临两个主要问题：
1）开发人员不会接受你的说法。
2）你不了解开发人员的挑战和需求。
准备一个辅助项目：这个项目的目的是测试新技术和工具，以了解当今和未来的开发方式。经验是观察，情感和假设的结合（Kurt Schneider所著的“Experience and Knowledge Management in Software Engineering”）。阅读教程或一些利弊是好的。但这只是“书本知识”。只有当你自己尝试一些事情的时候，你才能体验到情绪，才能对事情的好坏做出假设。你使用一种技术的时间越长，你的假设就会越好。这将帮助你在日常工作中做出更好的决定。当我开始编程时，我没有代码完成，只有一些实用程序库来加速开发。显然，在这样的背景下，我今天会做出错误的决定。今天，我们有大量的编程语言、框架、工具、过程和实践。只有当你对主要趋势有一些经验和粗略的了解时，你才能参与到对话中来，并将开发引向正确的方向。
找到正确的事物进行尝试：你无法尝试所有事物。这根本是不可能的。你需要一种更有条理的方法。我最近发现的一种来源于ThoughtWorks的Technology Radar。他们将技术，工具，平台，语言和框架分为四类：采用，试用，评估和保留。“采用”表示“已完全为企业使用做好准备”，“试用”表示“企业应该在一个可以处理风险的项目中进行尝试”，“评估”表示“研究它如何影响你的企业”，“保留”表示“谨慎处理”。通过这种分类，更容易获得新事物的概述及其准备情况，以更好地评估下一步要探索的趋势。
（5）文档
架构文档有时更重要，有时不那么重要。例如，重要的文档是架构决策或代码指南。在开始编码之前，通常需要初始文档，并且需要不断地细化。其他文档可以自动生成为代码，也可以是文档，例如UML类图。
简洁的代码：如果处理得当，代码是最好的文档。一个好的架构师应该能够区分好的代码和坏的代码。Robert C. Martin所著的“Clean code”一书是了解更多关于好坏代码的宝贵资源。
在可能的情况下生成文档：系统日新月异，很难更新文档。无论是关于api还是以CMDBs形式出现的系统环境：底层信息的变化往往太快，以至于无法手动更新相应的文档。例如：对于api，如果你是模型驱动的，你可以根据定义文件自动生成文档，或者直接从源代码生成文档。有很多工具可以帮助你，我认为Swagger和RAML是一个很好的学习起点。
如无必须，尽可能少：无论你需要记录什么文档（例如决策文件），都应尝试一次只关注一件事，并且仅包含关于这件事的必要信息。大量的文档很难阅读和理解。附加信息应存储在附录中。特别是对于决策文件，更为重要的是讲一个有说服力的故事而不是仅仅发表大量论据。此外，这为你和你的同事节省了很多时间因为他们不得不阅读它。看看你过去做过的一些文档(源代码、模型、决策文件等)，然后问自己以下问题：“为了理解它，所有必要的信息都包括在内了吗?”、“哪些信息是真正需要的，哪些可以省略?”和“文档有红线吗?”。
了解关于架构框架的更多信息：这一点也适用于所有其他“技术”方面。我把它放在这里，因为像TOGAF或Zachmann这样的框架提供了“工具”，这些工具在文档站点上显得很重要，尽管它们的附加价值并不局限于文档。在这样的框架中获得认证将教会你更系统地处理体系结构。
（6）沟通
根据我的观察，这是最被低估的技能之一。如果你的设计精湛，却无法传达你的想法，那么你的想法可能会影响较小，甚至无法成功。
学习如何交流你的想法：当你在董事会或活动挂图上进行合作时，为了组织你和你的同事的想法，知道如何正确地使用它是很重要的。我发现“UZMO — Thinking With Your Pen”这本书是一个很好的资源来提高我在这方面的技能。作为一名架构师，你通常不仅要参与会议，还需要推动会议并对其进行协调。给大型团队做演讲：把你的想法展示给小型或大型团队应该是可执行的。如果你对此感到不舒服，开始向你最好的朋友展示。慢慢扩大小组。这是你只能通过做和离开你的个人舒适区才能学到的东西。对自己耐心点，这个过程可能需要一些时间。找到合适的沟通层次：不同的利益相关者有不同的兴趣和观点。他们需要在他们的层次上被单独处理。在你交流之前，后退一步，检查你想要分享的信息是否在抽象性、内容、目标、动机等方面都是正确的。例如：开发人员通常对解决方案中很少的细节感兴趣，而管理人员更希望知道哪种方案最省钱。经常交流：如果一个优秀的架构没有人知道，它将毫无价值。定期并在每个(组织)级别上发布目标体系结构及其背后的思想。安排与开发人员、架构师和经理的会议，向他们展示所需的或已定义的方法。保持透明：定期的交流只能部分地缓解缺乏透明度的问题。你需要让决策背后的理由变得透明。特别是，如果人们不参与决策过程，就很难理解和遵循决策及其背后的理由。准备好演讲：总会有人提出问题，而你想马上给出正确的答案。尽量把最重要的幻灯片放在一起，这样你就可以展示和解释了。它能帮你节省很多时间，给你安全感。（7）评估了解基本的项目管理原则：作为架构师或首席开发人员，你经常被要求评估以实现你的想法：多长时间，多少人，多少技能，等等?当然，如果你计划引入新的工具或框架，你需要对这些“管理”问题有一个答案。最初，你应该能够给出一个粗略的估计，比如多少天、多少月或多少年。不要忘记这不仅涉及实现，还有更多的活动需要考虑，比如需求工程、测试和修复bug。因此，你应该了解所使用的软件开发过程的活动。你可以运用一件事来得到更好的估计，那就是使用过去的数据并从中得出你的预测。如果你没有过去的数据，你也可以尝试Barry W. Boehm的COCOMO方法。如果你被部署在一个敏捷项目中，学习如何正确地进行评估和计划：Mike Cohn的《Agile Estimating and Planning》一书提供了这一领域的可靠概述。评估“未知的”架构：作为架构师，你还应该能够评估架构对当前或未来环境的适用性。这不是一项简单的任务，但是你可以通过手头的一组问题来准备，这些问题对于每个体系结构都是常见的。这不仅是关于架构，而且是关于如何管理系统，因为这也给了你关于质量的内部信息。我建议总是准备一些问题，以便随时使用。一般性问题的一些想法：
1）设计实践：体系结构遵循哪些模式?它们是否因此而被正确使用?设计是否遵循红线还是增长不受控制？是否有一个清晰的结构和关注点的分离?
2）开发实践：代码指导方针是否到位并得到遵循?如何对代码进行版本控制?部署实践?
3）质量保证：测试自动化覆盖率?静态代码分析是否到位并取得良好的结果?同行评审到位了吗?
4）安全性：哪些安全概念是适当的?内置的安全?渗透测试或自动安全分析工具是否到位并经常使用?
（8）平衡
质量是有代价的：前面我讨论了质量和非功能性需求。如果你过度使用架构，它将增加成本并可能降低开发速度。你需要平衡架构和功能需求。应该避免过度设计。
解决矛盾的目标：矛盾目标的典型示例是短期和长期目标。项目往往倾向于构建最简单的解决方案，而架构师考虑的是长期的远景。通常，简单的解决方案不适合长期的解决方案，并且有可能在以后被丢弃（沉没成本）。为了避免实施走向错误的方向，需要考虑两件事：
1）开发人员和企业需要了解长期愿景及其收益，以适应其解决方案
2）负责预算的经理需要参与以了解财务影响。不一定要有100%的长期愿景，但开发的部分应该适合它。
冲突管理：架构师通常是具有不同背景的多个团队之间的粘合剂。这可能会导致不同层次的沟通冲突。为了找到一个平衡的解决方案，同时反映长期的战略目标，架构师的角色通常是帮助克服冲突。关于传播理论，我的出发点是舒尔茨·冯·图恩的“Four-Ears Model”。基于这个模型可以显示和推导出很多东西。但这一理论需要一定的实践，在交流研讨中应有所体会。（9）咨询
在咨询和辅导方面，积极主动可能是你最好的选择。如果有人询问你，往往为时已晚。清理架构网站是你要避免的事情。你需要以某种方式预见未来的几周、几个月甚至几年，为自己和公司的下一步做准备。
有远见：如果你被部署在一个项目中，不管是传统的瀑布式方法还是敏捷方法，你总是需要有一个你想要实现的中长期目标的远见。这不是一个详细的概念，但更多的是一个路线图，每个人都可以工作。因为你不可能一次完成所有的事情(这是一个过程)，所以我更喜欢使用成熟度模型。它们提供了一个清晰的结构，很容易使用，并给出了当前的进展情况。对于不同的方面，我使用不同的模型，例如开发实践或持续交付。成熟度模型中的每个级别都有明确的需求，这些需求遵循SMART标准，以便于你是否已经实现了度量。我找到的一个很好的例子是关于持续交付的。建立实践社区(CoP)：在一个共同的兴趣组之间交换经验和知识有助于传播思想和规范方法。例如，你可以每三个月左右将所有JavaScript开发人员和架构师聚集在一个房间中，讨论过去和当前的挑战以及如何解决这些挑战或采用新的方法论和方法。架构师可以分享、讨论和调整他们的愿景，开发人员可以分享经验并向他们的同行学习。这样的一轮讨论对企业和个人都是非常有益的，因为它有助于建立一个更强大的网络和传播思想。还可以查看安全框架中的实践社区，该框架解释了敏捷环境中的CoP概念。进行公开讨论：误解或模棱两可的一个来源是缺乏沟通。设定一个固定的时间，比如每周30分钟，和你的同事交流热点话题。会议不设议程，一切都可以讨论。试着当场解决一些小事情。对更复杂的话题安排后续跟进。（10）市场
你的想法很好，你已经很好地传达了它们，但仍然没有人愿意遵循?那么你可能缺乏营销技巧。
激励和说服：公司如何说服你购买产品?他们展示了它的价值和好处。但不只是五个要点。他们包装得很好，使它尽可能容易消化。
1）原型：展示你想法的原型。有很多创建原型的工具。对于喜欢SAP的企业，请访问build.me，在其中你可以快速轻松地创建外观漂亮且可单击的UI5应用程序。
2）展示视频：你也可以展示一个视频来代替“无聊的幻灯片”来展示你的想法或者至少是方向。但请不要过度营销：从长远来看，内容才是王道。如果你说的话没有兑现，从长远来看，这会损害你的声誉。
为你的想法而奋斗并坚持不懈：人们有时不喜欢你的想法，或者他们懒得遵循。如果你真的对自己的想法深信不疑，则应不断追求并“奋斗”。有时这是必要的。具有长期目标的架构决策通常不是最容易的：开发人员不喜欢它们，因为它们的开发更加复杂。经理们不喜欢它们，因为它们在短期内更昂贵。这是你要坚持不懈并进行谈判的工作。寻找盟友：建立或实施你自己的想法可能很难，甚至不可能。试着寻找那些能够支持并帮助说服他人的盟友。使用你的网络。如果你还没有，现在就开始构建它。你可以从和你的同事(思想开放的)讨论你的想法开始。如果他们喜欢你的想法，或者至少部分喜欢，那么当别人问他们时，他们很可能会支持你的想法(“X的想法很有趣”)。如果他们不喜欢，问问原因：也许你错过了什么?还是你的故事不够有说服力?下一步是寻找有决定权的盟友。要求一个开放的讨论。如果你害怕讨论，记住有时候你需要离开你的舒适区。
重复一遍，相信它：“ […]研究表明，反复接触某个观点会使人们相信该观点更为普遍，即使该观点仅来自一个人。”（来源：《金融品牌》）经常重复发布一些消息，这可以帮助说服人们。但请注意：从我的角度来看，应该明智地使用这种策略，因为它可能适得其反，成为糟糕的营销技巧。
架构师技术路线图
原文链接：https：//github.com/justinamiller/SoftwareArchitect/blob/master/README.md?from=singlemessage&isappinstalled=0