【译】软件架构师之路
今天给大家带来一篇自己翻译的干货《软件架构师之路》。本周Github上升很快的项目。其内容对致力于成为软件架构师(不管前后台)的同学应该都会有极大的帮助。
项目地址
中文地址 gamedilong/SoftwareArchitect-CN
原文地址 justinamiller/SoftwareArchitect
假如有看完英文原文,发现本文翻译内容中存在问题或者者错误的欢迎到中文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) 决策能力
架构师需要能够做出决策并将项目或者整个组织引导到正确的方向。
- 知道重点: 不要把时间白费在不重要的决定或者者行为上。学会抓住重点。据我所知,目前还没有一本书讲这方面的内容。个人评估某件事能否重要,通常考虑如下两点:
- 概念完整性:即便您决定以一种方式做到这一点,坚持下去,即便有时以其余方式更好地做到这一点也是如此。 通常,这会让概念整体上更简单,简化可了解性并简化维护性。
- 一致性:例如,假如您定义并应用命名商定,它就无关于大小写,而是以相同的方式在任何地方应用它。
- 优先级: 有些决定是非常关键的。假如不尽早决策,会产生很多冗余到后期不太能删除的方案,导致维护困难,甚至于导致开发人员无法继续开发,直到给出决策。这种时候,往往给出坏的决定好于没有决定。当然,遇到这种情况时优先选择当前方案中的最优解。这里我建议看看在敏捷软件开发中广泛使用的加权最短作业优先(WSJF)模型。尤其是时间关键性和风险降低是评估体系结构决策优先级的关键。
- 明确自己的职责: 不要决策在你能力或者者职责范围之外的事情。这是至关重要的,假如不考虑的话,它可能会严重破坏你架构师的地位。为了避免这种情况,肯定要于你的伙伴们明确你承担的责任及角色。假如架构师不止一个,那么你应该尊重当前的组织架构。作为级别低的一方,最好是给出建议不是决策。此外,我建议始终和同伴一起评审关键决策。
- 评估多个选项: 在决策时,肯定要有一个以上的选择。在我参加的大多数案例中,有不止一个(好的)选择。只有一个选择是不好的,两个方面:首先,似乎你没有做好你的工作,其次,它阻碍了做出正确的决定。通过定义度量标准,可以基于事实而不是直觉(例如许可证成本或者成熟度)比较选项。这通常会导致更好、更可持续的决策。此外,向不同的利益相关者推销决策也更容易。此外,假如没有正确评估选项,则在探讨时可能会遗漏少量因素。
(3) 化繁为简能力
请记住Occam剃刀的处理问题的准则,它表示更喜欢简单。我把这个准则解释为:假如你对这个问题有太多的假设要处理,那么你的处理方案可能是错误的,或者者导致不必要的复杂处理方案。为了得到一个好的处理方案,应该减少(简化)假设。
- 方案规整:
为了简化处理方案,从不同的位置角度评估它们通常有助于清除、规整处理方案。尝试通过自上而下和自下而上的思考来形成处理方案。假如您有一个数据流或者进程,那么首先考虑从左到右,再从右到左。可以提出少量问题,比方:“在一个完美的世界里,你的处理方案会怎样样?或者者:“X公司/个人会怎样做?“(其中X可能不是你的竞争对手,而是BAT(百度、阿里、腾讯)之一。)这两个问题都迫使你减少Occam的Razor建议的假设。 - 退一步:
经过激烈和长时间的探讨,得出的结果往往是高度复杂的草案。你永远不应该把这些看作是最终的结果。退一步:再看一眼大局(笼统层面)。还是有意义的吗?而后在笼统的层次上再进行一次重构。有时,中止探讨并在第二天继续探讨会有帮助。至少我的大脑需要少量时间来解决和想出更好、更优雅和更简单的处理方案 - 分而治之: 把问题分成小块来简化。而后独立处理。而后验证这些小块能否匹配在一起。退一步看一下这个的整体情况。
- 重构不是坏事: 假如找不到更好的主意,从更复杂的处理方案开始完全可以。假如处理方案遇到麻烦,您可以稍后重新考虑处理方案并应用您的学习。重构不是邪恶的。 但是在开始重构之前,请记住要进行以下工作:(1)进行足够的自动化测试,以确保系统的正确功能;以及(2)从利益相关者的支持。 要理解有关重构的更多信息,建议阅读<<重构。 改进现有代码的设计>>,作者是Martin Fowler。
(4) 编码能力
即便作为一个企业级架构师,最笼统的架构层次,你依然应该知道开发人员每天都在做什么。假如你不明白这是怎样做到的,你可能会面临两大问题:
- 开发者不会接受你的嘴炮。
- 不理解开发人员的实践需求和面临的困难.
有一个辅助项目: 这样做的目的是尝试新技术和工具,以理解当今和未来的开发方式。经验是观察,情感和假设的结合(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的《敏捷评估和计划》一书提供了这个领域的一个坚实的概述。评估“未知”架构: 作为架构师,您还应该能够评估体系结构对于当前或者未来上下文的适用性。这不是一项简单的任务,但是您可以通过手头的一组问题来准备,这些问题对于每个架构都是常见的。它不仅关乎体系结构,还关乎系统的管理方式,由于这也让您理解了系统的质量。我建议总是准备好少量问题并准备好使用。一般问题的少量想法:
- 设计实践: 架构遵循哪些模式?它们能否得到正确使用?设计能否遵循红线或者能否存在不受控制的增长?能否有明确的结构和关注点的分离?
- 开发实践: 制定并遵守规范指南?代码的版本是怎么的?部署实践?
- 质量保证: 测试自动化覆盖范围?静态代码分析到位且效果良好?同行评议到位?
- 安全性: 有哪些安全概念?内置安全?渗透测试或者自动安全分析工具到位并定期使用?
(8) 平衡能力
- 质量是有代价的: 早些时候我谈到了质量和非功能性需求。假如过度使用架构,将会添加成本,并可能降低开发速度。你需要平衡架构和功能需求。应避免过度设计。
- 处理矛盾目标:
矛盾目标的典型例子是短期和长期目标。项目往往倾向于构建最简单的处理方案,而架构师考虑的是长期的远景。通常,简单的处理方案不适合长期的处理方案,并且有可能在以后被丢弃(沉没成本)。为了避免实施方向错误,需要考虑两件事:- 开发人员和业务部门需要理解长期愿景及其好处,以便调整其处理方案。
- 负责预算的经理需要参加进来,以理解财务影响。不肯定要把100%的长远眼光直接放在适当的位置,但开发出来的成本大体在预算范围内。
- 冲突管理: 架构师往往是不同背景的多个群体之间的粘合剂。这可能会导致不同层次的沟通冲突。为了找到一个平衡的处理方案,同时也反映长期的战略目标,架构师的角色往往是帮助克服冲突。 关于传播理论的起点是舒尔茨·冯·图恩的“四耳模型”。 基于此模型,可以显示并推论很多。 但是,该理论需要少量实践,在交流研讨会上应该有经验。
(9) 指导、答疑能力
在咨询和辅导方面,积极主动可能是最好的选择。假如有人问你,那就太晚了。架构重构是尽量要避免的。你需要以某种方式预见未来几周、几个月甚至几年,并为下一步做好准备。
- 有远见: 假如你参加在一个项目中,无论是传统的瀑布式方法还是敏捷方法,你始终需要对要实现的中长期目标有一个愿景。 这不是一个详细的概念,而是针对每个人都可以落地的路线图。 因为无法一次完成所有工作(这是一段旅程),因而我更喜欢使用成熟度模型。 它们给出了易于使用的清晰结构,并且每次都给出了当前的进度状态。 对于不同的方面,我使用不同的模型,例如 开发实践或者持续交付。 成熟度模型中的每个级别都有明确的要求,这些要求遵循SMART原则,以便轻松衡量能否已达到要求。 我发现一个很好的例子是持续交付。
- 建立实践社区(CoP): 在一个共同兴趣小组之间交流经验和知识有助于分发思想和标准化方法。 例如,你可以每三个月左右将所有JavaScript开发人员和架构师聚集在一个房间中,探讨过去和当前的挑战以及如何处理它们或者采用新的方法论和方法。 架构师可以共享,探讨和调整其愿景,开发人员可以共享经验并向同行学习。 这样的交流不仅可以为企业带来极大的好处,而且对个人本身也非常有利,由于它有助于建立更强大的网络并传播思想。 还可以查看SAFe框架中的文章实践社区,该文章在敏捷环境中解释了CoP概念。
- 进行公开会议: 误会或者模棱两可的一个起因是缺乏沟通。在固定的时间段内,例如每周30分钟,与同事交流热门话题。这次会议没有议程,一切都可以探讨。尽量当场处理小事。安排对更复杂主题的跟进。
(10) 营销推广
你的想法很好,你已经很好地沟通了,但是依然没有人愿意追随?那么你可能缺乏营销技巧。
- 激励和说服: 公司如何说服你购买产品? 他们证实了它的价值和好处。 但不止如此。 他们包装得很好,并使其尽可能容易消化。
原型: 展现你想法的原型。有很多创立原型的工具。在喜欢SAP的企业背景下,可以查看build.me,在其中您可以快速轻松地创立漂亮且可点击的UI5应用程序。
视频: 与“无聊的PPT”不同的是,你还可以播放一段视频,展现你的想法或者至少方向。
但请不要过度营销:从长远来看,内容是王道。假如你的话没有实现,从长远来看,这将损害你的声誉。
- 坚持自己的想法:
有些时候人们不喜欢你的想法,或者者他们太懒了,不喜欢你的想法。假如你真的被自己的想法所说服,你就应该不断地去追求它们,并“战斗”。有时这是必要的。具备长期目标的架构决策通常不是最简单的:开发人员不喜欢它们,由于它们更复杂。经理们不喜欢他们,由于他们在短期内更贵。这是你的工作,你要坚持和谈判。 - 寻觅盟友: 建立或者执行你自己的想法可能是困难的,甚至是不可能的。努力寻觅能够支持和帮助说服他人的盟友。使用你的网络。假如你还没有,现在就开始建造它。你可以先和你的(思想开放的)同龄人谈谈你的想法。假如他们喜欢,或者者至少部分喜欢,假如别人问他们,他们很可能会支持你的想法(“X的想法很有趣。”)。假如他们不喜欢,问为什么:也许你错过了什么?或者者你的故事不够有说服力?下一步是找到有决策权的盟友。要求开诚布公的探讨。假如你害怕探讨,记住有时候你需要离开你的舒适区。
- 重复一遍,相信它: “[…] 研究表明,反复接触某个观点会使人们相信该观点更为普遍,即便该观点仅来自一个人也是如此。”(来源:《金融品牌》)假如您经常发布很少的信息,则可以帮助您 说服人们更容易。 但请注意:从我的角度来看,应该明智地使用这种策略,由于它可能适得其反,成为糟糕的营销技巧。
架构师的技术路线图
Architect roadmap
相关书籍
- 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
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 【译】软件架构师之路