前端职业规划 – 非大厂前端工程师如何不断提升自己的技术和专业能力

如果你奔着题目来, 可以直接翻到最下面, 如果你更关心为什么这样做可以提升, 那你请从头看完.

前言

最近团队里发生了一 个有关性能的惨案, 一名客户在操作产品的过程中, 因为表格性能不佳导致卡顿, 卡的鼠标也动不了了, 经过一下午的多方会诊, 基本解决了性能问题, 但作为一名专业工程师的直觉告诉我, 这不仅仅是个技术问题, 这是个思维问题.

正文

一个有潜在性能问题的表格, 在明确不支持千条数据的情况下依然能够上线, 从表面看这是个技术问题, 但实际上是个思维问题

在需求评审和技术方案设计阶段, 缺乏系统性的评估方法, 只能依靠经验来判断需求的合理性和设计技术方案

我发现目前大多数公司内, 在需求评审阶段, 作为前端工程师参与其中, 我们往往没有一个系统性的思维指导, 单纯只能凭借业务熟悉程度和开发框架的掌握程度来评估需求, 往往会陷入一种 当时觉得还行, 但是一上线, 或者过一段时间怎么就不行了的窘境

并且在大多数时候因为技术方案的潜在缺陷, 导致我们不得不在临上线或者上线后加班加点打补丁, 但如此仓促的情况下, 谁又能知道这些补丁会不会埋下隐患呢?

为了解决这个普遍存在的问题, 我陷入了深深思考🤔…, 是不是有什么思维方式或者方法论能够指导我们更高效并且充分评估需求和设计技术方案呢?

吃完一顿小龙虾, 小龙虾告诉了答案…

需求是对业务的描述, 但业务是会发展的, 是动态的.

产品经理整理需求, 进行需求评审的时候往往是给出了当下业务发展的一个静态描述, 这种静态描述让参与需求评审的人往往忽略了, 业务本身不是静态的是动态的, 是会随着时间, 环境, 人发生变化的, 因此我们可以得到第一条结论

需求只是一段时间内稳定, 从长期来看, 需求是不可靠的也是不稳定的

基于这条结论, 作为前端工程师, 我们应该始终对需求的动态性保持关注, 即我们在进行相应的技术方案设计和技术选型的时候要始终以需求是会变的为基准, 你为了需求而实现的代码应该尽可能控制在较小的范围内, 因为他们都是不稳定的, 你应该通过合理的架构设计去隔离这些不稳定的代码

很多人用 React, 会写出一种大组件, 里面有很复杂的 JSX 和各种业务逻辑, 事实上其中并不是所有的代码都和需求实现有关, 并且需求的变动频率也不是每次都是整个界面, 而这种一坨的写法却把需求的变更关联到了整个界面上, 这就违反了上面提到的这一个原则.

坚信这条结论, 这样你就可以忽略产品常说的一句话 “诶诶, 放心吧, 这个不会改的.”

业务具有扩张特征, 存在水平和垂直扩张两个特征

对于前端工程师来说, 堆砌业务代码的代价主要来自两方面

• 随着业务扩张, 渲染性能和网络性能会持续恶化
• 业务扩张导致代码量增长, 代码量增长会导致可维护性的持续恶化

掘金上有很多将性能优化的文章, 不过我总结的前端性能优化 (非 Nodejs) 其实主要就两个方面 渲染性能 和 网络性能

而持续恶化的性能问题就是你接下来不断加班的罪魁祸首之一, 因此如果我们不想陷入无休止的加班窘境, 你得记住这第二条结论

业务是会扩张的, 因此随着业务扩张你写的代码性能会持续恶化

如果说前面我告诉你们永远不要相信产品经理的嘴, 那现在就是告诉你们永远不要相信自己的手, 因为你无法预知业务扩张的速度和程度, 所以你写的代码的性能表现是会随着业务扩张发生变化的. 前面我们用隔离变化代码的手段来应对产品经理的嘴, 那在这里, 我们有什么方法可以去应对自己的手, 从而避免无效加班么?

答案自然也是有的. 别急, 往下看

业务的水平扩张

业务的水平扩张是指业务经过一段时间发展, 客户/用户数持续增长, 用户使用中的产品因为数据增长, 部分组件的渲染成本会不断抬升, 比如开头举例的表格, 电商 APP 里的我的订单, 商品数量等等, 这些组件渲染的成本和数据的增长之间关联, 因此如果你忽略了这一点, 就会陷入业务水平扩张导致的性能陷阱, 为了避免这种情况, 我们需要对业务的水平扩张保持关注, 同时把所有随着数据增长会导致渲染成本上的组件独立出来, 小心的控制渲染过程, 通过类似虚拟渲染, 渲染阈值等手段避免产生线上问题. 而这一部分也会受到需求的影响而变化

受业务水平扩张影响的组件都是性能不稳定组件, 你需要尽可能将他改成性能稳定组件, 将渲染过程和数据量解耦, 如果做不到也应该控制其上限, 降低两者的耦合程度

业务的垂直扩张

业务的垂直扩张是指随着业务发展, 部分业务虽然没有数据上的增长但是用户对产品的体验和需求提出了更高的要求, 其表现往往是视觉交互升级, 功能升级, 原有的简单功能变得更复杂, 实现成本更高, 和水平扩张不同, 垂直扩张的影响范围更广, 几乎涉及所有组件, 在性能和可维护性上有双重影响, 因此我们需要在技术方案中增加垂直的架构分层, 确保影响是层层递减, 逐步削弱业务垂直扩张带来的影响. 比如往上统一组件库, 分离组件的交互和视觉效果, 进一步分离样式排版等, 往下统一应用开发模式, 收敛业务侧对开发环境的控制, 开发上云等等手段.

业务的垂直扩张可以看成是一场业务对现有代码的入侵, 而你的垂加架构分层设计就是一种战略纵深, 避免你的技术方案或者整个技术体系被业务一次击穿, 导致大量重构和颠覆修改

所以你以为你是在参加一场事不关己的需求评审么?

不, 每一场需求评审, 都是你思考如何用技术去应对业务扩张的机会, 是你改善现有技术方案, 思考更优解的机会, 是你朝更专业的前端工程师甚至朝着架构师迈出一步的机会, 但你是怎么做的?

😪😴😴😴就过去了……

我知道大多数人可能看得云里雾里, 没事我给你总结下

• 不要相信产品经理关于需求不会变的扯谎, 他自己都不信
• 需求背后是业务, 业务的扩张会带来性能和可维护性上的持续压力
• 基于以上两点你要带着脑子去参加评审, 思考如何应对, 方法在上面的段落里
• 工程管理能力, 技术方案设计能力, 架构设计能力的成长是你对每一次需求评审仔细思考的结果, 不是你写代码的结果, 你写 100000 小时代码, 那也还只是代码不会对你的上述能力提升有帮助. 思考可以提升, 写代码只能练手速.

点题

非大厂前端工程师如何不断提升自己的技术和专业能力

我们总是把希望寄托在环境上而非自身, 很多人觉得自己进了大厂才有机会好好深造下, 在小公司很难提升自己的技术水平, 于是大家都倾向于不在大厂的时候玩些刺激的新鲜玩意, 作为大厂的晋升之阶, 比如捣鼓下 Babel 插件 / 搞个脚手架 / 自己写个 React / 自己搞个 Redux / 模拟 Vue 写个指令的效果等等, 但作为过来人, 我想告诫各位, 这些方式是可以帮你混进大厂, 但相信我进去了你也只是个螺丝钉, 如果你想真正在职业生涯上更进一步, 需要提升或者练习的不是这些工具框架模仿或者掌握的能力, 新工具层出不穷, 新框架还在路上, 学不完的.

作为一名前端工程师, 你的核心能力不是前端, 而是工程师, 前端 13年前没有, 难道 20年以后就能一直有么, 但是工程师已经存在很久了, 上面那些技术都是前端技术, 随着前端的消失他们也会消失, 但是作为一名工程师, 你的工程管理, 技术方案设计, 架构规划等等能力才是核心, 是不会随着某个领域消失而消失的, 这些能力是和整个大的软件工程体系绑定的, 拥有和算法, 计算机底层原理一样的生命力, 值得你不断的去学习和提升, 我相信只干前端, 你难过 35, 但是作为工程师, 你应该拥有更长的职业寿命

因此当你抱怨公司小, 技术团队人数少, 氛围差, 技术栈老旧的时候, 天天只堆业务代码的时候, 你可能正在浪费时间, 而你睡过去的每一次需求评审, 或者糊弄过去的每一次业务迭代都是在浪费你成为更专业的前端工程师的机会

后话

我看到掘金里很多同学都想谋求前端技术上的提升以获取职业晋升, 并且因为各种内心的焦虑, 觉得前端技术变化这么快, 不会新的就会被淘汰, 现在又猛攻算法之道, 我觉得其实有点舍本逐末了, 前端工程师, 或者软件工程师, 你的核心能力除了编程能力, 更主要的是你的工程方面的专业能力, 是实际解决业务问题的能力, 尤其是作为前端工程师, 说实话我们所掌握的算法能力和编程能力那都是基础, 只是为了更好的构建上层能力的底线, 但本身并不能直接解决业务问题或者产生价值, 除非你从事算法研究(不是算法调参工程师, 那还是工程问题), 那这点算法基础远远不够, 或者底层计算机理论的研究, 但我相信你既然来看掘金, 应该不是这类人.

希望以此文唤起大家对软件工程领域的兴趣, 而不是仅仅聚焦在基础知识和纯前端技术领域, 我相信这并不是一种健康的职业发展模式

大家似乎都把眼睛盯着那些金矿(各个大厂, 超级独角兽, 明星企业), 而忽视了手里的银矿, 铜矿等资源, 我们跳来跳去(跳槽)丢掉手里的资源, 无数人拥挤在一条独木桥上只为了那个靠近金矿的机会, 却没有发现有些人利用银矿和铜矿等其他资源早就跑在了前面

本文使用 mdnice 排版