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等世界顶级科技公司, 也切忌固步自封, 要多了解多同类问题的架构设计和解决方案, 取其精华弃其槽粕. 平时多了解多对比相关技术, 在遇到类似问题的时候, 就可以多一些参考信息, 少走一些弯路.
持续学习的能力
计算机技术发展速度非常快, 持续学习能力对于计算机工程师来说都非常重要, 特别是架构师还要求开阔技术视野. 持续学习能力与其说是一种能力, 更多的还是一种习惯的养成. 大家可以自己回想一下, 每天读多少文章, 每周或者每个月读几本书, 平时对于读到的文章或者书籍有没有记录笔记等. 处于信息爆炸的时代, 我们可以接触到的信息也越来越多, 持续学习能力还要注意信息质量, 注意把握信息的核心内容, 对信息区分精读和粗读. 这里我觉得一些付费内容往往质量较高, 正所谓一份价钱一分货, 为知识付费投资自己还是挺划算的.
技术影响力
架构师一定意义上也是某些领域的技术专家, 打造个人技术品牌, 树立技术影响力对于架构师来说就更为必要了. 现阶段技术社区非常活跃, 架构师可以通过开源项目, 技术论坛, 开设技术课程, 发表学术论文, 在技术类大会上发表演讲等多种途径来提升个人的技术影响力. 可以先从公司内部做起, 平时指导一线工程师的过程中, 注意积累素材, 积累到一定程度之后, 可以开设一些技术类课程, 然后可以到一些技术会议上进行更大范围的技术演讲等. 参与开源社区也是一种比较好的途径, 同时还可以接触相关技术圈子, 大家交流技术互通有无, 其乐融融.
沟通表达能力
作为架构师, 日常工作的沟通或者工作汇报必不可少. 能否将问题和解决方案表达清楚, 对待不同的听众, 能否区别的进行沟通都对架构师沟通能力的考察. 我在日常工作中参与过多次的职称评审, 也参与过无数次的技术评审和工作汇报等会议, 我发现很多架构师的通病就是平时不注意培养沟通表达能力. 有的同学一上来就讲解决方案, 很多同学对问题的背景都还不清楚呢, 大家自然对解决方案一头雾水. 有的同学对解决方案的非关键细节花费了大量的时间进行描述, 丝毫没有全局视角或者整体的介绍, 让大家听的是云里雾里. 有的同学在工作汇报时, 对技术方案进行了全方位阐述, 而忽略了对最终结果的介绍, 那大家可以想想老板是什么感受. 有的同学在和其他团队合作的沟通中, 强势的要求对方积极配合, 而丝毫没有替对方考虑的意思, 那这样的沟通成功率可想而之了.
类似的例子不胜枚举, 那么如何培养沟通能力呢? 我认为首先要能够站在听众的角度思考问题, 明白听众真正想要的是什么. 比如做工作汇报的时候, 老板更多的想知道事情的结果, 或者项目的计划, 对技术细节往往不那么关心. 做技术评审的时候, 评审专家关注整体的架构设计和技术难点的可行性, 对非关键细节就不需要过多阐述. 希望和其他团队合作的话, 尽量从双赢的角度, 先描述对方的收益, 然后在表达对方需要投入的工作, 这样往往能够取得对方的支持.
当然沟通表达能力的基础上是归纳抽象和逻辑思维能力, 如果没有良好的逻辑, 那么其他一切沟通技巧都是徒劳的. 另外强调一个沟通表达的礼貌问题, 那就是在发表意见之前, 注意倾听对方的话语, 切忌打断其他人的讲话. 随意打断别人的讲话, 不仅仅沟通低效, 而且还十分不礼貌, 沟通过程中如果遇到经常打断别人讲话的架构师, 那基本上可以敬而远之了.
技术管理能力
架构师不是做完架构设计之后就可以高枕无忧了, 架构师往往要带领整个研发团队完成架构的落地. 这就要求架构师即使不是经理角色, 也要具备一定的技术管理能力, 从而带着整个团队一起完成工作. 管理工作的核心就是管人, 管事和管钱. 管人就意味着需要和人打交道, 理解团队成员的特点, 建立良好的信任关系. 管事就意味着管理项目和技术的落地, 包括项目计划的拆解, 项目执行进度的追踪, 项目技术难点的攻克等等. 管钱就意味着需要考虑成本的因素, 考虑投入产出比, 考虑激励因素等. 管理是一门学问, 非常复杂, 我写在这里是希望架构师不能一味的钻研业务和技术, 也需要学一些管理方面的知识.
坚持正确的价值观
写在最后我觉得不仅仅是架构师, 一个成功的人, 往往都需要具备正确的价值观, 这也是我们常说的德才兼备. 我这里不是想让大家喝鸡汤, 而是我觉得任何所谓的能力都可以有意识的构建起来, 但是一个人的价值观等因素, 却是很容易被大家忽视. 比如遇到问题, 能不能首先反思自己的问题, 进行自我批评, 而不是仅仅觉得都是外界的问题. 比如遇到困难或者逆境, 能不能有坚定的信念和勇气. 比如待人接物, 能不能坚持诚信的原则, 能不能信守承诺. 比如面对挑战和压力, 能不能有所担当, 不甩锅不逃避. 比如面对误解, 能不能坚持原则, 能不能内心坚强. 诸如此类情况, 还有很多, 我理解这都是构建正确价值观的一些因素. 这也就是为什么我们常说先学做人, 在学做事的原因吧.
来源：https://www.cnblogs.com/elite-2012/p/10752227.html