几年前有人问我：“你是如何成为一名软件架构师的？”我们讨论了必要的技能、经验，以及储存相关知识所需的时间和精力。此外，我也会回顾自己走过的路，用过或尝试过的技术，以及从那些不同的工作中学到的东西。架构师技术路线图。什么是软件架构师？在深入探讨之前，让我们先看看两个定义：软件架构师是做出高级设计决策并制定技术标准的软件专家，包括软件编程标准、工具和平台。其中首席专家是首席架构师。（来源：维基百科：SoftwareArchitect）软件架构是一个系统的基本组织结构。这种组织主要体现在它的组成部分、组成部分之间的关??系、组成部分与环境的关系以及决定系统设计和演进的原则上。（来源：维基百科：SoftwareArchitecture）架构的“层次”架构可以抽象为以下“层级”。不同的级别需要不同的技能。虽然划分层次的标准有很多，但我最喜欢的是将架构分为3层：应用层：架构的最低层。只专注于单个应用程序。水平低，但非常详细。这方面的沟通一般在开发团队内部进行；解决方案层：架构的中间层。专注于满足业务需求的一个或多个应用程序（即业务解决方案）。其中一些设计是高层设计，但大多数是低层设计。这种分层架构的沟通开始涉及多个团队；企业级：最高级别的架构。专注于多种场景。这种架构的设计是高层和抽象的，因此还需要解决方案级和应用级架构师对其进行细化。这一级别的架构需要多个组织进行通信。如果你想了解更多，可以参考这个链接：https://github.com/justinamiller/EnterpriseArchitecture。有时，架构师也被视为不同工作组之间的粘合剂。以下是三个示例：横向：搭建业务部门与开发人员或不同开发团队之间的沟通桥梁；纵向：搭建管理者与开发者之间的桥梁；技术：将不同的技术或应用程序集成在一起。软件架构师的日常要了解架构师必备的技能，首先要知道架构师主要做什么。我认为架构师最重要的活动包括：定义和确定所需的开发技术和平台；定义开发标准，如编程标准、工具、审查流程、测试方法等；为确定和理解业务需求提供支持；根据需求做出决定；讨论并记录架构定义、设计和决策；检查和审计架构和代码，例如检查之前确定的模式和编程标准是否正确实现；与其他部门和建筑师合作；便利和协商；高级设计的细化和转换为低级设计。注：架构设计是一项持续性的工作，尤其是在敏捷软件开发过程中。所以我们一遍又一遍地重复这些任务。软件架构师所需的技能为了完成上述工作，架构师需要具备某些技能。根据我个人的经验、相关书籍和讨论，我们可以将其归纳为以下10种技能：设计、决策、简化、计划、文档、沟通、估算、平衡、咨询、市场。接下来，我将对这些技能一一进行介绍。设计中第一个也是最重要也是最难回答的问题是“什么是好的设计”。我将从理论和实践两个层面进行阐述。根据我的经验，最好两者兼有。那么我们先来谈谈理论层面：理解基本的设计模式：模式是架构师开发可维护系统所需要的最重要的工具之一。基于这些模式，您可以将一些对其他问题有效的解决方案转移到具有相同模式的一些新问题。《Design Patterns: Elements of Reusable Object-Oriented Software》由“四人帮”(GoF)撰写，是参与软件开发的任何人的必读书籍。尽管这些模式是在20多年前发布的，但它们仍然是现代软件架构的基础。比如书中的模型-视图-控制器（Model-View-Controller，MVC）模式在很多领域都有应用，也是一些新模式（如MVVM）的基础；模式（反模式）：如果你对GoF写的模式有全面的了解，那么你可以学习更多的软件设计模式，或者深入挖掘你感兴趣的领域。在应用程序集成领域，我最喜欢的一本书是GregorHohpe的《企业集成模式》。当两个应用程序需要交换数据时，无论是来自一些遗留系统的老式文件交换还是现代微服务架构，本书的内容都适用；定义、应用和控制这些指南和编程标准。这样做是因为需要控制质量并满足一些非功能性需求。我们想要的是一个可维护的、可靠的、适应性强的、安全的、可测试的、可扩展的、可用的系统。实现所有这些要求的方法是有一个好的架构设计方法。您可以在维基百科上阅读有关质量指标的更多信息。理论固然重要，但如果不想成为象牙塔里的建筑师，实践同样重要，甚至更重要；尝试并理解不同的技术栈：我认为这是你成为更好的架构师的重要一步。尝试一种新的技术栈并了解它是如何演变的。这些不同的技术具有不同的设计理念和模式。仅仅浏览PPT并不能学到很多东西，需要自己去尝试，感受这项技术的酸甜苦辣。架构师不仅要有广博的知识，还要在某些领域有深厚的积累。重点不是要掌握所有的技术栈，而是要对你所在领域最重要的技术有扎实的理解。你也可以尝试一些你领域之外的技术，例如，如果你对SAPR/3有扎实的了解，你应该尝试JavaScript，反之亦然。尽管如此，双方都会对SAPS/4Hana的最新发展感到惊讶。例如，您可以自己尝试并免费参加openSAP课程。保持好奇心，尝试新事物，也许尝试一些你几年前不喜欢的东西；分析和理解应用程序模式：查看任何当前的框架（例如Angular）。你可以在实践中学到很多模式（比如Observables），你也应该尝试理解它在框架中是如何应用的以及为什么。如果你是一个真正的专业人士，你还需要深入研究代码并了解它是如何实现的；保持好奇心并关注用户群。决策架构师做出的决策可以引导项目乃至整个公司朝着正确的方向发展。分清轻重缓急：不要把时间浪费在不重要的决定和工作上，而是要学会分清轻重缓急。我个人更倾向于通过以下两个特征来判断一件事情是否重要：概念完整性：如果您一开始就决定了一个概念，请坚持下去，即使有时以不同的方式来做会更好。这使得整体概念更加清晰，提高了可理解性并简化了维护。b.一致性：例如，如果您定义和应用一个命名约定，它不是关于大写或小写，而是以相同的方式在任何地方应用。优先级排序：有些决定非常关键，如果不及早采取适当的解决方案，以后很可能会出现无法解决的问题。这对维护人员来说是一场噩梦，或者更糟的是，在做出这个决定之前，开发人员无法继续工作。在这种情况下，先做出“坏”决定比根本不做决定还要好。但在此之前，您需要知道应该优先考虑哪些决策。有很多方法可以做到这一点。我建议首先查看加权最短作业优先(WSJF)模型，该模型广泛用于敏捷软件开发。尤其是时间紧迫性和风险降低，这两者的度量是评估架构决策优先级的关键；认清自己的能力：不做超出能力范围的事情的决定。这很重要，因为如果不考虑，它会严重损害您作为建筑师的地位。为避免这种情况，您应该与同事明确您的职责和角色。如果不止一个架构师，那么你应该只负责你当前负责的架构级别。作为较低级别的架构师，您应该为较高级别的架构提出建议，而不是做出决策。此外，我建议您经常与同事一起审查重要决策；评估多个选项：做决定时，总是列出多个选项。在我参与过的大多数情况下，有不止一种可能的（优秀的）选择。糟糕的选择有两个主要特征：（1）看起来你的工作做得不好；(2)它妨碍你做出正确的决定。定义指标后，您可以根据事实（例如许可成本或成熟度）而不是直觉来比较选项。这通常会导致更好、更可持续的决策。此外，将该决定推广到其他部门也会更容易。但如果你没有正确评估这些选项，你可能会在最后的讨论中失去一个重要的论点。简化并永远记住奥卡姆剃刀原则，即简单就是正义。我对这个原则的理解是这样的：如果你的解决方案是基于做出很多假设，那么你的解决方案很可能是错误的，而且很可能会变得异常复杂。此时你应该减少（简化）一些假设以获得更好的解决方案。从多个角度查看解决方案：为了简化解决方案，您经常需要调整解决方案的视角。例如，您可以尝试通过自上而下和自下而上的思考来找到解决方案。如果您有数据流或流程，请首先考虑从左到右，然后再从右到左。在简化过程中问问自己：“在一个完美的世界中，您的解决方案是否需要任何修复？”，或“公司/个人会做什么？”。这两个问题都可以帮助您按照奥卡姆剃刀原则简化假设；退后一步：经过激烈而冗长的讨论后，您通常会得出一些极其复杂的解决方案。永远不要将它们视为最终结果。“退一步”的意思是：再从宏观的角度来看这个问题，现在的方案还有意义吗？然后在抽象级别重构解决方案。有时暂停讨论并在第二天继续讨论是个好主意。至少对我来说，我的大脑需要一些时间来处理信息并想出更好、更优雅、更简单的解决方案；分而治之：把大问题分解成小问题，然后分别解决小问题，验证这些小方案是否匹配。最后，退一步看大局；重构并不是一件坏事：如果找不到更好的解决方案，那么修复一个复杂的解决方案是件好事。如果某个解决方案有问题，您可以稍后重新考虑该解决方案并应用新的想法。重构并不是一件坏事，但是在你开始重构之前，请记住：（1）准备足够的自动化测试以确保系统的正常功能；(2)获得利益相关者的支持。要了解有关重构的更多信息，我建议阅读MartinFowler的《Refactoring. Improving the Design of Existing Code》。编程即使作为企业架构师（最抽象的架构级别），您仍然应该了解开发人员的日常工作。如果您不了解开发是如何完成的，您可能会面临两个主要问题：开发人员不购买您的故事；您不了解开发人员的挑战和需求。开始一个副项目：做一个副项目的目的是尝试新技术和工具，以发现当前和未来的开发方法。经验是观察、情感和假设的结合（《Experience and Knowledge Management in Software Engineering》，作者：KurtSchneider）。阅读教程或优缺点介绍固然很好，但那只是“书本知识”。只有亲身尝试，才能体会到开发者的情绪，才能对事情的好坏做出假设。您使用一种技术的时间越长，您的假设就会越好。这将帮助您在日常工作中做出更好的决策。刚开始编程的时候，没有代码补全，只有一些实用库来加快开发速度。显然，将这??些背景知识应用到今天会让我做出错误的决定。现在我们有大量的编程语言、框架、工具、流程和实践。只有有了经验，对主要趋势有了大概的了解，才能参与讨论，引导发展朝着正确的方向发展；只尝试需要尝试的东西：你不能尝试一切，那根本不可能。您需要一种更加结构化的方法。我最近发现了一个资源：ThoughtWorks的技术雷达，他们将技术、工具、平台、语言和框架分为四类：Adoption、Experimentation、Evaluation和Hold。采纳是指“强烈建议行业采用这些技术”，测试是指“企业在风险可控的前提下，应尽量在项目中应用该技术”，评价是“其对企业的影响有待探索”，暂停是指“谨慎行事”。有了这个分类法，就可以更容易地了解新事物的概况，并更好地评估下一步要探索的趋势。记录您的架构有时很重要，有时则不那么重要。例如，架构决策或代码指南都是重要的文档。在开始编程之前，通常需要初始文档并随着时间的推移进行完善。因为代码也可以作为文档（例如UML类图），所以可以自动生成一些文档。干净的代码：好的代码本身就是最好的文档。一个好的架构师应该有能力区分好代码和坏代码。RobertC.Martin的《Clean Code》是一个很好的学习材料。尽可能生成文档：系统变化很快，因此文档很难保持最新。无论是API还是CMDB形式的系统环境：底层信息往往变化太快，无法手动更新相应的文档。例如：如果你的API是模型驱动的，你可以从定义文件自动生成文档，或者直接从源代码生成文档。有很多工具可以为您完成这项工作，我认为Swagger和RAML是不错的起点。尽可能多地记录，尽可能少地记录：无论您需要记录什么（例如决策文件），请尝试一次专注于一件事，并且只记录有关它的必要信息。丰富的文档难以阅读和理解，附加信息应保存在附录中。尤其是决策文件，讲一个有说服力的故事比抛出一大堆论据更重要。此外，当您必须阅读文档时，它可以为您和您的同事节省大量时间。查看您过去处理过的一些文档（源代码、模型、决策文件等）并问自己以下问题：“是否包含理解该文档所需的所有信息？”、“哪些信息真的需要，哪些可以省略？”，“文档里有红线吗？”了解有关架构框架的更多信息：这也适用于所有其他“技术”建议。我把它放在这里是因为像TOGAF或Zachmann这样的框架提供了在文档站点上很重要的“工具”，尽管它们的附加值不仅限于文档。对此类框架的深入理解将教会您更系统地处理架构。参考链接：https://github.com/justinamiller/SoftwareArchitect
