阅读 2258

前端职业规划 - 如何从一线开发转职架构师

前言

我记得 17年出来找工作的时候, 很少看到有前端架构师的招聘, 但是 3年后的现在你会看到像 BOSS 直聘上已经有很多关于前端架构师这样的 Title 的岗位, 这也说明在这 3年, 前端从业人员无论是规模还是面对的挑战都有了极大的变化, 前端其实有很多概念都是来自于后端, 其实这么说不准确, 对于软件工程来说, 软件架构师一直都存在, 只是对于前端这个领域, 近几年才开始有了明确的需求, 这也为一线的前端开发开辟了一条新的发展道路, 相比从事管理工作而言多了一个选择, 成为前端架构师

我在关于前端架构 - 让我们从架构说起中阐述了我对前端架构的概念上的理解, 过去几年也面试过不少前端架构师, 将一些面试考察的经验写在了前端面试 - 如何考察候选人的架构能力

这一篇就想聊聊如何从一线开发到架构师

先说说残酷的现实

如果你刚工作没几年, 年轻富有朝气, 对技术有热情, 憧憬着自己的职业生涯稳步向前, 那我恐怕得先给你来碗毒鸡汤, 现实非常残酷, 因为现实不是一场游戏.

玩过暗黑破坏神类型的游戏的同学应该知道, 这种 RPG 都有转职系统, 基本上你技能点到一定程度都可以完成转职, 转职后的强弱只看你技能如何点, 其实现实中的职业也差不多遵循这样一套体系, 我们有需要点的技能点, 有些技能会对其他技能产生加成, 或者有些技能会影响某些技能的发挥, 作为老司机, 我后面要讲的其实就是如何点, 怎么点更高效, 更有用, 但是你首先得知道一个事实 和游戏不同, 游戏是你花了钱买了一份只属于自己的 Copy, 资源是无限的, 你唯一要做的就是考虑如何花更少的时间换更多的资源, 但现实世界中, 大家是共享一个社会, 资源是共享的, 大多数情况下你花了时间也未必能换到资源, 而成为一个前端架构师需要很多资源

和普通的一线开发不同, 一线开发中你获取的资源包括开发技能和知识, 因为技术开源加上互联网信息搜索的便利, 大部分一线开发, 或者刚毕业的学生比拼的依然是时间成本, 不同人的优势在于学生阶段的基础积累对于获取技能的有效加成, 当然还有竞争岗位的潜在机会成本, 但总体来说依然是一个可以依靠时间来弥补的阶段, 举个例子

假设你想去大厂, 但是你自己学历背景一般, 你面对的对手各种各样, 有清北高材生或者野路子选手, 但人总是有七情六欲的, 如果你极度自律, 不谈恋爱不刷抖音不闲逛, 通过对时间的极致利用和压榨, 你依然有机会获得相同的工作机会成为一名大厂一线开发.

但是大厂一线开发也干不了几年, 如果不能持续向上转职, 面临的就是这样一个路线

22-30, 从初级到高级工程师
30-35, 从高级工程师到老油条工程师
35-40, 逃离大厂, 进入中小公司混饭吃
40-50 ?
复制代码

事实上一旦过了 35, 就得看天吃饭, 因为岗位需求主要来自于创业公司, 但经济环境不好的时候就没有创业公司, 也就没了这些岗位, 比如当下

不过最近我发现很多传统公司开始转型, 产生了一些对程序员的需求, 或许是未来程序员需求的另一个增长点, 但适应了互联网模式的这一代程序员是否能适应传统公司, 我持怀疑态度, 有待观察

所以如果你没想过要成为架构师或管理, 我建议 35 之前把赚到的钱存起来, 学点投资知识, 另外最好尽可能的和另一半达成共识, 晚点生孩子, 集中精力赚钱, 这样转职失败, 后续也给自己的人生留下别的可能性.

一般一个 10 - 20 人的前端团队需要一到两名架构师, 按照这种比例, 架构师的需求相比 TL 会多一些, 差不多 10% 到 20%. 也就意味着 10 个高级前端工程师仅有一个可能转型成功, 必然有 9个 失败者.

所以为什么会失败? 难道苦学技术, 通过不断的技术投入大家不应该都可以成功么, 比如像一开始从初级到高级那样?

之所以会这样, 关键在于, 架构师是一个强调实践的职业, 要培养一名架构师, 需要投入大量的资源, 就拿一个做前端基础架构的架构师举例吧, 假设你有幸在团队内获得了担任基础架构设计的职责

  • TL 要给你配人, 协助你开发, 协助你开发的同事的精力是公司买单的, 假设一个高级开发 25000/月, 不算其他额外成本, 4个高级开发配合你, 50%的精力, 为了实践你的设计, 完成你的工作, 假设项目持续了1年, 则光这部分公司就为你成为一个架构师花费了 60万, 是不是比你年薪还高?
  • 假设第二年你的架构在不同业务中落地, 于是业务方的研发要配合你...

所以培养一名有经验的优秀的架构师, 公司花费的资源可以说是以百万千万计, 如果大厂中承担极核心架构的工作可能以亿计, 公司能对每一个高级开发都投入这种资源么?

答案是显然的, 不可能, 这就是 90%淘汰率背后的残酷现实, 要转职, 你需要去参与竞争, 击败你 90% 的同事, 同行, 踩着他们上位.

在日常美好合作的背景下, 其实隐藏的就是这样激烈的竞争, 当然我说的可能会过于残酷, 但这样有助于你理解这个现实

而成为架构师, 转职成功, 并不意味着你的职业生涯的安全, 架构师的竞争只会比一线开发竞争更残酷, 从初级到高级到资深架构的每一步, 都需要淘汰对手, 抢夺资源.

阿里黑话里经常说的一个词, "要性" , 其实就是强烈的竞争意识.

如何让自己有资格去竞争

把转职架构师变成你自己的一种执念

我们玩游戏的时候, 通宵达旦, 就是为了尽快点满技能转职, 然后体验一把豪华技能的杀怪效果, 你当时那种状态就是一种强烈的欲望, 想从一线开发转职到架构师, 先不谈思维, 最基本的就是欲望, 你内心要有强烈的冲动和欲望成为一名架构师, 让这种欲望成为你的执念, 只有这种执念才能驱动你去迎接挑战, 争取资源, 和主动学习, 很多时候你并不需要知道如何做, 或者你甚至于根本不了解什么是前端架构师前就必须有这种执念, 这种执念会让你先人一步, 赢得未来的竞争.

当别人问你的职业规划是什么, 不要犹豫, 直接回答 "我要成为一名前端架构师", 反正我估计面你的人可能也不知道前端架构师是个啥 😀

从建立架构思维开始

前端有很多优秀的开源框架, 比如 React Vue 等等, 每一个框架内部都有非常庞大的源码, 网上有非常多的关于这些源码的解读, 但是你会发现很少有人从架构的角度去解读这些框架, 难道 React Vue 内部是没有架构设计的么? 当然不是, 不仅有, 还有非常棒的架构设计, 来让如此大规模的开源项目能够不断演进的同时保持平衡, 其实在 Vue3 中尤就提到过 Vue2 的架构中存在的问题以及 Vue3 如何解决, 如果你看过 Chromium 的文档, 开篇就有关于架构设计的部分解读, React 在官方文档中也加入了关于 Fiber 的架构设计, 这些文档的角度和一般的源码解读完全不同, 更抽象而且是动态的, 有变化发展思考, 一般的源码解读文章会侧重于算法的解释, 逻辑流程的处理, 但架构解读的则会侧重于解释整个框架内部的边界在哪, 边界隔离的空间彼此如何有效运作, 在面对场景时有哪些问题, 如何改进等等, 这是一种完全不同的思维方式

当你从事了多年前端开发, 拥有丰富的开发经验, 扎实的技术基础, 同时抱有强烈的转职信念, 那你接下里需要的就是建立架构思维, 刻意训练这种思维方式, 来扭转多年一线开发行程的思维习惯

习惯的力量非常强大, 我见过很多高级开发在建立思维这个步骤就失败的情况, 他们不乏名校大厂背景, 聪明优秀, 但是却败给了习惯. 因为经历了 5年以上的一线开发之后, 我们会习惯性的将对任何问题的思考局限在某一个领域, 或者探究某一个细节, 就拿上面源码解读这件事, 都会习惯性的从某个 API 开始去读, 然后看里面怎么走怎么走, 然后积累了一堆细节在脑子里. 这种习惯正是你转职的最大阻碍

人脑处理的能力其实极其有限

我国领导人, 作为整个中国的架构师, 要处理的问题的复杂性可以说是人类史上的前所未有, 试想如果他需要关注到每个街道的路牌是否安置合理, 才能做出规划, 我简直不能想象, 这该怎么做, 或者他脑袋里装一堆路牌, 那估计最多也就做个街道架构. 还不一定设计合理.

所以我们要认识到人脑的处理能力极其有限, 有研究表明在记忆过程中超过 3组信息就容易产生遗忘

我们需要对细节进行抽象, 抽象到足以组成基本可分析的架构单元, 然后再分解再分析, 就拿 React 内部架构为例, React 内部架构包括了 ReactCore, ReactDom, Fiber, 作为 React 架构师, 你需要考虑的就是这些子架构之间的关系, 以及如果 16版本要添加 Hook 你如何保持现有架构的同时又将其加入其中呢? 再然后分解到 Fiber 内的架构, 就有了 current, workInProgress 等概念.

架构的最大特征是其内部具有边界, 当拆解到某个程度看不到边界的时候, 我们可以认为最近一个具有边界的架构单元就是当前架构的最小子架构

所以架构思维是自上而下的, 而不是我们习惯的那种自下而上的思维方式, 这种完全逆转的思维方式是对我们习惯的极大挑战, 这也是为什么很多高级开发在这一步失败的原因, 毕竟你如果没法早起, 没法减肥, 没法不吃辣等等都是对自我习惯的挑战, 习惯的力量如此强大, 在缺乏信念驱动的情况下我们几乎无法改变我们自身的习惯

这也是为什么我把 "把转职架构师变成你自己的一种执念" 放在第一条的原因

刻意练习与机会竞争

我不会告诉你太多关于架构理论方面的知识, 事实上处理架构工作的两条核心法则极其简单

  • 寻找建立确认边界来设计和组织架构
  • 保持边界内外平衡, 让多方达成一致

如果说架构设计是平面的, 那实际架构是运行在一个多维空间, 你可以将前端架构看做是一个立体的结构, 你需要和不同岗位的人打交道, 比如产品, UI, 后端等等, 你需要团队成员的配合, 你需要掌握其他各种软性能力, 这些我不在这里展开

你唯一要记得, 架构能力需要刻意练习, 你需要主动承担架构设计的工作, 争取架构维护上的机会, 用你的架构思维去分析现有项目的架构, 找出问题加以改良, 当然你还需要持续学习前端领域的知识和技能来扩充自己的架构工具箱, 以处理更复杂更宽泛的问题

后话

我并没有在这里讨论关于一线开发和架构技能上的区别, 因为我从来不认为那是两者的核心差异, 就像社会普遍存在的 2/8 原则, 我们要相信 90% 的人没法成为架构师, 这是规律, 无人可破, 就像我说的残酷现实, 即便我告诉你如何去做, 但你依然有九成的概率会失败, 因为这个过程太过于复杂, 里面有太多变数, 甚至你的同事, 你的领导, 你所在的行业都会深刻影响你成长的过程, 但我希望通过这篇文章揭示一些东西

  • 九成人会失败
  • 大部分人无法成功建立架构思维, 因为习惯
  • 即使你建立了架构思维, 依然可能因为年龄增长, 因为机会竞争的失败, 或者时运不济而无法成为架构师

如果你知道这些困难依然决定走这条路, 那开始自我挑战, 从打破思维习惯开始吧. 祝你好运!!

本文使用 mdnice 排版

关注下面的标签,发现更多相似文章
评论