因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享
点击关注#互联网架构师公众号,领取架构师全套资料 都在这里
大家好,我是互联网架构师!
今天是国庆节,祝大家国庆节快乐!
今天我们聊聊如何成为架构师,架构师从入门到放弃
如果你的未来职业目标是架构师,强烈建议仔细阅读并收藏。
“我怎么才能成为一个软件架构师?”
这是很多小伙伴问我的一个问题,最近看到Kai Niklas讲架构师的一篇文章,其中的真知灼见引起了我的强烈共鸣,尤其是后面的非技术部分。翻译过来(略有删减),分享给大家。英文文章请点击”阅读原文“。
我事先给一位同学看了一下,他说:当个架构师太难了吧,又要精通技术,还得会沟通,平衡,营销..... 我还是争取做个技术专家吧!
扪心自问,我这个架构师在很多方面也做得远远不够,继续学习吧!如果你的未来职业目标是架构师,强烈建议仔细阅读并收藏。
01
什么是软件架构师
在我们一头扎入细节之前,我们先得知道软件架构和架构师到底是什么:
软件架构师是一个软件专家,他可以做出高层的设计决定,规定技术标准,包括编码标准,工具和平台 -- Wikipedia
软件架构是一个系统最基本的组织方式,由其组件,组件之间的关系,组件和环境的关系表达出来。也包括决定设计和系统演化的原则。--Handbook of Software Architecture
02
架构的级别
架构可以在不同的抽象级别上完成, 不同的级别要求不同技能,有很多分类标准,我最喜欢的是这三个级别:
Application Level (应用级别):架构的最低级别,专注于单个应用,有非常具体的设计,沟通通常局限在开发团队
Solution Level (解决方案级别) :架构的中间层,需要关注几个应用来实现一个商业的需求,有部分高层的设计,但大多数还是具体的设计,沟通需要跨越多个开发团队。
Enterprise Level (企业级别):架构的最高级, 关注多个解决方案,这一层的设计比较抽象,需要解决方案架构师和应用架构师去细化。沟通跨越整个企业组织。
有时候,架构师被看作不同利益相关者之间的粘合剂,比如:
水平方向:在业务人员和开发人员建立沟通的桥梁
垂直方向:在开发人员和经理之间建立沟通桥梁
技术领域:集成不同的技术和应用。
03
软件架构师的日常活动
为了理解软件架构师需要哪些技能,我们得先来看看架构师的日常活动
确定开发的平台和技术
确定开发标准和规范:编码标准,工具,评审流程,测试方法等
根据需求,设计系统并且做出架构设计决定
把架构设计和决定文档化,和团队沟通
把高层的设计变成底层设计
检查、评审架构设计和代码,比如看看确定的模式和代码标准是否正确施行
和其他架构师、利益相关者协作
指导开发人员
注: 架构设计是一个持续的活动,所以这些活动会一遍一遍地完成。
软件架构师所需的重要技能
根据我的经验,阅读的书籍,以及参与的讨论,我可以列出这10个技能,每个架构师都必须具备:
设计, 决策,简化, 编码, 文档, 沟通, 估算, 平衡, 咨询, 营销
我们一个个来说,对每个技能我都会列出一些我的见解,你应该采取的行动,以便在这个技能领域持续提高。
04
设计
是什么造就了好的设计?这可能是最重要,并且最具挑战性的问题,让我们先从理论开始。
理解基本的设计模式:为了开发一个可维护的系统,模式绝对是架构师最重要的工具之一,使用模式,你可以复用设计来决定那些通用的问题。“四人帮”的《设计模式:可复用的面向对象软件基础》是每个开发人员的必读书籍。尽管过去20多年了,模式依然是软件架构的基本单元。
比如书中描述的MVC模式被应用在很多领域,也是很多新模式如MVVM的基础。
深入挖掘模式和反模式:理解了基本的“四人帮”模式以后,你需要把你知识扩展到更多的软件设计模式中,或者根据自己的兴趣,深入研究,例如Java并发模式。
在应用程序的集成领域, 我最喜欢的是《企业集成模式》,这本书适用于各种领域,只要两个应用需要交换数据,不管是很古老的基于文件的交换还是现代的微服务架构,都可以参考本书。
了解软件质量的度量方式:我们希望我们的系统是可以维护的、可靠的、安全的、可以测试的、可以扩展的、可用的...... 为了达成这些目标,必须要把系统架构设计好。你可以参考这个:
理论很重要,实践更加重要,否则你就会变成一个象牙塔架构师。
不断尝试和理解不同的技术栈 : 我认为这是成为架构师非常重要的事情, 你很难从抽象的PPT中学到真东西,你得尝试不同的、新的技术栈,亲自感受一下它带来的好处和引发的“疼痛”。另外也可以尝试不属于你所在领域的技术,例如你对SAP R/3 非常擅长,那你应该也试试JavaScript。
分析、理解那些应用良好的模式:看看你当前使用的框架,例如Angular, 你可以研究很多以及付诸实践的模式,如观察者。看看它是怎么在框架中使用的,为什么要这么使用。如果你愿意投入更多的精力,那就深入源代码看看它是如何实现的。
保持好奇心,参加一些公司之外的社团活动:比如Java User Group会讨论很多主题,从最底层的编码到高层的架构,我很喜欢这样的活动,因为它会让我跳出工作来思考,并且加强个人社交网络。
05
决策
架构师需要能够做出架构决定,引导项目和组织走在正确的方向。
确定优先级:有些决策非常关键,如果没有在早期确定下来,就会出现一些变通的临时措施,导致后续难以移除,变成维护的噩梦。更差的情况是,程序员需要停止工作,等你做出决策。
为了避免这种情况,必须要把这些决策按优先级排序,我建议看一看敏捷软件开发中非常流行的Weighted Shortest Job First (WSJF) 模型。
了解你的能力:不要在你的能力之外做决定,这非常关键,如果你不遵循的话可能会毁掉你架构师的岗位。
所以一定要和你的同伴明确你承担的职责和你的角色。作为低级别的架构师,你可以提出对高层架构的建议,但是不要擅自做主。我建议要经常和同伴审视那些关键的架构决定。
评估多个选项:涉及到决策时,要列出多个选项。在我参与的大多数决策中,都有不止一个可能(好的)选择。仅仅提供一个选项说明你没有完成自己的工作,没法完成决策。各种选项要通过可以度量的事实(如许可证费用,成熟度)而不是个人感情来比较,这样才能真正完成决策。
06
简洁
要谨记解决问题的奥卡姆剃刀原则:如无必要,勿增实体。
对于一个问题,如果你有太多的假设,很可能会走向一个错误的方向,导致不必要的、复杂的解决方案。一定要精简假设来生成好的解决方案。(可见架构工作也是一门艺术)
“摇动”你的架构设计:为了让架构设计更加简单,可以从多个角度去审视解决方案,不但要以自顶向下的方式思考,还要自底向上的方式再来一遍, 如果你有数据流或者业务流程,先从左向右看,然后再从右往左看。
经常问自己:“在一个理想的环境中,架构设计会是怎么样呢?” “如果是那些大公司,它们会怎么做呢?” 这些问题会促使你减少假设。
退后一步:经常长时间的密集讨论,通常会得到一个高度复杂的设计,你绝对不能把它们当作最终结果,退后一步,从抽象的级别看看全局的图景,这设计还是有意义的吗?
有时候停止讨论,第二天再继续会有帮助,至少我的大脑需要时间来处理这些信息,然后提出更好的,更优雅的,更简单的方案。
分而治之:将大问题分成小块儿,逐个解决,然后看看小块儿解决方案能不能匹配起来。
重构并不邪恶:如果找不到更好的设计,从一个复杂的解决方案开始也是可以的。如果后面遇到了问题,你需要回过头来再想一想,重构并不是邪恶的,但是再开始重构之前要确保 :
(1)足够的自动化的测试用例,保证系统的功能不被破坏
(2) 获取利益相关者的认可。
07
代码
即使是贵为企业级架构师,也就是抽象级别最高的架构师,你也得知道程序员日常工作在做些什么。否则你会遇到两个问题:
(1) 开发人员不会接受你的想法、说辞
(2) 你不会理解开发人员面临的真正挑战和真正的需要。
做一个副业项目:目的是尝试新的技术和工具,以了解当前和将来的开发方式。阅读一些教程确实不错,但仅仅是“书本”知识。只有自己亲自尝试一遍,体验一遍,你才能获得真正的经验:它为什么好?为什么差?你和一门技术呆的时间越长,你的体验就会越多,就越能帮助你做出好的决策。
找到正确的技术来尝试:你不可能尝试所有的东西,我最近发现了ThoughtWorks的技术雷达,它们把技术,工具,平台,语言和框架分为四类:采用,尝试、评估和保留。
采用的意思是“适合企业采用”。
实验指的是“企业可以在一个风险可控的项目中尝试”
评估的意思是“研究下如果对企业产生影响”
暂缓意思是“谨慎推行”
通过这种分类,你就可以找到你想尝试的新技术了。
08
文档
Clean Code :简洁优雅的代码是最好的文档,架构师一定得能区分开什么是好代码,什么是坏代码。有一本很好的书来介绍好代码和坏代码:
在可能的时候尽量自动生成文档:对于一些较为详细的文档,由于系统变化迅速,很难及时更新,所以尽可能自动生成文档:如果你是Model Driven的话可以从定义文件中自动生成文档,SWagger 和RAML都是很好的起点。
该多就多,该少就少:无论是什么文档,在同一时刻只应该把注意力放在一件事情上,只包含这件事情的必要信息,额外的信息应该保留在附录中,因为大量的文字是很难阅读和理解的。 仔细看看你的文档,问问自己:“为了理解整个东西,是不是所有的信息都在其中了?” ,“哪些信息是必须的,哪些是可以忽略的?”
09
沟通
根据我的观察,这是最被低估技能,如果你在设计方面特别出色,但是却无法和别人沟通,你的想法就没啥影响力,很可能失败。
演讲:向一个小组或大组做演讲是一个架构师常见的工作,如果你刚开始觉得不舒服,可以从你的最好的朋友开始,慢慢扩大的更多的人,这件事只能通过不断地实践来学习, 是个需要花费时间的过程,还需要离开舒适区,所以要保持耐心。
找到正确的沟通级别:不同的人看待事物的角度是不同的,所以你需要在他们的级别和他们交流。比如开发人员对技术细节感兴趣,经理更倾向于知道哪个选项更加省钱。
所以在沟通之前,你要看看你想交流的东西是不是在合适的级别,包括抽象度,内容,目标,动机等
经常沟通: 如果无人知晓,一个出色的架构毫无意义,要经常沟通你的架构设计以及背后的想法,定期在每个组织级别(小组,部门,公司)进行沟通,安排和开发人员,架构师,管理人员的会议,展示你的架构思路。
保持透明:定期沟通只能部分缓解缺少的透明度,你还得确保决策背后的原因透明化,特别是对那些不参加决策的过程的人,他们很难理解为什么要这么做,有什么理由。
随时准备好做一个演讲:总会有人问架构师问题,你也想快速地给出正确答案,这该怎么办呢?你可以把最重要的PPT挑出来,放在一起,随时展示并且给他们做展示,避免在一堆资料中找来找去,那样会浪费太多时间。
10
估算和评估
理解基本的项目管理原则:作为架构师或者首席开发,你经常会被要求对你的设计进行估算:多长时间能完成?需要多少人?需要什么技能?
刚开始,你可以提供粗略的估算:几天,几个月。请记住估算的时间可不仅仅是编码实现,要有需求分析,测试,改正Bug。因此你需要知道软件开发过程中的各个步骤。获得更好估算的一个方法是基于历史数据给出预测。如果你没有历史数据,可以试试COCOMO方法,如果你在做一个敏捷项目,这本书非常有帮助:
评估架构:作为一个架构师,你应该能够架构设计在当前和未来上下文中的适应性,这件事不容易,你可以准备一组问题来对架构设计进行“质询”,例如:
(1) 设计实践: 架构遵循了哪些模式?是否正确地被使用了?是否有清晰的设计和关注点分离?
(2) 开发实践: 制定代码规范了吗?被遵循了吗?代码有版本控制吗
(3) 质量保证: 自动化测试的覆盖率如何? 有静态代码分析到位了吗? Peer review做到位了吗?
(4) 安全: 架构设计中有哪些安全概念? 内置安全性如何? 渗透测试和自动化安全分析是否做到位?是否定期使用?
11
平衡
质量是有代价的:前面聊过系统质量和非功能性需求,如果你在架构设计上做得过度,就会增加开销,降低开发的速度。你需要平衡架构设计和功能需求,过度设计应该被避免。
解决相互矛盾的目标:一个经典的例子就是短期目标 vs 长期目标。项目通常倾向于构建最简单的方案,而架构师脑海中有长期的愿景。通常,简单的方案不适合长期的目标,并且有可能被丢弃(沉没成本)。为了避免走向错误的方向,应该注意两件事情:
(1) 开发人员和业务人员都需要理解长期的愿景及其收益。
(2) 负责预算的经理也需要参与其中,了解财务影响。
冲突管理:由于团队有着不同背景,冲突难免发生,为了找到一个相互能接受的、平衡的解决方案,架构师需要充当粘合剂,来解决这些冲突。关于沟通的理论,我是从Schulze von Thun的Four-Ears Model开始的:
12
咨询和指导
拥有愿景 :不管你是在一个什么样的项目中,不管是传统的瀑布模型还是敏捷模型,你必须需要有一个愿景,也就是你想获得的短期和长期目标,并且清晰地传递给团队成员。
由于不可能一下子达成所有的目标,我通常倾向于建立成熟度模型,让团队清楚地得知我们当前处于哪一级别。开发有很多方面,得使用不同的成熟度模型,例如开发实践成熟度模型,持续交付成熟度模型。这些模型的每个级别都有清晰的定义,团队可以轻松地度量自己在什么级别。
对于持续交付,我个人倾向于这个模型
建立社区:例如,把JavaScript程序员和架构师组织起来,每个月讨论一次,主题可以是如何解决过去和现在的技术挑战,新的技术和方法。架构师可以分享、讨论他们的愿景,程序员可以分享他们的经验,这样的会议能帮助建立一个更强大的团伙,对企业和个人都极具价值。
进行开诚布公的讨论:误解和模棱两可的根源是缺乏沟通,所以你可以安排一个固定的时间段,如每周30分钟,和同伴交换一些热门的话题,什么都可以讨论,不用刻意安排讨论的议程。可以当场解决一些小事,对于复杂的主题,安排后续的跟进。
13
营销
你的想法很棒,并且和大家做了很好的沟通,但是没人愿意去做,那可能是缺乏了营销的技巧。
激励并说服:公司是怎么说服你购买他们产品的?他们肯定展示了价值和好处,但不仅如此,他们还做了漂亮的包装,使其尽可能地容易消化
(1) 原型:带界面的原型非常直观,会很吸引人。有很多创建软件原型的工具,如果你喜欢SAP的话可以事实build.me ,使用它可以轻松快速地创建漂亮的UI5应用。
(2) 视频: 除了无聊的PPT之外,用一个视频可以更好地展示你的想法。但是请不要过度营销,从长期看,内容为王,如果你满嘴跑火车,损伤的是你的声誉。
捍卫你的想法并且坚持不懈:如果你真的对自己的想法深信不疑,你应该捍卫它,为之战斗,这是非常必要的,因为具备长期目标的架构决策是不容易被人接受的:开发人员不喜欢它因为开发起来太难, 经理不喜欢它因为短期来看代价太高。所以坚持不懈地去说服是你的本职工作。
找到同盟军:独自去建立并且执行你的想法几乎是不可能的,你需要盟友的支持来说服别人。这时候需要使用你的社交网络,如果你还没有的话,马上去建吧!
你可以先去和那些具备开放心态的同事去谈你的想法, 如果他们喜欢(或者部分喜欢),当别人问起的时候,他们很有可能会支持你:X的想法很有趣。 如果他们不喜欢你的想法,问问为什么,你是不是漏掉了什么东西?你的故事不够吸引人?
下一步就是找到具备决策权力的盟友,请求他进行一个开放的讨论,如果你害怕这种讨论,你需要反思一下,是不是应该离开舒适区了。
重复它,相信它:研究显示重复的展示一个观点会使人们相信这是一个普遍的观点,即使该观点仅仅来自一个人。如果你经常发过某个消息,更容易说服别人。但是要当心:应该明智地使用这种策略,因为它可能适得其反。
相关阅读:
· END ·
最后,关注公众号互联网架构师,在后台回复:2T,可以获取我整理的 Java 系列面试题和答案,非常齐全。
如果这篇文章对您有所帮助,或者有所启发的话,帮忙扫描下发二维码关注一下,您的支持是我坚持写作最大的动力。
求一键三连:点赞、转发、在看。