【译】软件架构师之路

今天给你们带来一篇本身翻译的干货《软件架构师之路》。本周Github上升很快的项目。其内容对致力于成为软件架构师（不论先后端）的同窗应该都会有极大的帮助。

项目地址:

中文地址 https://github.com/gamedilong...

原文地址 https://github.com/justinamil...

若是有看完英文原文，发现本文翻译内容中存在问题或者错误的欢迎到中文Git地址PR，如可以对你们起到必定的帮助也欢迎star

内容

• 什么是软件架构
• 软件架构的层次
• 软件架构师的典型工做内容
• 软件架构师的重要技能
• 架构师的技术路线图
• 相关书籍

什么是软件架构?

• 软件架构师是一名软件开发专家，他能够进行高层设计选择并决定技术标准，包括软件编码标准，工具和平台。

(出处: 维基百科:软件架构师)

• 软件架构（architecture）是一个系统的基本组织，由其组件、它们之间的相互关系和环境以及决定系统设计和演化的原则来表示。

(出处: 软件架构手册)

软件架构的层次

软件架构能够被抽象的分为几个层次，不一样的层次对技能的要求不一样。对层次有不少不一样的划分，我最喜欢以下这三种划分:

• 应用级: 最低层次的架构。聚焦单个具体的应用。 很是注重细节, 底层设计。 沟通仅限入单个开发团队。
• 解决方案级: 中级别的架构. 聚焦解决业务需求（业务解决方案）的一个或多个应用。进行一些高层次可是主要以低层次的设计为主，须要在多个开发团队之间的沟通。
• 企业层级: 最高级别的架构。专一于多种解决方案。高层次的抽象设计，须要将解决方案对应用架构师进行详细说明。 须要在整个组织沟通。查看 连接 得到更多相关信息。

有时架构师也被看做是不一样利益相关者之间的“粘合剂”。 三个例子:

• 水平方向: 架起业务与开发人员或不一样开发团队之间的沟通桥梁。
• 垂直方向: 架起开发人员和管理人员之间的沟通桥梁。
• 技术方向: 不一样的技术栈或应用程序的集成和融合。

软件架构师的典型工做内容

要了解架构师所需的必要技能，咱们首先须要了解架构师平时主要干什么。如下是我认为最重要的一些工做内容:

• 定义和肯定开发技术和平台。
• 定义开发标准，如编码标准、工具、评审过程、测试方法等。
• 支持认识和理解业务需求。
• 根据需求设计系统并作出决策。
• 记录并传达架构定义、设计和决策。
• 检查和评审架构与代码等，检查是否符合约定的设计模式和编码标准。
• 与其余架构师和相关方协做。
• 负责开发的指导和咨询。
• 细化、细化上级设计为下级设计。

  注意: 架构是一项持续的工做，尤为当项目采起敏捷开发的模式，上述工做应该也是反复迭代进行的。

软件架构师的重要技能

为了支撑上述工做须要不少重要的能力。就我我的的经验，每一个软件架构师应该具有以下十项技能:

• 设计能力
• 决策能力
• 化繁为简能力
• 编码能力
• 文档架构能力
• 沟通能力
• 评估能力
• 平衡能力
• 指导、答疑能力
• 营销能力

(1) 设计能力

什么是好的设计？这多是最重要和最具挑战性的问题。要把理论和实践区别开来。根据个人经验，二者兼而有之是最有价值的。让咱们从理论开始:

• 了解基本的设计模式: 设计模式是架构师设计开发可维护、可扩展系统的一项最重要工具。经过设计模式你能够设计解决通用问题的可重用方案。 由John Vlissides，Ralph Johnson，Richard Helm，Erich Gamma撰写的《设计模式：可重用面向对象软件的要素》一书每一个从事软件开发的人都有必要阅读一番。尽管上述模式发布于20多年前，其仍然是现代软件架构的重要基础。例如，本书描述了模型-视图-控制器（MVC）模式，该模式应用于许多领域，也是一些新模式（如MVVM）的基础。
• 深耕模式和反模式: 若是你已经知道了全部的基本GoF模式，那么能够用更多的软件设计模式扩展你的知识. 或者深刻你感兴趣的领域。我最喜欢的应用程序集成相关的内容之一是Gregor Hohpe编写的“企业集成模式”一书。本书适用于两个不一样环境的应用程序须要交换数据时，不管是一些传统系统的旧式文件交换仍是现代微服务体系结构。
• 了解质量测量: 定义架构远不是终点。指引手册和编码标准的定义、应用和管理是有缘由的，这么作是由于质量和非功能性需求。你想拥有一个可维护、可靠、可适应、安全、可测试、可扩展、可用等的系统，而实现全部这些质量属性的一个方法就是应用好的架构工做。你能够在维基百科上了解更多关于质量衡量的信息。理论很重要。若是你不想成为一名站在空中楼阁上的架构师，那么实践一样重要，甚至更重要。
• 尝试了解不一样的技术栈: 这是成为一个更好的架构师的一项重要工做。尝试新的技术栈并至上而下的学习他们。不一样的技术能够给你带来不一样的设计理念和模式。对新技术的学习最好不要浮于表面，应该去多实践深刻感觉解决的痛点和其存在的问题。架构师不只须要涉猎普遍，在某些领域也要有深厚的知识。 固然并不须要掌握全部的技术，你须要对你所在领域最核心的技术有扎实的了解。 你也能够尝试其余领域的技术,例如, 若是你深刻SAP R/3，你就应该也去尝试一下JavaScript，反正亦然。时刻保持好奇心并付诸实践。还能够去试一些你讨厌了不少年的技术。
• 分析和理解应用模式: 看一下当前的任一比较流行的框架，例如Angular。 能够在实践中研究不少模式，例如“观察者模式”。 尝试了解它如何在框架中应用，为何要这样作。 若是真的颇有时间且认真，能够更深刻地了解代码并了解其实现方式.
• 加入一些用户组. Meetup

(2) 决策能力

架构师须要可以作出决策并将项目或整个组织引导到正确的方向。

• 知道重点: 不要把时间浪费在不重要的决定或者行为上。学会抓住重点。据我所知，目前尚未一本书讲这方面的内容。我的评估某件事是否重要，一般考虑以下两点:

  1. 概念完整性：即便您决定以一种方式作到这一点，坚持下去，即便有时以其余方式更好地作到这一点也是如此。 一般，这会让概念总体上更简单，简化可理解性并简化维护性。
  2. 一致性：例如，若是您定义并应用命名约定，它就无关于大小写，而是以相同的方式在任何地方应用它。
• 优先级: 有些决定是很是关键的。若是不尽早决策，会产生不少冗余到后期不太能删除的方案，致使维护困难，甚至于致使开发人员没法继续开发，直到给出决策。这种时候，每每给出坏的决定好于没有决定。固然，遇到这种状况时优先选择当前方案中的最优解。这里我建议看看在敏捷软件开发中普遍使用的加权最短做业优先（WSJF）模型。尤为是时间关键性和风险下降是评估体系结构决策优先级的关键。
• 明确本身的职责: 不要决策在你能力或者职责范围以外的事情。这是相当重要的，若是不考虑的话，它可能会严重破坏你架构师的地位。为了不这种状况，必定要于你的伙伴们明确你承担的责任及角色。若是架构师不止一个，那么你应该尊重当前的组织架构。做为级别低的一方，最好是给出建议不是决策。此外，我建议始终和同伴一块儿评审关键决策。
• 评估多个选项: 在决策时，必定要有一个以上的选择。在我参与的大多数案例中，有不止一个（好的）选择。只有一个选择是很差的，两个方面:首先，彷佛你没有作好你的工做，其次，它阻碍了作出正确的决定。经过定义度量标准，能够基于事实而不是直觉（例如许可证成本或成熟度）比较选项。这一般会致使更好、更可持续的决策。此外，向不一样的利益相关者推销决策也更容易。此外，若是没有正确评估选项，则在讨论时可能会遗漏一些因素。

(3) 化繁为简能力

请记住Occam剃刀的解决问题的原则，它表示更喜欢简单。我把这个原则解释为：若是你对这个问题有太多的假设要解决，那么你的解决方案多是错误的，或者致使没必要要的复杂解决方案。为了获得一个好的解决方案，应该减小（简化）假设。

• 方案规整:

为了简化解决方案，从不一样的位置角度评估它们一般有助于清理、规整解决方案。尝试经过自上而下和自下而上的思考来造成解决方案。若是您有一个数据流或进程，那么首先考虑从左到右，再从右到左。能够提出一些问题，好比：“在一个完美的世界里，你的解决方案会怎么样？或者：“X公司/我的会怎么作？“（其中X可能不是你的竞争对手，而是BAT（百度、阿里、腾讯）之一。）这两个问题都迫使你减小Occam的Razor建议的假设。

• 退一步:

通过激烈和长时间的讨论，得出的结果每每是高度复杂的草案。你永远不该该把这些看做是最终的结果。退一步：再看一眼大局（抽象层面）。仍是有意义的吗？而后在抽象的层次上再进行一次重构。有时，中止讨论并在次日继续讨论会有帮助。至少个人大脑须要一些时间来处理和想出更好、更优雅和更简单的解决方案

• 分而治之: 把问题分红小块来简化。而后独立解决。而后验证这些小块是否匹配在一块儿。退一步看一下这个的总体状况。
• 重构不是坏事: 若是找不到更好的主意，从更复杂的解决方案开始彻底能够。若是解决方案遇到麻烦，您能够稍后从新考虑解决方案并应用您的学习。重构不是邪恶的。 可是在开始重构以前，请记住要进行如下工做：（1）进行足够的自动化测试，以确保系统的正确功能；以及（2）从利益相关者的支持。 要了解有关重构的更多信息，建议阅读<<重构。 改进现有代码的设计>>，做者是Martin Fowler。

(4) 编码能力

即便做为一个企业级架构师，最抽象的架构层次，你仍然应该知道开发人员天天都在作什么。若是你不明白这是怎么作到的，你可能会面临两大问题:

1. 开发者不会接受你的嘴炮。
2. 不了解开发人员的实践需求和面临的困难.

• 有一个辅助项目: 这样作的目的是尝试新技术和工具，以了解当今和将来的开发方式。经验是观察，情感和假设的结合（Kurt Schneider的“软件工程中的经验和知识管理”）。阅读教程或一些利弊是好的。但这仅仅是“书籍知识”。仅当你本身尝试事物时，才能体验到情绪并创建关于事物好坏的假设。并且，使用某项技术的时间越长，你的评估就会越准确。这将帮助您在平常工做中作出更好的决定。当我开始编程时，我没有代码完成，只有一些实用程序库能够加快开发速度。显然，在这种背景下，我今天会作出错误的决定。今天，咱们拥有大量的编程语言，框架，工具，过程和实践。只有您对主要趋势有必定的经验和粗略的了解，才能参与对话并引导开发朝正确的方向发展。

• 找到合适的东西去尝试: 您没法尝试全部内容。 这根本是不可能的。 您须要一种更有条理的方法。 我最近发现的一种来源是ThoughtWorks的Technology Radar。 他们将技术，工具，平台，语言和框架分为四类：采用，试用，评估和保留。 经过这种分类，更容易得到新事物的概述及其准备状况，以更好地评估下一步要探索的趋势。

  • 采用: “已经准备好提供企业级服务”
  • 试用: “可以在一个承担必定风险的项目中尝试”
  • 评估: “还需进一步评估其对业务的影响”
  • 保留: “谨慎处理“

(5) 文档架构能力

架构文档有时更重要，有时则不重要。重要的文档例如体系结构决策或代码指南。在开始编码以前一般须要初始文档，而且须要不断改进。其余文档能够自动生成，由于代码也能够是文档，例如UML类图。

• 代码整洁: 若是作对的话，代码是最好的文档。 一个好的架构师应该可以区分好的代码和坏的代码。 罗伯特·C·马丁（Robert C. Martin）所著的<<代码整洁之道>>一书是了解更多关于好坏代码的宝贵资源。.
• 尽量生成文档: 系统变化很快，很难更新文档。不管是关于api仍是以CMDBs（配置管理数据库）形式出现的系统环境：底层信息一般变化太快，没法手动更新相应的文档。例如：对于api，若是您是模型驱动的，则能够基于定义文件自动生成文档，或者直接从源代码生成文档。有不少工具存在，好比Swagger和RAML是一一些不错的初始选择。
• 必要而精简:不管您须要记录什么文件（例如决策文件），都应尝试一次只关注一件事，而且仅包含关于这件事的必要信息。 大量的文档很难阅读和理解。 附加信息应存储在附录中。 特别是对于决策文件，讲一个有说服力的故事而不是仅仅发表大量论据，更为重要。 此外，这为您和您的同事节省了不少时间，然后者须要阅读。 看看您过去作过的一些文档（源代码，模型，决策文件等），而后问本身如下问题：“是否包含全部必要的信息才能理解它？”，“确实须要哪些信息，而且 能够省略吗？”和“文档中是否有红线？”。
• 了解有关架构框架的更多信息: 该点也能够应用于全部其余“技术”点。 我把它放在这里，是由于TOGAF或Zachmann之类的框架正在提供“工具”，这些工具在文档站点上感受很沉重，尽管它们的附加值并不限于文档。 在这样的框架中得到认证能够教会您更系统地解决体系结构。

(6) 沟通能力

根据个人观察，这是最被低估的技能之一。若是你在设计上很聪明，但不能传达你的想法，你的想法可能会影响较小，甚至没法成功。

• 学习如何传达你的想法:

在会议上进行协做时，知道如何正确的沟通传达你的想法，将其同步到你的同行是相当重要的。 我发现《 UZMO-用笔思考》是提升我在这一领域技能的好资源。 做为架构师，你一般不只会参加会议，并且一般须要主持并主导会议。

• 大型的演讲: 将你的想法呈现给小型或大型团体应该对您来讲可行。 若是对此感到不舒服，请开始向你最好的朋友介绍。慢慢扩大小组。 这是你只能经过离开本身的温馨区来学习的东西。 请耐心等待，此过程可能须要一些时间。
• 找到合适的沟通方式: 不一样的利益相关者有不一样的利益和观点。它们须要在各自的层面上用不一样的方式单独解决。在你交流以前，退后一步，检查你想分享的信息是否有正确的层次，关于抽象性、内容、目标、动机等。例如：开发人员一般对解决方案的很是小的细节感兴趣，而经理则更喜欢知道哪一个选项能节省最多的钱。
• 常常沟通: 若是没有人知道，再香的架构也是毫无心义的。按期在每一个组织级别上分发目标体系结构及其背后的思想。安排与开发人员、架构师和管理人员的会议，向他们展现所需或定义的方式。
• 透明: 按期交流只能部分缓解缺乏的透明度。 您须要使决策背后的缘由透明化。 特别是，若是人们不参与决策过程，则很难理解和遵循其背后的决策和理由。
• 随时准备发表演讲: 总有人有疑问，你想立刻给出正确的答案。尽可能把最重要的幻灯片放在一个统一的集合里，你能够展现和解释。它为你节省了不少时间，也给你本身带来了安全感。

(7) 评估能力

• 了解基本项目管理原则:

做为架构师或首席开发人员，您常常被要求估算实现您的想法：多长时间、多少人、多少人、哪些技能等。？固然，若是你计划引入新的工具或框架，你须要对这些“管理”问题有一个答案。最初，你应该可以给出一个粗略的估计，如天，月或年。别忘了，它不只仅是关于实现，还有更多的因素要考虑，好比需求管理、测试和Bugfix。所以，您应该了解所使用的软件开发过程当中的工做。经过过去的使用数据，你能够获得更好的评估，并从中得出你的预测。若是你没有过去的数据，你也能够尝试一些方法，如巴里W鲍姆的COCOMO。若是你被分配在一个敏捷项目中，学习如何正确地进行评估和计划：Mike Cohn的《敏捷评估和计划》一书提供了这个领域的一个坚实的概述。

• 评估“未知”架构: 做为架构师，您还应该可以评估体系结构对于当前或将来上下文的适用性。这不是一项简单的任务，可是您能够经过手头的一组问题来准备，这些问题对于每一个架构都是常见的。它不只关乎体系结构，还关乎系统的管理方式，由于这也让您了解了系统的质量。我建议老是准备好一些问题并准备好使用。通常问题的一些想法:

  1. 设计实践: 架构遵循哪些模式？它们是否获得正确使用？设计是否遵循红线或是否存在不受控制的增加？是否有明确的结构和关注点的分离？
  2. 开发实践: 制定并遵照规范指南？代码的版本是怎样的？部署实践？
  3. 质量保证: 测试自动化覆盖范围？静态代码分析到位且效果良好？同行评议到位？
  4. 安全性: 有哪些安全概念？内置安全？渗透测试或自动安全分析工具到位并按期使用？

(8) 平衡能力

• 质量是有代价的: 早些时候我谈到了质量和非功能性需求。若是过分使用架构，将会增长成本，并可能下降开发速度。你须要平衡架构和功能需求。应避免过分设计。
• 解决矛盾目标:

矛盾目标的典型例子是短时间和长期目标。项目每每倾向于构建最简单的解决方案，而架构师考虑的是长期的远景。一般，简单的解决方案不适合长期的解决方案，而且有可能在之后被丢弃（沉没成本）。为了不实施方向错误，须要考虑两件事:

1. 开发人员和业务部门须要了解长期愿景及其好处，以便调整其解决方案。
2. 负责预算的经理须要参与进来，以了解财务影响。不必定要把100%的长远眼光直接放在适当的位置，但开发出来的成本大致在预算范围内。

• 冲突管理: 架构师每每是不一样背景的多个群体之间的粘合剂。这可能会致使不一样层次的沟通冲突。为了找到一个平衡的解决方案，同时也反映长期的战略目标，架构师的角色每每是帮助克服冲突。 关于传播理论的起点是舒尔茨·冯·图恩的“四耳模型”。 基于此模型，能够显示并推论不少。 可是，该理论须要一些实践，在交流研讨会上应该有经验。

(9) 指导、答疑能力

在咨询和辅导方面，积极主动多是最好的选择。若是有人问你，那就太晚了。架构重构是尽可能要避免的。你须要以某种方式预见将来几周、几个月甚至几年，并为下一步作好准备。

• 有远见: 若是你参与在一个项目中，不管是传统的瀑布式方法仍是敏捷方法，你始终须要对要实现的中长期目标有一个愿景。 这不是一个详细的概念，而是针对每一个人均可以落地的路线图。 因为没法一次完成全部工做（这是一段旅程），所以我更喜欢使用成熟度模型。 它们给出了易于使用的清晰结构，而且每次都给出了当前的进度状态。 对于不一样的方面，我使用不一样的模型，例如 开发实践或持续交付。 成熟度模型中的每一个级别都有明确的要求，这些要求遵循SMART准则，以便轻松衡量是否已达到要求。 我发现一个很好的例子是持续交付。
• 创建实践社区（CoP）: 在一个共同兴趣小组之间交流经验和知识有助于分发思想和标准化方法。 例如，你能够每三个月左右将全部JavaScript开发人员和架构师汇集在一个房间中，讨论过去和当前的挑战以及如何解决它们或采用新的方法论和方法。 架构师能够共享，讨论和调整其愿景，开发人员能够共享经验并向同行学习。 这样的交流不只能够为企业带来极大的好处，并且对我的自己也很是有利，由于它有助于创建更强大的网络并传播思想。 还能够查看SAFe框架中的文章实践社区，该文章在敏捷环境中解释了CoP概念。
• 进行公开会议: 误解或模棱两可的一个缘由是缺少沟通。在固定的时间段内，例如每周30分钟，与同事交流热门话题。此次会议没有议程，一切均可以讨论。尽可能当场解决小事。安排对更复杂主题的跟进。

(10) 营销推广

你的想法很好，你已经很好地沟通了，可是仍然没有人愿意追随？那么你可能缺少营销技巧。

• 激励和说服: 公司如何说服你购买产品？ 他们证实了它的价值和好处。 但不止如此。 他们包装得很好，并使其尽量容易消化。

  1. 原型: 展现你想法的原型。有不少建立原型的工具。在喜欢SAP的企业背景下，能够查看build.me，在其中您能够快速轻松地建立漂亮且可点击的UI5应用程序。
  2. 视频: 与“无聊的PPT”不一样的是，你还能够播放一段视频，展现你的想法或至少方向。

但请不要过分营销：从长远来看，内容是王道。若是你的话没有实现，从长远来看，这将损害你的声誉。

• 坚持本身的想法:

有些时候人们不喜欢你的想法，或者他们太懒了，不喜欢你的想法。若是你真的被本身的想法所说服，你就应该不断地去追求它们，并“战斗”。有时这是必要的。具备长期目标的架构决策一般不是最简单的：开发人员不喜欢它们，由于它们更复杂。经理们不喜欢他们，由于他们在短时间内更贵。这是你的工做，你要坚持和谈判。

• 寻找盟友: 创建或执行你本身的想法多是困难的，甚至是不可能的。努力寻找可以支持和帮助说服他人的盟友。使用你的网络。若是你尚未，如今就开始建造它。你能够先和你的（思想开放的）同龄人谈谈你的想法。若是他们喜欢，或者至少部分喜欢，若是别人问他们，他们极可能会支持你的想法（“X的想法颇有趣。”）。若是他们不喜欢，问为何：也许你错过了什么？或者你的故事不够有说服力？下一步是找到有决策权的盟友。要求开诚布公的讨论。若是你惧怕讨论，记住有时候你须要离开你的温馨区。
• 重复一遍，相信它: “[…] 研究代表，反复接触某个观点会令人们相信该观点更为广泛，即便该观点仅来自一我的也是如此。”（来源：《金融品牌》）若是您常常发布不多的信息，则能够帮助您 说服人们更容易。 但请注意：从个人角度来看，应该明智地使用这种策略，由于它可能拔苗助长，成为糟糕的营销技巧。

架构师的技术路线图

相关书籍

• Refactoring. Improving the Design of Existing Code by Martin Fowler
• Enterprise Integration Patterns written by Gregor Hohpe
• Design Patterns: Elements of Reusable Object-Oriented Software by John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma
• Experience and Knowledge Management in Software Engineering by Kurt Schneider
• Clean Code by Robert C. Martin
• UZMO — Thinking With Your Pen
• Agile Estimating and Planning by Mike Cohn