如何成为一名架构师（翻译）

如何成为一个架构师（翻译）

如何成为一个架构师（翻译）

原文：https://github.com/justinamiller/SoftwareArchitect

什么是软件架构师

软件架构师是软件专家，负责高层级的设计决策，指定技术标准，包括软件代码标准，工具和平台
软件架构是一个系统的基础构成，由多个组件组成，组件之间的关系，组件与环境之间的关系，并且决定了系统的设计和演进原则。

软件架构的层级

架构可以分为多个抽象的层级。层级会对必要的技能的重要性有影响。

三层架构：

应用层（Application Level）：最低层级的架构。集中于单一的应用。非常细化，低层级的设计。沟通往往发生在一个开发团队内部。
解决方案层级（Solution Level）：架构的中间层，集中于一个或多个应用，用于实现一个业务需求（或业务解决方案）。有一些高层级的设计，但是主要是低层级的设计。沟通会发生在多个开发团队
企业级（Enterprise Level）高层级架构。集中于多个解决方案。高层级，抽象设计，由应用架构师或解决方案架构做细化。沟通会跨组织。

有时，架构师像是不同群体（stakeholder）的“粘合剂（glue）”，例如：

横向（Horizontal）：在业务和开发人员，或不同开发团队之间作为沟通桥梁
垂直（Vertical）：开发人员和管理人员之间的沟通桥梁
技术：整合不同的技术或应用

典型的活动（Typical Activities）

为了理解架构师所必要的技能，我们首先需要理解他们典型的活动。

架构师典型的活动包括：

定义和决定开发技术和平台
定义开发标准，如：代码标准、工具、复查流程，测试过程等
支持识别和理解业务需求
根据需求，设计系统和做出决策
记录和交流架构定义，设计和决策
检查和复查架构和代码，如：检查是否正确实现了定义的模式和代码标准
与其他架构师和相关人员合作
指导和咨询其他开发人员
将高层级的设计细化到低层级设计

注意：架构是一段连续的活动，尤其当在敏捷软件开发（agile software development）下。因此，这些活动需要多次迭代，循序渐进。

重要的技能

为了支持以上列出的活动，需要掌握特定的技能。就我的经验而言，阅读书籍和参与讨论得出的结果，我们能总结出架构师所必备的十个技能：

设计（Design）
决策（Decide）
简化（Simplify）
编码（Code）
记录（Document）
沟通（Communicate）
评估（Estimate）
平衡（Balance）
查阅（Consult）：获取信息的能力
营销（Market）

1. 设计

如何实现好的设计？这个问题非常重要，且具有挑战。我会把理论和实践分开来。从我的经验来说，两者相结合是最有价值的。

从理论开始：

熟悉基础的设计模式：设计模型是开发可维护的系统的重要的工具。通过模式可以复用设计解决共同的问题。书籍《设计模式：可重用的面向对象元素》（“Design Patterns: Elements of Reusable Object-Oriented Software”）是每个软件开发者必读的。虽然一些模式发布已经超过20年，却仍然是现代软件架构的基础。如：本书中描述的Model-View-Controller（MVC）模式，被应用到多个领域且是更新的模式的基础，如：Model-View-ViewModel（MVVM）。
深挖（Dig deeper）模式和反模式（anti-patterns）：如果你已经知道四人帮（Gang-of-Four）提出的所有模式，然后扩展你的知识到更多的软件设计模式，或深挖你感兴趣的领域。我有一本很喜欢的关于应用整合的书籍是《企业整合模式》（"Enterprise Integration Patterns"）。这本书适用于在两个应用需要交换数据的任何场景，无论它是否是从遗留系统的旧文件或现代微服务架构。
熟悉质量指标（quality measures）：定义架构并不是结束。我们需要指南和代码标准为什么被定义、应用和控制的理由。你做这个因为质量和非功能性需求。你想要一个可维护，可靠的，适配的，安全的，可测试的，可扩展的，可用的系统等等。要实现所有的品质属性，就需要应用好的架构。你可以学习更多的质量指标在维基百科。

理论是重要的，但实践同等，甚至更加重要，如果你不想成为一个象牙塔（Ivory Tower）架构师。

尝试（Try out）和理解不同的技术栈：我认为这是成为一个更加优秀的架构师最重要的活动。尝试新的技术栈并且学习他们的优点和缺点（ups and downs）。不同的技术或新技术会有不同的设计方面和模式。你不能像快速浏览滑动的幻灯片一样学习知识，需要尝试它们，感受它们的痛点和解决方案（pain or the relief）。一个架构师不仅要见多识广，还需要在一些领域有深厚的知识。无需精通所有的技术栈，但是要在你最重要的领域有扎实的理解。同时，尝试你的领域以外的知识，如：你要深入学习SAP R/3，你应该尝试JavaScript，反之亦然。你可以自己动手尝试或者找课程学习。保持好奇心并尝试新事物。同时尝试你多年前可能不喜欢的事物。
分析和理解应用的模式：了解当前的框架，如：Angular。你可以一个实践中使用的模式，如：观察者（Observables）。尝试理解该模式是如何应用，为什么会被应用。需要深入的，对源码有深入理解的并且理解其如何实现。
保持好奇心并加入用户群体

2. 决策

一个架构师需要能够做出决策并指导工程或整个机构向正确的方向前进。

知道重点：不要浪费时间在非重要的决策或活动上。学习重要的东西。就我了解，没有一本书会有这些信息。我个人评估一件事情的重要性的两个特点：
1. 概念完整性（Conceptional Integrity）：如果你决定使用一种方式，就坚持这种方式，即使有时不同的方式更加好。通常，这导致更加直接的整体的概念，降低理解难度和维护。
2. 一致性（Uniformity）：如果你定义和应用了命名习惯（不是关于大写或小写），那就以相同的方式把它应用到每个地方
确定优先级（Priotize）：一些决策是高度重要的。如果他们没有被提前考虑，就搭建了工作空间，且不总是能在之后移除，就会成为维护的噩梦，或更糟，开发人员会停止工作直到做出决策。在这种情况下，一个“差”的决策也好过没有决策。但是，在这种情况来临之前，考虑优先安排即将到来的决策。存在多种可行方式。我建议参考在敏捷开发中广泛使用的权重最短任务优先（Weighted Shortest Job First,WSJF）模型。尤其是指标时间关键性（measures time cirticality）和风险降低（risk reduction）在评估架构决策优先级上是重要的。
确定职责（competence）：不要决策非职责范围的事情。如果不考虑你的职责，将毁灭架构师所处的位置。为了避免发生这样的情况，向你的同事阐明你的职责和角色。如果不止一个架构师，你应当尊重你当前所被安排的架构级别。作为一个低层级的架构师你更应该向高层级架构提出建议，而不是做出决策。进一步，我建议经常和同事确认关键的决策。
评估多个选项：当做决策时，总是列出多个选项。在多数情况下，总是会存在多个好的选项。仅提供一个是糟糕的，表现在两方面：
1. 看起来你没有做好你的工作。（PS：没有仔细调研各种技术方案）
2. 这会阻碍做出合适的决策
- 通过定义指标，选择可以基于现实做比较而不是直觉（gut feelings），如：许可证成本或成熟度。这总是导致更好并且更加可持续的决策。再者，这可以减少向不同的群体推销你的决策的难度。除此之外，如果你并没有正确的评估选项，你会在讨论中失去发言权。

3. 简化

记住解决问题的奥卡姆剃刀（ Occam’s Razor ）原则，即追求简单。我的解释如下：如果你对问题有太多的假设，你的解决方案很可能是错误的，或导致一个不必要的复杂的解决方案。假设应该减少（简化）以得到一个好的解决方案。

转动解决方案：为了简化解决方案，”转动“解决方案并从不同的位置观察它们通常是有帮助的。尝试通过自上而下和自下而上的思考来塑造解决方案。如果您有一个数据流或流程，那么首先从左到右，然后从右到左。问这样的问题：“在一个完美的世界里，你的解决方案会发生什么？”或者：“X公司/个人会怎么做？“其中X可能不是你的竞争对手，而是GAFA（谷歌，苹果，Facebook和亚马逊）公司之一。这两个问题都迫使你按照奥卡姆剃刀的建议减少假设。
退一步：在激烈而漫长的讨论之后，结果往往是非常复杂的涂鸦。你永远不要把这些看作是最终的结果。退一步：再看一看大局（抽象层面）。这还说得通吗？然后在抽象层面上再进行一次重构。有时，停止讨论并在第二天继续讨论是有帮助的。至少我的大脑需要一些时间来处理，并想出更好、更优雅和更简单的解决方案。
分而治之：通过将问题分成更小的部分来简化问题。然后独立解决。然后验证小片段是否匹配。让我们回过头来看看这方面的整体情况。
重构并不是邪恶的：如果找不到更好的想法，从更复杂的解决方案开始是完全可以的。如果解决方案带来了麻烦，你可以稍后重新考虑解决方案，并应用你学到的知识。重构并不是坏事。但是在您开始重构之前，请记住：(1)有足够的自动化测试，以确保系统的正确功能;(2)相关人员的接收你的做法。要了解更多关于重构的知识，我建议阅读《重构。改进现有代码的设计》（"Refactoring. Improving the Design of Existing Code"）。

4. 编码

即使作为企业架构师（最抽象的体系结构级别），您仍然应该了解开发人员每天在做什么。如果你不明白这是如何做到的，你可能会面临两个主要问题：

开发人员不接受你的安排
你不了解开发人员面临的挑战和需求

有一个副业项目：副业项目的目的是尝试新的技术和工具，以了解当前和未来的开发是如何完成的。经验是观察、情感和假设的结合（Kurt Schneider的《软件工程中的经验和知识管理》（"Experience and Knowledge Management in Software Engineering"）。阅读教程或一些利弊是很好的。但这只是“书本知识”。只有当你亲自尝试时，你才能体验到情绪，并建立起关于事物好坏的假设。你使用一项技术的时间越长，你的假设就会越好。这将帮助你在日常工作中做出更好的决定。当我开始编程时，我没有代码补全，只有一些实用程序库来加速开发。显然，有了这样的背景，我今天会做出错误的决定。今天，我们有大量的编程语言、框架、工具、过程和实践。只有当你有一些经验和对主要趋势的粗略概述时，你才能参与对话，并将发展引向正确的方向。
找到合适的事情去尝试：你不可能尝试所有的事情。这简直是不可能的。你需要一个更有条理的方法。我最近发现的一个来源是ThoughtWorks的技术雷达（Technology Radar）。他们将技术、工具、平台、语言和框架分为四类：
- 采用：“强烈的感觉企业会使用”。
- 尝试：“企业应该在一个能够承担风险的项目中进行尝试”。
- 评估：“探索它如何影响您的企业”
- 谨慎（Hold）：“小心处理”。

有了这种分类，就更容易对新事物有一个总体的了解，并能更好地评估下一步要探索的趋势。

5. 记录（Document）

体系结构文档有时更重要，有时不那么重要。例如，体系结构决策或代码指南是重要的文档。在编码开始之前，通常需要初始文档，并且需要不断地改进。其他文档可以自动生成，因为代码也可以是文档，例如UML类图。

整洁的代码：如果处理得当，代码是最好的文档。优秀的架构师应该能够区分好代码和坏代码。Robert C. Martin的《整洁的代码》（"Clean Code"）一书是了解更多关于好代码和坏代码的非常好的资源。
在可能的情况下生成文档：系统变化很快，很难更新文档。无论是关于API还是cmdb（配置管理数据库）形式的系统场景：底层信息经常变化的太快，无法手动保持相应文档的更新。示例：对于API，如果您是模型驱动的，您可以根据定义文件自动生成文档，或者直接从源代码生成文档。有很多工具可以做到这一点，我认为Swagger和RAML是学习更多的好起点。
尽可能多，尽可能少：无论你需要记录什么，例如，决策文件，试着一次只关注一件事，只包括这件事的必要信息。大量的文档很难阅读和理解。其他信息应存储在附录中。特别是对于决策文件来说，讲述一个令人信服的故事比抛出大量的论点更重要。此外，这为你和你的同事节省了大量的时间，因为他们必须阅读它。看看你过去做过的一些文档（源代码、模型、决策文件等），问自己以下问题：“是否包含了理解它所需的所有必要信息？”、“哪些信息是必需的，哪些可以省略？”和“文档有红线吗？”
了解更多关于体系结构框架的信息：这一点也可以应用于所有其他“技术”点。我把它放在这里，因为像TOGAF或Zachmann这样的框架提供的“工具”在文档方面感觉很重，尽管它们的附加价值不限于文档。在这样的框架中获得认证可以教会您更系统地处理体系结构。

6. 沟通（Communicate）

根据我的观察，这是最被低估的技能之一。如果你在设计方面很有才华，但不能表达你的想法，你的想法很可能影响较小，甚至无法成功。

学习如何交流你的想法：当你在白板或挂图上合作时，为了组织你和同事的想法，知道如何正确使用它是很重要的。我发现《UZMO -用你的笔思考》（"UZMO-Thinking With Your Pen"）这本书是一个很好的资源，可以提高我在这方面的技能。作为架构师，您通常不只是参与会议，通常还需要推动会议并主持会议。
向一大群人演讲：向一小群或大群人展示你的想法对你来说是可行的。如果你对此感到不舒服，开始向你最好的朋友展示。慢慢地扩大群体。这是你只能通过实践和离开你的个人舒适区来学习的东西。对自己要有耐心，这个过程可能需要一些时间。
找到正确的沟通水平：不同的群体有不同的利益和观点。这些问题需要在他们的层面上单独解决。在交流之前，退一步检查你想要分享的信息是否有正确的层次，比如抽象性、内容、目标、动机等。例子：开发人员通常对解决方案的微小细节感兴趣，而经理更喜欢知道哪个选项最省钱。
经常交流：如果没有人知道一个优秀的架构，那么它就毫无价值。定期地在每个组织级别上分发目标体系结构及其背后的思想。安排与开发人员、架构师和管理人员的会议，向他们展示所需的或定义的方法。
透明：定期沟通只能部分地缓解透明度缺失。你需要让决策背后的原因变得透明。特别是，如果人们不参与决策过程，就很难理解和遵循决策及其背后的理由。
随时准备好做报告：总会有人提出问题，而你想立即给出正确的答案。尽量把最重要的幻灯片放在一个统一的集合中，你可以展示和解释。这为你节省了很多时间，也给了你安全感。

7. 评估（Estimate and Evaluate）

了解基本的项目管理原则：作为架构师或首席开发人员，你经常被要求进行评估，以实现自己的想法：多长时间，多少钱，多少人，哪些技能，等等？当然，如果您计划引入新的工具或框架，您需要对这些“管理”问题有一个答案。最初，你应该能够给出一个粗略的估计，比如天、月或年。不要忘记，它不仅仅是关于实现的，还有更多的活动需要考虑，比如需求工程、测试和修复bug。因此，您应该了解所使用的软件开发过程中的活动。为了得到更好的估计，你可以使用过去的数据，并从中得出你的预测。如果没有过去的数据，也可以尝试Barry W. Boehm的COCOMO方法。如果你被部署在一个敏捷项目中，学习如何正确地评估和计划：Mike Cohn的《敏捷评估和计划》（"Agile Estimating and Planning"）一书在这方面提供了坚实的概述。
评估“未知的”体系结构：作为架构师，您还应该能够评估体系结构对当前或未来上下文的适用性。这不是一项容易的任务，但是您可以准备一组每个体系结构都常见的问题。这不仅是关于体系结构，也是关于如何管理系统，因为这也给了你关于质量的见解。我建议总是准备一些问题，随时可以使用。关于一般性问题的一些建议：
- 设计实践：体系结构遵循哪些模式？它们是否被正确使用？设计是否遵循红线，或者是否存在不受控制的增长？是否有清晰的结构和关注点分离？
- 开发实践：代码指导方针是否到位并得到遵循？代码是如何进行版本控制的？部署实践？
- 质量保证：测试自动化覆盖率？静态代码分析是否到位，结果是否良好？同行评审到位了吗？
- 安全性：有哪些安全性概念？内置的安全？渗透测试或自动安全分析工具是否到位并经常使用？

8. 平衡

质量是有代价的：前面我谈到了质量和非功能需求。如果架构做得太多，就会增加成本，可能还会降低开发速度。您需要平衡架构和功能需求。应避免过度工程。
解决相互矛盾的目标：相互矛盾的目标的一个经典例子是短期目标和长期目标。项目通常倾向于构建最简单的解决方案，而架构师有长期的想法。通常情况下，简单的解决方案并不适合长期的解决方案，并且有可能在以后被抛弃（沉没成本）。为了避免实现走向错误的方向，需要考虑两件事：
- 开发人员和业务人员需要了解长期愿景及其好处，以便适应他们的解决方案
- 负责预算的管理人员需要参与其中，以了解财务影响。没有必要将100%的长期愿景直接到位，但开发的部分应该与之相适应。
冲突管理：架构师通常是不同背景的多个团队之间的粘合剂。这可能会导致不同层次的沟通冲突。为了找到一个平衡的解决方案，同时也反映出长期的战略目标，架构师的角色通常是帮助克服冲突。我对传播理论的研究起点是舒尔茨·冯·图恩的“四耳模型”。在此模型的基础上，可以推导出很多东西。但这一理论需要一定的实践，需要在交流研讨会中进行实践。

9. 询问（Consult）和指导（Coach）

在咨询和指导方面，积极主动可能是你能做的最好的事情。如果有人问你，通常已经太晚了。在架构现场进行清理是你要避免的事情。你需要以某种方式预见未来几周、几个月甚至几年，为自己和公司的下一步做好准备。

有一个远景：如果你被部署在一个项目中，无论是传统的瀑布式方法还是敏捷方法，你总是需要对你想要实现的中期和长期目标有一个远景。这不是一个详细的概念，但更多的是一个路线图，让每个人都可以工作。因为你不能一次完成所有的事情（这是一个过程），我更喜欢使用成熟度模型。它们提供了一个清晰的结构，可以很容易地消耗，并提供了每次的当前进展状态。对于不同的方面，我使用不同的模型，例如开发实践或持续交付。成熟度模型中的每个级别都有明确的需求，这些需求遵循SMART标准，以便于您是否实现了它的度量。我发现的一个很好的例子是持续交付。
建立一个实践社区（community of practice, CoP）：在一个共同兴趣团体中交流经验和知识有助于传播思想和标准化方法。例如，你可以每三个月左右把所有JavaScript开发人员和架构师聚集在一个房间里，讨论过去和当前的挑战，以及如何解决它们或新的方法。架构师可以分享、讨论和协调他们的愿景，开发人员可以分享经验并向同行学习。这样的交流不仅对企业非常有利，对个人也非常有利，因为它有助于建立更强大的网络，传播思想。还可以查看来自SAFe框架的《实践社区》（"Communities of Practice"）文章，它解释了敏捷环境中的CoP概念。
进行开放式会议：误解或歧义的一个来源是缺乏沟通。用固定的时间（例如每周30分钟）与同事交流热门话题。这次会议没有议程，什么都可以讨论。试着当场解决一些小问题。对更复杂的话题安排后续跟进。

10. 营销（Market）

你的想法很好，你也很好地沟通了它们，但仍然没有人想要遵循？那么你可能缺乏营销技巧。

激励和说服：公司如何说服你购买产品？他们展示了它的价值和好处。但不仅仅是5个要点。他们把食物包装得很好，尽可能容易消化。
- 原型：展示你的想法的原型。有很多工具可以用来创建原型。热爱SAP的企业创建了build.me网站。你可以快速且容易的创建漂亮的外观和可点击的UI5应用程序。
- 展示一个视频：而不是“无聊的幻灯片”,你也可以展示一个展示你想法的视频,或者至少是方向。但请不要过度营销：从长远来看,内容是国王。如果你的话不能实现,这将会损害你长期的声誉。
为你的想法而奋斗,坚持不懈：人们有时不喜欢你的想法,或者他们太懒了,不愿意跟随他们。如果你真的相信你的想法,你应该不断地追求他们并且为之“战斗”。这有时是必要的。长期目标的架构决策通常不是最容易的，因为开发人员不喜欢它们，因为它们更复杂。经理们不喜欢他们,因为他们在短期内更贵。这是你的工作是坚持不懈的,是为了谈判。
寻找盟友：独自建立或执行你的想法可能很难，甚至是不可能的。试着找到那些可以支持和帮助说服别人的盟友。使用你的网络。如果您还没有，现在就开始构建它。你可以先和（思想开放的）同事谈谈你的想法。如果他们喜欢你的想法，或者至少是其中的一部分，那么当别人问起你的想法时，他们很可能会支持你的想法（“X的想法很有趣。”）。如果他们不喜欢，问原因：也许你错过了什么？还是你的故事不够有说服力？下一步是寻找有决策权的盟友。要求进行开放的讨论。如果你害怕讨论，记住有时候你需要离开你的舒适区。
重复做，相信它：“研究表明，反复接触一种观点会使人们相信这种观点更普遍，即使这种观点的来源只是一个人。如果你足够频繁地发布一些信息，就能更容易地说服人们。但请注意：从我的角度来看，这种策略应该明智地使用，因为它可能会适得其反，成为糟糕的营销伎俩。