架构师能力模型

https://github.com/elithnever/paperreading/blob/master/%E6%9E%B6%E6%9E%84%E5%B8%88.md#架构师能力模型

架构师能力模型

架构师在不少人眼中是一个很是高大上的职业, 就像武侠小说中的绝世高手同样, 关键时刻能够起到扭转乾坤的做用, 是团队中的灵魂人物. 回想我本身作一线架构师的过程当中, 也没有经历过比较系统的培训, 都是摸着石头过河. 近期在培养架构师的过程当中, 促使我一直在思考, 一个合格的架构师到底应该具有哪些能力? 对但愿成长为架构师的同窗, 或者在承担架构师职责的同窗, 须要提供哪些方面的指导和帮助, 才能让他逐步成长为合格的架构师呢? 下面我结合本身的经验, 总结了我认为对架构师来讲很是重要的十项能力, 但愿给那些努力成长为架构师的同窗提供一点点帮助.

研发流程的持续改进

架构师不是单兵做战, 凭借我的英雄主义是没法作成大事的. 架构师必定是指挥一个团队来共同完成既定目标, 或者一个复杂项目. 在软件研发领域, 决定团队研发效率的核心在于研发流程的优化. 现阶段互联网公司大多采用敏捷研发流程, 这其中主要包括:

• 需求卡片的状态流转. 尽量依靠工具实现状态的自动化流转, 减小人为操做的状况.
• 开发工具的选择. 好比web ide, 代码审查工具, 项目管理工具等.
• 代码的开发和审查(包括单测代码和测试流水线代码). 开发功能代码的同时, 必须同时提交单测代码和测试流水线代码, 保证新增代码的基本功能被覆盖. 尽可能不要分开开发, 保证测试代码的质量.
• 测试流水线的建设和持续优化. 测试流水线须要在测试覆盖率和运行时间方面进行平衡, 测试覆盖率越大势必会增长测试时间, 若是每次提交pr, 都须要跑很长时间的测试流水线, 那么无疑会下降研发效率. 这时候能够采用测试case分级的方法, 设计ci pileline, daily pipeline, perf pipeline等多条测试流水线, 而且以不一样的周期运行.
• 持续发布和持续部署. 敏捷开发模式核心就是但愿经过小步快跑的方式优化传统瀑布模型的阶段性开发模式, 让每次迭代尽量快速的获得效果反馈, 从而能够针对反馈更快速的进行软件迭代. 这就要求咱们必定要有持续发布和部署的能力, 能够采用灰度发布, A/B test等模式.

架构师须要对研发流程的每一个环节保持着敏锐的嗅觉, 能够及时发现其中的问题, 并提出有效的优化方法. 咱们常常讨论架构师要不要写代码的问题, 在我看来, 无论架构师是否动手写代码, 必定要对代码保持敏感. 保持敏感的方法就是对研发流程保持足够的把控, 参与代码审查, 持续的优化研发流程. 作职称评审的时候, 对于不作code review的架构师我一直是保持怀疑态度的, 我始终认为, 连代码都不进行review的架构师根本没办法真正指导一个项目或者一个技术方向, 至少一线架构师如此.

概括抽象和技术泛化能力

架构设计不少状况下我理解就是将共性和差别化的东西分离出来, 共性的部分抽象成独立的接口, 功能模块或者组件, 差别化的部分分别造成其余代码模块. 那如何识别或者分析出共性的部分, 我认为主要就是依靠架构师的概括, 抽象和技术泛化能力. 这须要架构师对问题进行反复深刻的思考和对比, 透过现象探究事务的本质, 须要架构师拥有触类旁通的能力. 锻炼这样的能力, 我以为能够从平常编写代码中体会和训练. 好比把握好代码设计的SOLID原则, 在须要的时候对代码或者架构进行局部重构, 参考写的更好的代码或者架构设计等. 另外在平常工做中及时进行总结和复盘也很是有必要, 不要一味地低头走路, 在每完成一些阶段性工做以后, 对本身的工做过程和成果进行总结, 发现其中的优势和缺点, 避免走弯路.

业务和需求的分析和理解能力

架构的核心是为了业务服务的, 不少架构师以为本身高高在上, 看不起业务研发同窗, 这可不是什么好的想法. 架构就是要让业务更快速的发展, 因此架构师必定要接地气. 所谓的接地气, 我认为就是要增强对业务的深刻理解, 可以预测业务的发展趋势, 提早在业务须要的技术方向进行适当的布局. 同时对业务提出的需求, 要多问多思考需求背后的本质是什么, 来帮助咱们识别并解决业务真正的痛点. 对业务的理解也意味着架构师不会设计出天马行空不切实际的架构, 可让架构师的架构设计更快的落地, 也让架构师可以更为顺畅的和业务研发同窗进行沟通和交流. 因此架构师切忌不可脱离业务, 要时刻保持对业务的必定程度的理解能力.

技术折中和持续改进能力

不少架构师或者研发工程师都有所谓的代码或者架构洁癖, 动不动就想重构或者重写, 并自认为是一种很是好的品质. 这确实在某种程度上体现了工程师的主动性和匠心精神, 可是绝对要把握好时机. 我相信任何一家公司或者任何一个代码模块, 都有所谓的技术债务或者实现的不那么好的代码和架构, 但愿短期内完全解决是不现实的. 架构师须要可以识别那些真正的技术债务, 而且要在适当的时机进行适当的重构来解决问题. 技术债务的识别能力是架构师抽象能力和业务理解能力等多方面能力的体现. 适当的时机指的是架构师可以在必定程度上预测将来的发展趋势, 同时结合当前的研发任务, 让架构朝着能够逐步迭代演化的方式来进化到理想目标. 迭代式的发展能够有效下降技术风险, 也可让架构师更能充分的把握理想目标. 这个过程要注意避免两个极端. 一个极端是架构师动辄进行大规模的重构, 一个项目耗时数人年或者更长时间上线. 这种状况不只项目风险极大, 上线以后很是容易回滚, 并且也大大减小了试错的机会. 能够说是不成功便成仁. 另外一个极端是架构师仅仅就是新功能的建筑师, 不断的添砖加瓦, 只关注新功能的设计和研发节奏, 而不作任何架构优化工做. 这样时间久了以后, 项目就会愈加难以维护, 周边相似项目不胜枚举. 固然上述两种情形毕竟只是极端状况, 更多的时候仍是考察架构师对时机的把握了.

技术广度和深度

这一项能力都比较容易理解了. 架构师毕竟仍然是工程师, 并且大都是从一线研发工程师逐步成长和积累起来的, 在某一技术领域或者技术方向一般都有较为深刻的理解和积累. 这里我想说的是, 无论是一线研发同窗仍是架构师, 至少应该在1~2个技术领域有着深刻理解的基础上, 再同时涉猎技术广度. 若是缺少对技术基础知识或者某个技术方向的深刻理解, 那想继续在技术广度上拓展就很是困难了. 就像那些所谓的武林高手, 一般都有深厚的内功根基, 学习其余武学招数就会特别快同样. 技术广度一般也成为技术视野, 计算机技术发展特别迅速, 即便在BAT或者Google/Facebook等世界顶级科技公司, 也切忌固步自封, 要多了解多同类问题的架构设计和解决方案, 取其精华弃其槽粕. 平时多了解多对比相关技术, 在遇到相似问题的时候, 就能够多一些参考信息, 少走一些弯路.

持续学习的能力

计算机技术发展速度很是快, 持续学习能力对于计算机工程师来讲都很是重要, 特别是架构师还要求开阔技术视野. 持续学习能力与其说是一种能力, 更多的仍是一种习惯的养成. 你们能够本身回想一下, 天天读多少文章, 每周或者每月读几本书, 平时对于读到的文章或者书籍有没有记录笔记等. 处于信息爆炸的时代, 咱们能够接触到的信息也愈来愈多, 持续学习能力还要注意信息质量, 注意把握信息的核心内容, 对信息区分精读和粗读. 这里我以为一些付费内容每每质量较高, 正所谓一份价钱一分货, 为知识付费投资本身仍是挺划算的.

技术影响力

架构师必定意义上也是某些领域的技术专家, 打造我的技术品牌, 树立技术影响力对于架构师来讲就更为必要了. 现阶段技术社区很是活跃, 架构师能够经过开源项目, 技术论坛, 开设技术课程, 发表学术论文, 在技术类大会上发表演讲等多种途径来提高我的的技术影响力. 能够先从公司内部作起, 平时指导一线工程师的过程当中, 注意积累素材, 积累到必定程度以后, 能够开设一些技术类课程, 而后能够到一些技术会议上进行更大范围的技术演讲等. 参与开源社区也是一种比较好的途径, 同时还能够接触相关技术圈子, 你们交流技术互通有无, 其乐融融.

沟通表达能力

做为架构师, 平常工做的沟通或者工做汇报必不可少. 可否将问题和解决方案表达清楚, 对待不一样的听众, 可否区别的进行沟通都对架构师沟通能力的考察. 我在平常工做中参与过屡次的职称评审, 也参与过无数次的技术评审和工做汇报等会议, 我发现不少架构师的通病就是平时不注意培养沟通表达能力. 有的同窗一上来就讲解决方案, 不少同窗对问题的背景都还不清楚呢, 你们天然对解决方案一头雾水. 有的同窗对解决方案的非关键细节花费了大量的时间进行描述, 丝毫没有全局视角或者总体的介绍, 让你们听的是云里雾里. 有的同窗在工做汇报时, 对技术方案进行了全方位阐述, 而忽略了对最终结果的介绍, 那你们能够想一想老板是什么感觉. 有的同窗在和其余团队合做的沟通中, 强势的要求对方积极配合, 而丝毫没有替对方考虑的意思, 那这样的沟通成功率可想而之了.

相似的例子不胜枚举, 那么如何培养沟通能力呢? 我认为首先要可以站在听众的角度思考问题, 明白听众真正想要的是什么. 好比作工做汇报的时候, 老板更多的想知道事情的结果, 或者项目的计划, 对技术细节每每不那么关心. 作技术评审的时候, 评审专家关注总体的架构设计和技术难点的可行性, 对非关键细节就不须要过多阐述. 但愿和其余团队合做的话, 尽可能从共赢的角度, 先描述对方的收益, 而后在表达对方须要投入的工做, 这样每每可以取得对方的支持.

固然沟通表达能力的基础上是概括抽象和逻辑思惟能力, 若是没有良好的逻辑, 那么其余一切沟通技巧都是徒劳的. 另外强调一个沟通表达的礼貌问题, 那就是在发表意见以前, 注意倾听对方的话语, 切忌打断其余人的讲话. 随意打断别人的讲话, 不只仅沟通低效, 并且还十分不礼貌, 沟经过程中若是遇到常常打断别人讲话的架构师, 那基本上能够敬而远之了.

技术管理能力

架构师不是作完架构设计以后就能够高枕无忧了, 架构师每每要带领整个研发团队完成架构的落地. 这就要求架构师即便不是经理角色, 也要具有必定的技术管理能力, 从而带着整个团队一块儿完成工做. 管理工做的核心就是管人, 管事和管钱. 管人就意味着须要和人打交道, 理解团队成员的特色, 创建良好的信任关系. 管事就意味着管理项目和技术的落地, 包括项目计划的拆解, 项目执行进度的追踪, 项目技术难点的攻克等等. 管钱就意味着须要考虑成本的因素, 考虑投入产出比, 考虑激励因素等. 管理是一门学问, 很是复杂, 我写在这里是但愿架构师不能一味的钻研业务和技术, 也须要学一些管理方面的知识.

坚持正确的价值观

写在最后我以为不只仅是架构师, 一个成功的人, 每每都须要具有正确的价值观, 这也是咱们常说的德才兼备. 我这里不是想让你们喝鸡汤, 而是我以为任何所谓的能力均可以有意识的构建起来, 可是一我的的价值观等因素, 倒是很容易被你们忽视. 好比遇到问题, 能不能首先反思本身的问题, 进行自我批评, 而不是仅仅以为都是外界的问题. 好比遇到困难或者逆境, 能不能有坚决的信念和勇气. 好比待人接物, 能不能坚持诚信的原则, 能不能信守承诺. 好比面对挑战和压力, 能不能有所担当, 不甩锅不逃避. 好比面对误解, 能不能坚持原则, 能不能心里坚强. 诸如此类状况, 还有不少, 我理解这都是构建正确价值观的一些因素. 这也就是为何咱们常说先学作人, 在学作事的缘由吧.