标签：类库 height sci 迭代 人力 阶段 选择 年龄 答案
在盘点2019年全年平台各技术岗位薪资数据时发现，架构师是全年面邀薪资中仅次于CTO的岗 位，同时，将架构师作为期望求职岗位的候选人数，仅次于Java工程师、前端工程师，以及移动端工程师。
因此，今天会把从事多年的架构经验和大家做分享，我觉得很有必要，会比纯技术的分享更有意义。
今天我将以自己的亲身经历，与大家分享技术领导者成长过程中的几大常见难题，以及一名合格的架构 师应具备的素质。
经历了3-5年的一个技术人很常见的问题就来了：我是坚持走技术路线呢，还是走管理岗位？这个问题其实并没有标准答案。
每个人的喜好不同，对自己的规划也不同。
但我觉得不论走技术路线还是管理路线，首先技术能力是不可或缺的。
技术人，如果自己的技术都不过关，很难领导好一个团队。最基础的，面临一个技术问题的排期，如果 你技术不过关，恐怕也很难保证收到的排期是合理的、符合预期的。（毕竟谁也不会真心服一个能力比自己低的人）
其次是带队能力，技术专家并不只关注技术。技术是为业务服务的，一味地讲技术深度，做出来的东西 有时候并不符合业务的需要。所以，技术专家的存在，一是带领大家对技术做攻关，二是确保业务需求 架构设计更合理。当然，管理方向和技术方向对个人的要求还是有区别的。
管理方向更多的是带领团队完成某件事，利用 好人；例如按照公司的战略方向，制定团队的作战方法。技术专家则更多关注的是技术如何更好地服务 业务，利用自身的技术能力，赋能业务、赋能团队。
所以一定要根据自身的实际情况及个人规划，选择自己未来要走的路。
对于任何一个软件开发人员来说，架构师都是一个令人向往的角色。
其实架构师和程序员的界限并不是很大，比如现在仍然在每天写代码。成长首先来自于自身的学习，而阅读成熟项目的代码会使人受益匪浅，其次就是来自于所从事领域的经验，要了解分布式系统的特点，在做项目时，要能够关注性能、扩展性、可靠性、可用性等指标。
架构师其实就是一个漫长的积累过程（打野），从准备期到动荡期我们都是不停的探索，学习.大部分的高级架构师的年龄都是在35岁左右，这个阶段就是程序员的黄金期。
1、懂业务
没有业务，架构也就无从谈起。合理的架构也一定是随着业务的发展逐步进化的。
大部分初创公司人员简单，业务简单且变化较快，这个时候，单体应用比较合适。因为单体应用有更高 的开发效率，能够快速试错。但业务量上涨之后，公司的规模一般也会变大，人员增多，组织部门开始划分。
这时就要开始服务化， 降低系统间的耦合，职责更加清晰，每个部门对自己所负责的服务负责。随着业务量的持续上涨，就要进行更细的划分，这时可能就要使用微服务。微服务越来越多，就要去解 决服务治理，服务发现等一系列问题。
所以说，好的架构师一定是为业务设计架构。
2、技术前瞻性
架构师一定要站在业务和技术的更前端，考虑业务的发展对架构的影响，以最小的变动，支撑业务的发展。
拿某电商的订单服务来说，早期，单体应用没有订单服务，整个业务都是一个大的数据库。当业务量上 来后，有了订单服务，订单表从大库拆分，仅仅进行了拆表操作，没有进行拆库，导致后期订单库成为 了业务瓶颈，再次进行拆库耗费了很多的人力物力。
如果主导这次拆分的是一个合格的架构师，应该从一开始就要考虑到目前的技术选型是否符合业务的长期发展需求，选择一个更加合适的架构。
3、沟通协作能力
好的架构师能将自己的设计通俗易懂的讲给小伙伴，不仅要做到传道还要授业解惑。
同时，在日常工作 中，能够将自己的选型及设计清楚地传达下去，合理分工，还能交代清楚为什么这样做，这样做的好处 是什么。让每个人都清楚自己的职责，更好地完成工作内容。
好的架构师能够关注业务重点，及时解决 小伙伴们碰到的技术问题，给予支持，帮助整个团队一起提升。
4、持续学习的心态
新的技术层出不穷，持续不断地学习是技术人必备的通用素质，但架构师尤甚。新的技术能否帮助业务发展，我们现有的技术体系是否有需要借鉴的地方，都是架构师要持续学习的。
除了技术，业务方向也 是架构师需要学习的点，架构师要有广阔的视野，才能在后续的业务中有好的架构设计。
程序员要往一名架构师发展，需要进一步加强技能的修养。
对于互联网公司来言，最重要的技能是对网 络和分布式系统的理解，比较麻烦的是分布式系统，需要结合很多实际的项目和方案来理解。
因为同一个技术，在不同的项目经验后，绝对不是不同的理解。
首先架构师的技术宽度必须很广，技术深度在某一个领域是专家。
思考问题的角度尽量站的高一点,再高一点,从分解公司战略层面开始入手做架构设计
对业务的深刻理解，才能做好业务架构
理论学习&技术实践,什么时候都不能丢掉,这是技术架构的基础,重要性不赘述 同行业交流
时时对新技术保持敏感。
要成为一名合格的架构师仅仅通过理论学习是不行的，我自己理想中的架构师要求很高，不仅有丰富的 编码经验，而且还要熟悉硬件性能优化、内核调试、网络故障排查、系统安全、分布式系统，还有了解国内外技术的新趋势和特点，最重要的是还要善于与人沟通，敢于排除不同意见，敢于承担责任，了解团队内工程师的特点，善于将他们组成一个整体。
技术方面：
从最基础的开发做起
逐步提高解决高难度技术的能力
不断重构代码、不断优化代码，每次重构都是一次思考
业务方面：
从理解现有业务做起
从成为小领域业务专家,扩展到更多领域的业务专家
在每次重构底层代码时，更在不断思考业务架构重构与优化,做到以上,大约是个高级序员或准架构师水平。
做到以上，大约是个高级程序员或准架构师水平。
有独立思考,价值判定,建立在对行业,对公司战略和目标的深刻理解之上。
很强的语言翻译能力,能跟产品经理讲明白技术能把产品理念翻译成架构和可执行代码
影响力。
以公司战略在技术方面的分解为指导思想：
为团队设定技术规范、代码规范、文档规范
为开发团队、以及相关产品团队、测试团队、运维团队，规定流程和标准 为开发团队抽象、提炼、储备和推广通用代码类库、常用业务代码类库 。
根据实际操作情况，对以上内容不断优化和调整。
架构师最大的挑战是什么？
如何克服这些困难？
架构师最大的挑战是架构的落地和执行,克服方法,无它法,唯有紧密贴近业务。
示例1：公司战略需要半年内出某个新平台,力求速度,效率,作为竞争的重要利器。这时架构设计最忌讳过度设计,过于理想化,建议走实用路线,不断迭代,不断重构,小快灵的做一次次升级架构。
示例2：公司战略1年后重新规划系统,为未来3-5年做准备,这时架构设计当然需要尽量考虑周全,尽量留出足够的接口,保留灵活性扩展性。
高清大纲图可私聊小编获取
.
标签：类库 height sci 迭代 人力 阶段 选择 年龄 答案
原文地址：https://www.cnblogs.com/vwvwvwgwg/p/13170971.html
