如何成为一名更好的软件架构师？

机器的

从GitHub

作者: 贾斯汀·米勒

机器的编译

参与: 王自佳，恶魔之王

几天前，高级架构师贾斯汀·米勒（Justin Miller）在GitHub上创建了一个项目，以介绍他关于“如何成为一名更好的软件架构师”的想法. 该项目发布后的一天，它赢得了1.4千颗星，现在已经达到3.8千颗星.

几年前，有人问我: “你是如何成为软件架构师的？”我们讨论了必要的技能，经验以及保留相关知识所需的时间和精力. 除此之外，我还回顾了自己走过的路，使用或尝试过的技术以及从这些不同的工作中学到的东西.

建筑师技术路线图.

什么是软件架构师？

在深入讨论之前，让我们看一下两个定义:

软件架构师是做出高级设计决策并确定技术标准（包括软件编程标准，工具和平台）的软件专家. 其中的首席专家是首席架构师. （来源: 维基百科: 软件架构师）

软件体系结构是系统的基本组织. 该组织主要体现在其组件，组件之间的关系，组件与环境之间的关系以及确定系统设计和演进的原理上. （来源: 维基百科: 软件架构）

架构的“层次”

可以将体系结构抽象为以下“级别”. 不同级别所需的技能也不同. 尽管有许多用于层次结构分类的标准，但我还是喜欢将体系结构分为3个层次结构:

应用程序级别: 最低的体系结构级别. 仅关注单个应用程序. 级别低，但是非常详细. 通常在开发团队内部进行这方面的沟通；

解决方案级别: 体系结构的中间层. 专注于满足业务需求的一个或多个应用程序（即业务解决方案）. 这些设计中的一些是高级设计，但大多数是低级设计. 这种分层的沟通开始涉及多个团队；

企业级别: 最高的体系结构级别. 专注于多种选择. 该体系结构的设计级别很高且很抽象，因此架构师还需要在程序级别和应用程序级别对其进行完善. 这种架构水平需要多个组织进行通信. 如果您想了解更多，可以参考此链接: .

有时，建筑师也被视为不同工作组之间的粘合剂. 这是三个示例:

水平的: 在业务部门与开发人员或不同的开发团队之间架起沟通的桥梁；

垂直: 在经理和开发人员之间架起一座桥梁；

技术: 集成不同的技术或应用程序.

软件设计师的日常

要了解架构师的基本技能，我们必须首先了解架构师的工作. 我认为建筑师最重要的活动包括:

定义并确定所需的开发技术和平台；

定义开发标准，例如编程标准软件架构师，工具，审查流程，测试方法等；

为识别和理解业务需求提供支持；

设计系统并根据需要做出决策；

有关体系结构定义，设计和决策的讨论记录；

检查并检查体系结构和代码，例如检查上一时期确定的模式和编程标准是否得到正确实施；

与其他部门和架构师合作；

对开发人员的指导和咨询；

详细的高级设计并转换为低级设计.

注意: 体系结构设计是一项连续的任务，尤其是在敏捷软件开发过程中. 因此，我们将一遍又一遍地重复这些任务.

软件架构师所需的技能

为了完成上述任务，架构师需要具备一些特定技能. 根据我的个人经验，相关书籍和讨论，我们可以将其总结为以下10种技能: 设计，决策，简化，编程，记录，沟通，估计，平衡，咨询，营销.

接下来，我将逐一介绍这些技能.

设计

首先，最重要和最难回答的问题是“什么是好的设计”. 我将在理论和实践层面上进行详细阐述. 以我的经验，最好同时拥有两者. 让我们先谈谈理论水平:

理解基本设计模式: 模式是架构师开发可维护系统所需的最重要工具之一. 基于这些模式，您可以将已经解决其他问题的某些解决方案迁移到具有相同模式的一些新问题. 对于所有从事软件开发的人员来说，“四人帮”（GoF）撰写的“设计模式: 可重用的面向对象软件的元素”是必读的. 尽管这些模式是20多年前发布的，但它们仍然是现代软件体系结构的基础. 例如，本书中的Model-View-Controller（MVC）模式在许多领域都得到了使用，它也是某些新模型（例如MVVM）的基础；

更深入地研究模式和反模式: 如果您对GoF编写的模式有全面的了解，那么您可以学习更多的软件设计模式，或者更深入地研究您感兴趣的领域. 在应用程序集成领域，我最喜欢的一本书是Gregor Hohpe撰写的“ Enterprise Integration Mode”. 当两个应用程序需要交换数据时，无论是来自某些旧系统的旧文件交换还是现代微服务体系结构，本书的内容均适用；

了解质量指标: 定义体系结构不完整，但也解释了为什么定义，应用和控制这些准则和编程标准. 这是因为需要控制质量以满足某些非功能性要求. 我们想要的是一种可维护，可靠，适应性强，安全，可测试，可扩展和可用的系统. 满足所有这些要求的方法是拥有一种好的建筑设计方法. 您可以在Wikipedia上了解有关质量指标的更多信息. 理论很重要，但是如果您不想成为象牙塔中的建筑师，那么实践同样重要，甚至更重要；

尝试并了解不同的技术栈: 我认为这是您成为一名更好的架构师的过程中最重要的一步. 尝试新技术堆栈并了解其开发过程. 这些不同的技术具有不同的设计概念和模型. 仅浏览PPT并不会学到很多东西. 您需要自己尝试体验这项技术的喜悦和悲伤. 建筑师不仅必须具有广泛的知识，而且必须在某些领域具有深刻的积累. 关键不是要掌握所有技术堆栈，而是要对您所在领域的最重要技术有扎实的了解. 您还可以尝试该领域以外的某些技术，例如软件架构师，如果您对SAP R / 3有深刻的了解，则应该尝试JavaScript，反之亦然. 但是，双方将对SAP S / 4 Hana的最新进展感到惊讶. 例如，您可以自己尝试并免费加入openSAP课程. 保持好奇心，尝试新事物，并尝试几年前不喜欢的事物；

分析并了解应用程序模式: 查看任何当前框架（例如Angular）. 您可以在实践中学习许多模式（例如Observables），并且还应该尝试了解它在框架中的应用方式以及为什么要这样做. 如果您是真正的人员，则还需要更深入地研究代码并了解其实现方式；

好奇并关注您的用户群.

决定

建筑师需要制定决策，以正确的方向指导项目甚至整个公司.

将主要和次要分开: 不要在不重要的决定和工作上浪费时间，要学会区分主要和次要. 就个人而言，我更喜欢使用以下两个特征来确定事件是否重要:

a. 概念完整性: 即使您一开始就决定一个概念，也要坚持下去，即使有时最好以其他方式来做. 这样，整个概念就越来越清晰，从而提高了可理解性并简化了维护过程.

b. 一致性: 例如，如果您定义并应用命名约定，则它与大写或小写无关，而是以相同的方式应用于所有位置.

优先级: 某些决定很关键. 如果您不及早采取适当的解决方案，将来可能会导致无法解决的问题. 对于维护者来说，这是一场噩梦，或者更糟的是，开发人员在做出此决定之前无法继续工作. 在这种情况下，首先做出“坏”决定甚至比没有决定要好. 但是在发生这种情况之前，您需要知道应该优先考虑哪些决策. 有很多方法可以做到这一点. 我建议看一下加权最短作业优先（WSJF）模型，该模型已广泛用于敏捷软件开发中. 特别是时间紧迫性和风险降低，这两个方面的度量是评估体系结构决策优先级的关键；

承认你的能力: 不要对超出你能力范围的事情做出决定. 这很重要，因为如果您不考虑它，可能会严重损害您作为建筑师的地位. 为避免这种情况，您应与同事明确职责和角色. 如果架构师不止一个，那么您应该只负责当前负责的架构级别. 作为低级架构师，您应该为高级别架构提出建议，而不是做出决策. 另外，我建议您经常与同事一起检查重要的决定；

评估多个选项: 做出决定时，请始终列出多个选项. 在我参与的大多数情况下，都有不止一种可能的（优秀）选择. 错误的选择主要有以下两个特征: （1）看来您做得不好. （2）它会阻止您做出正确的决定. 定义指标后，您可以基于事实（例如许可证成本或到期时间）而不是凭直觉来比较选项. 通常，这使您可以做出更好，更可持续的决策. 此外，将决策扩展到其他部门将更加容易. 但是，如果您没有正确评估选项，则可能在最终讨论中失去重要论据.

简化

始终记住奥卡姆（Occam）的剃刀原则，即简单就是正义. 我对这个原理的理解是: 如果您的解决方案是在做出许多假设的基础上提出的，那么您的解决方案可能是错误的，或者可能变得极其复杂. 此时，您应该减少（简化）一些假设以获得更好的解决方案.

多方向观察解决方案: 为了简化解决方案，您通常需要调整解决方案的视角. 例如，您可以尝试自上而下和自下而上的思考以获得解决方案. 如果您有数据流或流程，请首先考虑从左到右，然后再考虑从右到左. 在简化过程中问自己: “在理想环境中，您是否需要对解决方案进行任何更正？”或“公司/某人会做什么？”. 这两个问题都可以帮助您根据Occam的剃刀原理简化假设；

退后一步: 经过冗长而漫长的讨论，您通常会获得一些极为复杂的解决方案. 切勿将其视为最终结果. “退一步”的意思是: 再次从宏观角度看这个问题，当前的解决方案仍然有效吗？然后在抽象级别重构计划. 有时候，第二天暂停讨论并继续是一个不错的选择. 至少对我来说，我的大脑需要一些时间来处理信息并提出更好，更优雅，更简单的解决方案；

分而治之: 将大问题分解为小问题，然后分别解决小问题，并验证这些小解决方案是否匹配. 最后，退后一步查看整体情况；

重构不是一件坏事: 如果您找不到更好的解决方案，那么修复一个复杂的解决方案也是一个不错的选择. 如果解决方案有很多问题，您可以稍后重新考虑解决方案，然后将您认为的新事物应用于解决方案. 重构不是一件坏事，但是在开始重构之前，请记住: （1）准备足够的自动化测试以确保系统正常运行； （2）得到利益相关者的支持. 要了解有关重构的更多信息，我建议阅读Martin Fowler的“重构. 改进现有代码的设计”.

编程

即使作为企业架构师（最抽象的架构级别），您仍然应该了解开发人员的日常工作. 如果您不了解开发的完成方式，那么您可能会面临两个主要问题:

开发者不接受您的声明；

您不了解开发人员的挑战和需求.

开发子项目: 做子项目的目的是尝试新技术和工具以发现当前和将来的开发方法. 经验是观察，情感和假设的结合（Kurt Schneider撰写的“软件工程中的经验和知识管理”）. 阅读有关利弊的教程或简介当然不错，但这只是“书籍知识”. 只有当您自己尝试时，您才能体验开发人员的情绪，并做出好或坏背后的原因的假设. 您使用技术的时间越长，您所做的假设就越好. 这将帮助您在日常工作中做出更好的决策. 刚开始编程时，没有代码完成，只有一些实用程序库可以加快开发速度. 显然，利用今天那个时候的背景知识，我会做出错误的决定. 现在，我们拥有大量的编程语言，框架，工具，过程和实践. 只有在对主要趋势有经验并大致了解后，您才能参与讨论并朝着正确的方向引导发展；

仅尝试您需要尝试的事情: 您不会尝试所有事情，这是不可能的. 您需要一种更有条理的方法. 我最近发现了一种资源: ThoughtWorks的技术雷达，它将技术，工具，平台，语言和框架分为四类: 采用，试验，评估和延期. 通过表示“强烈建议业界采用这些技术”，通过测试表示“公司应在可控风险的前提下尝试在项目中应用该技术”，评估表示“仍需探讨其对公司的影响“行为”. 使用这种分类方法，我们可以更轻松地了解新事物并更好地评估接下来要探索的趋势.

记录

建筑文档有时很重要，但有时不那么重要. 例如，体系结构决策或代码准则是重要的文档. 在开始编程之前，通常需要初始文档，并且会不断对其进行完善. 因为该代码也可以用作文档（例如UML类图），所以可以自动生成某些文档.

简洁的代码: 好的代码本身就是最好的文档. 一个好的架构师应该有能力区分好的代码和坏的代码. 罗伯特·C·马丁（Robert C. Martin）撰写的“清洁代码”是这方面的很好的学习材料.

在可能的情况下生成文档: 系统会快速更改，因此很难及时更新文档. 无论是API还是CMDB形式的系统环境: 基础信息通常变化太快，因此无法手动更新相应的文档. 例如: 如果您的API是模型驱动的，则可以基于定义文件或直接从源代码自动生成文档. 有很多工具可以帮助您完成此任务，我认为Swagger和RAML是很好的起点.

记住尽可能多的内容和尽可能少的内容: 无论您需要记录什么（例如决策文件），都一次尝试只关注一件事，并且仅记录有关该问题的必要信息. 丰富的文档难以阅读和理解，其他信息应保留在附录中. 特别是对于决策文件，讲一个有说服力的故事比丢掉很多争论更重要. 此外，这可以节省您和您的同事很多时间，因为您必须阅读这些文档. 看一下您过去做过的一些文档（源代码，模型，决策文件等），然后问自己以下问题: “所有必要的信息都用于理解其中包含的文件吗？”什么可以省略？ “，”文档中是否有红线？ “

了解有关体系结构框架的更多信息: 这也适用于所有其他“技术”建议. 我将其放在此处是因为TOGAF或Zachmann之类的框架提供了在文档站点上很重要的“工具”，尽管它们的附加值并不限于文档. 对此类框架的深入了解将教会您更系统地处理架构.

参考链接:

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-193695-1.html