前不久，高级架构师JustinMiller在GitHub上创建了一个项目来介绍他关于如何成为更好的软件架构师的想法。该项目在发布后的一天内获得了1400颗星，目前已拥有近5000颗星。图片来自Pexels几年前有人问我：你是如何成为一名软件架构师的？我们讨论了所需的技能、经验以及获取知识所需的时间和精力。此外，我也会回顾自己走过的路，用过或尝试过的技术，以及从那些不同的工作中学到的东西。架构师技术路线图什么是软件架构师？在深入探讨之前，让我们先看看两个定义：软件架构师是做出高级设计决策并制定技术标准（包括软件编程标准、工具和平台）的软件专家。其中首席专家是首席架构师。软件架构是系统的基本组织结构。这种组织主要体现在它的组成部分、组成部分之间的关??系、组成部分与环境的关系以及决定系统设计和演进的原则上。架构的“层次”架构可以抽象为以下几个层次。不同的级别需要不同的技能。虽然划分层次的标准有很多，但我最喜欢的是将架构分为三层：应用层：架构的最低层。只专注于单个应用程序。水平低，但非常详细。这方面的沟通一般在开发团队内部进行。解决方案层：架构的中间层。专注于满足业务需求的一个或多个应用程序（即业务解决方案）。其中一些设计是高层设计，但大多数是低层设计。这种分层沟通开始涉及多个团队。企业级：架构的最高级别。专注于多种场景。这种架构的设计是高层和抽象的，因此还需要解决方案级和应用级架构师对其进行细化。这一级别的架构需要多个组织进行通信。有时，架构师也被视为不同工作组之间的粘合剂。以下是三个示例：横向：搭建业务部门与开发人员或不同开发团队之间的沟通桥梁。纵向：弥合经理和开发人员之间的鸿沟。技术：将不同的技术或应用程序集成在一起。软件架构师的日常要了解架构师必备的技能，首先要知道架构师主要做什么。在我看来，架构师最重要的活动包括：定义和确定所需的开发技术和平台。定义开发标准，例如编程标准、工具、审查流程、测试方法等。为识别和理解业务需求提供支持。设计系统并根据需求做出决策。记录关于体系结构定义、设计和决策的讨论。检查和审计架构和代码，比如检查之前确定的模式和编程标准是否正确实现。与其他部门和架构师合作。对开发商的指导和咨询。详细阐述高层设计并将其转化为低层设计。PS：架构设计是一项持续性的工作，尤其是在敏捷软件开发过程中。所以我们一遍又一遍地重复这些任务。软件架构师必备技能为了支持上述工作，需要具备许多重要的能力。根据我个人的经验，每个软件架构师都应该具备以下十项技能：设计能力、决策能力、简化能力、编码能力、文档架构能力、沟通能力、评估能力、平衡能力、引导能力、问答能力、营销能力能力，设计能力，什么是好的设计？这可能是最重要和最具挑战性的问题。有必要区分理论和实践。根据我的经验，两者的结合是最有价值的。让我们从理论开始：①了解基本的设计模式：设计模式是架构师设计和开发可维护和可扩展系统的最重要工具之一。使用设计模式，您可以针对常见问题设计可重用的解决方案。《设计模式：可重用面向对象软件的要素》由JohnVlissides、RalphJohnson、RichardHelm、ErichGamma撰写，是参与软件开发的每个人的必读书籍。尽管上述模式发表于20多年前，但它仍然是现代软件体系结构的重要基础。例如，本书介绍了模型-视图-控制器(MVC)模式，该模式在许多领域中都有使用，并且是一些新模式（如MVVM）的基础。②深耕模式与反模式：如果你已经了解了所有的GoF基本模式，你可以通过更多的软件设计模式来扩展你的知识，或者深入到你感兴趣的领域。我最喜欢的与应用程序集成相关的事情之一是GregorHohpe的书《企业集成模式》。本书适用于不同环境中的两个应用程序需要交换数据时，无论是一些遗留系统的旧式文件交换还是现代微服务架构。③理解质量度量：定义架构远未结束。由于质量和非功能性要求，指南和编码标准的定义、应用和管理是有原因的。您希望拥有一个可维护、可靠、适应性强、安全、可测试、可扩展、可用等的系统，实现所有这些质量属性的一种方法是应用良好的架构工作。您可以在维基百科上阅读更多关于质量测量的信息。理论很重要。如果你不想成为空中楼阁的建筑师，实践同样重要，甚至更重要。④尝试理解不同的技术栈：这是成为更好的架构师的重要工作。尝试新的技术堆栈并自上而下地学习它们。不同的技术可以为你带来不同的设计思路和模式。新技术最好不要肤浅地学习，多实践，深刻感受痛点和需要解决的现存问题。架构师不仅要涉猎面广，还要在某些领域有深厚的造诣。当然，不一定要掌握所有技术，你需要对你所在领域的核心技术有扎实的了解。你也可以尝试其他领域的技术，比如你对SAPR/3很深，你也应该试试JavaScript，反之亦然。始终保持好奇心并将其付诸实践。也可以尝试一些自己讨厌多年的技术。⑤分析理解应用模式：看一看目前流行的任何一个框架，比如Angular。有很多模式可以在实践中研究，比如“观察者模式”。尝试了解它在框架中的应用方式以及为什么要这样做。如果你真的有时间和认真，你可以更深入地挖掘代码并了解它是如何实现的。⑥加入一些用户组，比如Meetup。决策能力架构师需要能够做出决策并引导项目或整个组织朝着正确的方向发展。①知道要点：不要把时间浪费在不重要的决定或行动上。学会专注。据我所知，没有这方面的书。个人评估某件事是否重要通常会考虑两件事：概念完整性：即使您决定以一种方式做事，也要坚持下去，即使有时以其他方式做事更好。通常，这会使概念整体更简单，易于理解并易于维护。一致性：例如，如果您定义和应用命名约定，它是大小写不可知的，但是以相同的方式在任何地方应用它。②优先级：有些决定非常关键。如果不及早做出决策，后期就会有很多冗余的解决方案无法删除，导致维护困难，甚至导致开发人员在没有做出决策之前无法继续开发。在这种时候，一个糟糕的决定往往比没有决定要好。当然，遇到这种情况，优先考虑当前方案中的最优解。在这里，我建议查看在敏捷软件开发中广泛使用的加权最短作业优先(WSJF)模型。特别是，时间紧迫性和风险降低是评估架构决策优先级的关键。③明确自己的责任：不做超出自己能力和责任范围的决定。这一点很关键，如果不考虑，可能会严重损害您的架构师身份。为避免这种情况，请务必向您的合作伙伴阐明您的责任和角色。如果架构师不止一个，那么你应该尊重当前的组织结构。作为下级，最好是出谋划策，而不是做决定。此外，我建议始终与同行一起审查关键决策。④评估多个选项：做决定时，必须有多个选项。在我参与过的大多数情况下，有不止一种（好的）选择。只有一个选择在两个方面是不好的：首先，看起来你的工作做得不好，其次，它会阻止做出正确的决定。通过定义指标，可以根据事实而不是直觉（例如许可成本或成熟度）来比较选项。这通常会导致更好、更可持续的决策。此外，更容易向不同的利益相关者推销决策。此外，如果未正确评估选项，则在讨论过程中可能会遗漏某些因素。降低复杂性的能力记住奥卡姆剃刀的问题解决原则，它表达了对简单性的偏好。我将这个原则解释为：如果你对要解决的问题有太多假设，那么你的解决方案可能是错误的，或者导致不必要的复杂解决方案。为了得到一个好的解决方案，应该减少（简化）假设。①方案正则化：为了简化解，从不同的位置角度对其进行评估，往往有助于解的清理和正则化。尝试通过自上而下和自下而上的思考来形成解决方案。如果您有数据流或流程，请首先考虑从左到右，然后再从右到左。问这样的问题：在一个完美的世界里，你的解决方案会是什么样子？或者：“X公司/个人会做什么？其中X可能不是你的竞争对手，而是BAT（百度、阿里、腾讯）。这两个问题都迫使您减少奥卡姆剃刀提案的假设。②退一步：经过激烈和长时间的讨论，结果往往是高度复杂的草稿。您永远不应该将这些视为工作是最终结果。退后一步：再看看大局（抽象层次）。它仍然有意义吗？然后在抽象级别再做一次重构。有时停止讨论并在第二天继续讨论会有所帮助……至少我的大脑需要一些时间来处理并提出更好、更优雅和更简单的解决方案。③分而治之：把问题分成小块来简化。然后独立解决。然后验证小块是否匹配在一起。退后一步，看看这件事的大局。④重构不是坏事：如果你找不到更好的想法，从更复杂的解决方案开始是完全没问题的。如果解决方案遇到麻烦，您可以稍后重新考虑解决方案并学以致用。重构不是邪恶的，但在你开始重构之前，记住要做到以下几点：有足够的自动化测试来确保系统的正确功能。获得利益相关者的支持。了解有关重构的更多信息，我建议阅读MartinFowler的《重构 改进现有代码的设计》。编码技巧即使作为企业架构师，最抽象的架构层次，你仍然应该知道开发人员每天都在做什么。如果您不明白这是如何做到的，您可能会面临两个主要问题：开发人员不会接受您的话。不了解开发者的实际需求和面临的困难。①有一个sideproject：这样做的目的是尝试新技术和工具，了解现在和未来的开发是如何进行的。经验是观察、情感和假设的组合（KurtSchneider的“软件工程中的经验和知识管理”）。阅读教程或一些利弊是好的。但这只是“书本知识”。只有当您亲自尝试事物时，您才能体验情绪并形成关于事物是好是坏的假设。而且，您使用一项技术的时间越长，您的评估就会变得越准确。这将帮助您在日常工作中做出更好的决策。当我开始编程时，我没有代码完成，只有一些实用程序库来加速开发。显然，在这种背景下，我今天会做出错误的决定。今天，我们拥有大量的编程语言、框架、工具、流程和实践。只有有了一定的经验，对大趋势有了粗略的了解，才能加入对话，引导发展朝着正确的方向发展。②找到合适的东西去尝试：你不能什么都试。这根本不可能。您需要一种更有条理的方法。我最近发现的一个来源是ThoughtWorks的技术雷达。他们将技术、工具、平台、语言和框架分为四类：采用、试用、评估和保留。通过这种分类，可以更轻松地了解新事物及其准备情况，以便更好地评估下一步要探索的趋势：采用：准备提供企业级服务。Tryitout：能够在承担一定风险的项目中进行尝试。评估：需要进一步评估其对业务的影响。保留：谨慎处理。文档架构能力架构文档有时更重要，有时则不重要。架构决策或代码指南等重要文档。在编码开始之前通常需要初始文档，并且需要持续改进。可以自动生成附加文档，因为代码也可以是文档，例如UML类图。①干净的代码：如果做得对，代码就是最好的文档。一个好的架构师应该能够区分好的代码和坏的代码。RobertC.Martin的《代码整洁之道》一书是学习更多关于好代码和坏代码的重要资源。②尽量生成文档：系统变化快，更新文档困难。无论是API还是CMDB（配置管理数据库）形式的系统环境：底层信息往往变化太快，无法手动更新相应的文档。例如：对于API，如果你是模型驱动的，你可以根据定义文件自动生成文档，或者直接从源代码生成文档。那里有很多工具，比如Swagger和RAML是一些很好的开始选择。③必要且精简：无论你需要记录什么文件（如决定文件），你都应该一次只关注一件事，只包含关于这件事的必要信息。大量文档难以阅读和理解。附加信息应存储在附录中。尤其是决策文件，更重要的是讲一个有说服力的故事，而不是仅仅发表一大堆论据。此外，这还可以为您和您的同事节省大量阅读时间。查看您过去完成的一些文档（源代码、模型、决策文件等）并问自己以下问题：“它是否包含理解它的所有必要信息？”、“什么信息确实是必需的，可以省略吗？”和“文档中是否有任何红线？”。了解有关架构框架的更多信息：这一点也可以应用于所有其他“技术”点。我把它放在这里是因为像TOGAF或Zachmann这样的框架正在提供“工具”。这些工具在文档站点上感觉很重，尽管它们的附加值不限于文档。在这样的框架中获得认证可以教会您更系统地解决架构问题。沟通技巧据我观察，这是最被低估的技能之一。如果你在设计上很聪明，但不能传达你的想法，你的想法可能影响不大，甚至会成功。①学会如何传达你的想法：在会议协作时，知道如何正确传达你的想法并与你的同事同步是至关重要的。我发现《 UZMO-用笔思考》是提高我在这方面技能的重要资源。作为架构师，您通常不仅会参加会议，而且还经常需要主持和领导会议。②大型演讲：向小型或大型团体展示您的想法应该适合您。如果您对此感到不舒服，请开始将它介绍给您最好的朋友。慢慢扩大群体。这是你只有走出舒适区才能学到的东西。请耐心等待，此过程可能需要一些时间。③找到正确的沟通方式：不同的利益相关者有不同的利益和观点。他们需要在各自的层面上以不同的方式单独解决。在你交流之前，退后一步，检查你想分享的信息在抽象、内容、目标、动机等方面是否有正确的层次。例如：开发人员通常对解决方案的非常小的细节感兴趣，而管理人员更愿意知道哪个选项最省钱。④经常交流：如果无人知晓，载祥的结构就没有意义。定期在每个组织级别分发目标架构及其背后的想法。安排与开发人员、架构师和经理的会议，向他们展示需要或定义的内容。⑤透明度：定期沟通只能部分缓解透明度不足的问题。您需要对您的决定背后的原因保持透明。特别是，如果人们不参与决策过程，就很难理解和遵循决策及其背后的理由。⑥随时准备演讲：总是有人提出问题，你想马上给出正确答案。尽量将最重要的幻灯片放在一个统一的集合中，您可以展示和解释。它为您节省了大量时间，并为您自己带来安全感。评估能力①了解基本的项目管理原则：作为架构师或首席开发人员，经常会被要求评估你的想法的实现：需要多长时间、多少人、哪些技能等。当然，如果你打算引入新工具或框架，您需要回答这些“管理”问题。最初，你应该能够给出一个粗略的估计，比如几天、几个月或几年。别忘了，这不仅仅是关于实施，还有更多的因素需要考虑，比如需求管理、测试和错误修复。因此，您应该了解您正在使用的软件开发过程的工作原理。借助过去的使用数据，您可以获得更好的评估并据此做出预测。如果你没有过去的数据，你也可以尝试像BarryWBaum的COCOMO这样的东西。如果您被分配到一个敏捷项目，请学习如何正确估计和计划：MikeCohn的书《敏捷评估和计划》提供了该领域的可靠概述。②评估“未知”架构：作为架构师，您还应该能够评估架构对当前或未来上下文的适用性。这不是一项简单的任务，但您可以通过手头准备一组对每种架构都通用的问题来做好准备。这不仅仅是关于架构，而是关于系统是如何管理的，因为这也让你了解系统的质量。我建议始终准备好一些问题并随时使用。关于一般问题的一些思考：设计实践：架构遵循哪些模式？它们使用正确吗？设计是否遵循红线或是否存在不受控制的增长？是否有清晰的结构和关注点分离？开发实践：制定并遵循规范指南？代码的版本是怎样的？部署实践？质量保证：测试自动化覆盖率？静态代码分析到位且运行良好？同行评审到位了吗？安全：有哪些安全概念？内置安全性？渗透测试或自动安全分析工具是否到位并定期使用？平衡能力①质量是有代价的：前面我谈到了质量和非功能需求。如果架构被过度使用，它会增加成本并可能减慢开发速度。您需要平衡架构和功能需求。应避免过度设计。②解决冲突目标：冲突目标的典型例子是短期目标和长期目标。项目往往倾向于构建最简单的解决方案，而架构师则考虑长期愿景。通常，简单的解决方案不适合长期解决方案，并且有可能在以后被丢弃（沉没成本）。为了避免误导实施，需要考虑两件事：开发人员和企业需要了解长期愿景及其好处，以便微调他们的解决方案。负责预算的管理人员需要参与进来，以了解财务影响。不一定是直接到位的100%长期愿景，但大致在预算范围内制定。③冲突管理：架构师往往是具有不同背景的多个群体之间的粘合剂。这可能会导致不同级别的沟通冲突。为了找到同时反映长期战略目标的平衡解决方案，架构师的角色通常是帮助克服冲突。通信理论的起点是舒尔茨·冯·图恩的“四耳模型”。基于这个模型，可以展示和推断很多东西。但是，理论需要一些实践，应该在交流工作坊中体验。指导、问答技巧在咨询和指导方面，积极主动可能是最好的选择。如果有人问你，那就太晚了。应尽可能避免架构重构。你需要以某种方式预见未来的几周、几个月甚至几年，并为下一步做准备：①预见：如果你参与一个项目，无论是传统的瀑布方法还是敏捷方法，你总有一个需要对要实现的中长期目标有远见。这不是一个详细的概念，而是一个每个人都可以实施的路线图。由于不能一次完成（这是一段旅程），我更喜欢使用成熟度模型。它们给出了易于使用的清晰结构，并且每次都给出当前进度状态。我针对不同的方面使用不同的模型，例如开发实践或持续交付。成熟度模型中的每个级别都有遵循SMART准则的明确要求，因此很容易衡量是否满足要求。我发现的一个很好的例子是持续交付。②建立实践社区（CoP）：在一群有共同兴趣的人之间交流经验和知识有助于传播思想和标准化方法。例如，您可以每三个月左右将所有JavaScript开发人员和架构师聚集在一个房间里，讨论过去和当前的挑战以及如何解决这些挑战或采用新的方法和方法。架构师可以分享、讨论和调整他们的愿景，开发人员可以分享经验并向同行学习。这种交流不仅对企业而且对个人本身都有很大好处，因为它有助于建立更强大的网络和传播思想。另请查看文章SAFe框架中的实践社区，其中解释了敏捷环境中的CoP概念。③召开公开会议：误解或歧义的原因之一是缺乏沟通。在固定的时间段内，比如每周30分钟，与同事聊聊热门话题。这次会议没有议程，一切都可以讨论。尝试当场解决小问题。安排对更复杂主题的跟进。营销您的想法很棒，您已经很好地传达了它，但仍然没有人愿意效仿？那么你可能缺乏营销技巧。①动机与说服：公司是如何说服你购买产品的？他们展示了它的价值和好处。但不仅如此。它们经过精心包装并尽可能易于理解：原型：展示您的想法的原型。有许多用于创建原型的工具。在热爱SAP的企业环境中，查看build.me，在这里您可以快速轻松地创建美观且可点击的UI5应用程序。视频：与“枯燥的PowerPoint”不同，您还可以播放一段视频来展示您的想法或至少是方向。但请不要过度营销，从长远来看，内容为王。如果你的话不兑现，从长远来看会损害你的声誉。②坚持自己的想法：有时候人们不喜欢你的想法，或者懒得喜欢你的想法。如果你真的被你的想法说服了，你就应该继续追求它们并“战斗”。有时这是必要的。具有长期目标的架构决策通常不是最简单的：开发人员不喜欢它们，因为它们更复杂。经理们不喜欢它们，因为它们在短期内成本更高。坚持和谈判是你的工作。③寻找盟友：??建立或执行自己的想法即使不是不可能，也可能很困难。努力寻找可以支持和帮助说服他人的盟友。使用您的网络。如果您还没有，请立即开始构建它。您可以先与您的（思想开放的）同行谈论您的想法。如果他们喜欢，或者至少部分喜欢，他们可能会在被问及时支持您的想法（“X的想法很有趣。”）。如果他们不喜欢，问为什么：也许你错过了什么？还是你的故事不够有说服力？下一步是寻找具有决策权的盟友。要求进行公开和诚实的讨论。如果您害怕讨论，请记住，有时您需要走出舒适区。④重复，相信：“研究表明，反复接触一种观点会使人们相信它更普遍，即使它仅来自一个人。”（来源：《金融品牌》）如果你经常发布信息，你可以帮助你更容易说服人们。但请注意：在我看来，应该谨慎使用这种策略，因为它作为一种糟糕的营销技巧可能会适得其反。相关书籍：重构。改进现有代码的设计，作者：MartinFowler企业集成模式，作者：GregorHohpe设计模式：可重用面向对象软件的元素，作者：JohnVlissides、RalphJohnson、RichardHelm、ErichGamma软件工程师的经验和知识管理，作者：KurtSchneider清洁代码byRobertC.MartinUZMO—ThinkingWithYourPenAgileEstimatingandPlanningbyMikeCohn作者：JustinMiller编辑：陶家龙、孙淑娟来源：https://github.com/gamedilong/SoftwareArchitect-CNO原文：https://github.com/justinamiller/软件架构师
