5年前端经验的大佬提供的职业规划(1)_工作四年的前端职业规划-CSDN博客

本文链接：https://blog.csdn.net/cwcnl25131/article/details/138446940

做职业规划的目的是避免迷茫，而避免迷茫最有效的方式就是确定明确的方向和目标。

方向

对于任何一个技术岗位，都有固定的两个方向：技术专家（架构师）和 开发经理。前者偏重技术，需要你在当前领域钻研得很深；后者偏向管理，需要你在对技术有很深掌握的同时，可以带领团队完成项目的开发。当然，两者并不是鱼与熊掌的关系，你可以同时成为技术专家和开发经理。

对于技术专家和开发经理两个方向的选择，更多取决于你自身在工作中多巴胺的分泌情况。当你专研技术时，多巴胺分泌得更多，感到更兴奋，或许你会很容易成为技术专家；反之，当你跟团队一起做业务时，多巴胺分泌得更多，更有获得感，那么你可以尝试向开发经理方向发展。当然，你也可能做什么都没有分泌太多的多巴胺，那么，你可以在尝试一段时间后，转型其他职业，例如产品经理。前端作为核心是用户体验，与用户最近的工程师，转型产品经理，阻碍会小一些。况且，文艺型前端布道人豆瓣前端负责人张克军认为，前端工程师正慢慢演变为产品工程师，前端和产品离得确实很近。

当你选择好一个方向后，你就要朝着这个方向一步一步进发。丹尼尔在《一万小时天才理论》提出一万小时定律，即要成为某个领域的专家，需要积累一万小时。当然这只是个概数，不过每天花更多的时间去学习和实践，肯定是最有效的。这里，成为技术专家和开发经理过程中，关注的点略有差别。成长为技术专家，要更多关注技术本身的实现，包括逻辑、架构、设计模式、方法论等；而成长为技术经理，则要更多关注技术开发的过程，考虑如何提高开发效率、降低开发成本、优化开发质量等等。不同的人，精力是有限的，选择性关注一些必要的方面，对自身快速的成长是很有必要的。

做业务还是做架构

做业务，时间要求比较紧，代码质量要求高，可参考的代码比较多，业务知识需要学习。做架构，时间稍微自由，对经验要求比较高，无可参考代码，专业基础知识需要深刻理解；最主要的，做架构的你既是开发，又是用户，还是 PM ，只有 80% - 90% 的明确目标，并在开发过程中不断微调最终的目标。

对于一个新人，其实不用纠结，做业务才是好的选择，而且做 技术含量高、使用流行技术 的业务才是最好的。原因很简单，架构的最终的目的是解决业务当中的问题，你没做过业务，哪能知道业务的问题在哪，你都不知道要解决什么问题，如何做好架构。所以，从业务做起，是新人最好的选择，也是唯一可行的选择。而选择有技术含量、使用流行技术的业务的原因更多在于成长，这样你的成长可能会更快、成长道路可能会更直。当然，这只是『可能』，不同的人适合不同的业务，所以不要强求一定『技术含量高、使用流行技术』的业务，更多的而是改变自己，去 适应团队、适应业务，这样才能 更快地成长。

事实上，很多时候，你会遇到很业务工作很繁重没有额外时间学习的情况。而如何在这样环境中更快地成长呢？说白了就是『抄』，不不，是参考。将学习融入到工作中，是最好的方法。做新项目，参考老项目代码；做新需求，参考老需求的代码；没有同类型的代码，参考别的业务的代码。参考前人的经验，在巨人的肩膀上，成长才会变得更快。同时，你的导师和你的伙伴，也会在业务中给你指点，帮你快速解决成长路上的问题。

导师

在这里，总结一下，在繁重的业务环境下快速成长，你需要 很优秀的学习能力、很持久的耐心 以及 很好的导师和伙伴，这样才能在技术成长的路上事半功倍。

技术的学习

说了半天，到了最核心的问题了，对于一个新人如何学习技术？笔者给的建议是：千万不要囫囵吞枣，先把当前使用的技术学透用熟，才是最重要的；千万不要在还没把当前使用的技术吃透之前，去学新的东西，不管新的东西有多火。就像上文所说，不同的框架，有不同的核心，有不同的思想。两个框架代码相似之处的思想不一定相似，例如 Angular 和 Vue 都有双向绑定，虽然效果相似，但是实现思想和内部实现方式是截然不同的。还在入门阶段的你，会被各种思想充斥头脑，反而会更不清楚。

一定的时间后，当你理解透一个架构体系后，你可以 类比地去看 更多的架构体系。这时候，你会发现不同架构很多东西都是殊途同归，理解得很快。

持续学习

当然，理解透一个架构体系，有人需要一年，有人需要三年，还有人可能需要更长时间。为什么有这么大的区别呢？因为有些人在开发中，并不认为完成就可以了，会在开发中，追求代码的优美，会不断优化自己的代码，让自己的代码性能更好、可读性更高，并通过长时间的积累，达到 量变导致质变 的程度。即使一个特别聪明的人，没有『量』也不可能『质变』的，只不过他的量可能比其他人少而已。

要提醒的一点是，学技术，一定要结合你所在公司、团队的技术栈。例如，去哪儿前端应届生会在进入业务线前，进行3个月的脱产培训，2017年的前端培训课程内容中涉及的技术主要是 React 和 React Native，而去哪儿业务的技术栈也大多是 React，那么作为去哪儿的前端应届生，你优先学习 React 的技术体系是事半功倍的，既有前人可以问，又有项目可以实践。

当然，在学习架构的同时，不要忽略两样最基本的东西，一个是 技术基础，一个是 开发规范。

技术基础是一切开发、架构的前提，没有一个好的基础，是无法让你自身的技术水平达到足够高的维度。例如你对于继承理解的并不透彻，你很难理解清晰 React 的内部实现。

对于开发规范，笔者在带应届生时特别注意让他们遵守。代码规范比比皆是，但是很少有人严格遵守。究其原因，多是在代码规范制定之前，已经有自己的一套代码习惯，很难短时间改变自己的习惯。而应届生，一般来说代码并不多，还没有形成自己的编码习惯。这时候，开始遵守一定的规范，会促使他们养成一个较好的编码习惯，为后续的成长打好基础。下面，列举一下开发规范的几点好处，让大家明白代码规范的重要性：

规范的代码可以促进团队合作。
规范的代码可以减少 Bug 处理。
规范的代码可以降低维护成本。
规范的代码有助于代码审查。
养成代码规范的习惯，有助于程序员自身的成长。

规范

这部分最后，推荐一些学习技术的好地方，例如情封大大三年不停更的《前端早读课》、阿里大漠（不是大漠穷秋）的 w3cplus.com、微信公众号《前端圈》、《前端之巅》、《Node 全栈》，当然还有公司内的《Qunar 技术沙龙》微信公众号，笔者所在团队 YMFE 的博客 blog.ymfe.org 等，都是学习技术的好地方。

主战场 —— 移动混合开发

随着移动浪潮的兴起，业务在移动端App 的需求量迅速扩大，应用迭代更新的频率也随之极速攀升，但与此同时纯 Native 的开发和更新成本成为了业务增长难以逾越的瓶颈。因此，引入一种开发更高效、成本更低的解决方案势在必行。

混合开发

在当前的移动互联网环境下，iOS 和 Android 上的 App 已经成了每个互联网产品的标配。如果一个用户端产品并不提供相应 App 版本，几乎会直接定义成一个不完整的产品。而被互联网人尊为铁律的『唯快不破』—— 快速开发、高速迭代、低成本上线，同时也是移动时代每个开发团队所追求的目标。综合以上两点原因，『Native 搭台，Web 唱戏』的 Hybrid 开发模式，以『快』的特点赢得了大家的青睐，并纷纷投入大量开发力量，使这种开发模式迅速走红。当前最常见的技术架构方案有以下三种：

基于 Web 的 Hybrid 解决方案：例如微信浏览器、各公司的 Hybrid 方案
非基于 Web UI 但业务逻辑基于 JavaScript 的解决方案：例如 React-Native
基于 Web UI，但是为了追求运行效率，对 UI 展现逻辑和业务逻辑的 JavaScript 进行了隔离的解决方案：微信小程序

对于一个前端，笔者感觉每个人必须了解这三种常见方案的实现方式和优缺点，这样才能在开发移动端业务的时候，更为清楚自己所要注意、所要学习的地方。当然，仅仅了解实现方式是不够的，你要有环境去实践你学习的东西。再拿去哪儿为例，去哪儿现在大多数业务都是移动端的，Hybrid 和 RN 方案都在被使用。所以，作为一个应届生，你很有可能去做一些 Hybrid 或者 RN 的项目。做 Hybrid 项目时，你更多要考虑的是『如何高效地操作 Dom』；反之，做 RN 项目，你更多要考虑的则是『如何减少和 Native 的通信』。这两点，最终都会反应在项目的用户体验上。

前端中的『另类』—— Node

对于 Node，作为一个前端，应该并不陌生。Node 最大的卖点在于完全异步的 I/O 模型，相比于阻塞 I/O ，异步 I/O 模型极大提高 Web 服务的并发性。因此，前端都可以自己开发服务端了？

这样认为的同学，笔者只能说，你想多了。Node 是可以开发服务端，但是不代表所有前端都可以使用 Node 去开发一个庞大业务的服务端。你去知乎搜索使用 Node 开发服务端的相关问题，一部分人会说 Node 不能替代之前的服务端语言，另一部分人会说什么也阻挡不了 Node 在服务端的脚步；同时有很多诸如 Paypal、阿里这样大公司大规模使用 Node，也很多公司在落入 Node 深坑而不起。不论争论如何，笔者认为，Node 是否能写服务端，主要在于使用 Node 的人是否有服务端的思想。开发服务端和开发前端是完全不同的思想，服务端更注重效率、更注重稳定、更注重高并发情况下数据的处理，用前端的思想去开发服务端显然是不行的。当然，成功的案例中，Node 也更多运用在页面渲染这一层，配合前端更快的渲染页面，提高用户体验；而复杂的数据逻辑，还是用传统的服务端语言进行开发，毕竟技术成熟、运维成本低。

node

这里，会出现一个问题，我只是前端，需不需要去学习 Node？笔者的答案是需要。前端兴起已经很多年，已经从游击队乱枪打鸟的阶段逐渐变为规模化、工程化的时代。在这个时代中，尤其是在工具和流程方面，Node 起到了很大的作用，扮演很重要的角色。诸如 Webpack、Gulp、NPM 这些工具，他们被运用在各个公司的各类前端项目中。学习 Node 其实就是去学习前端的工具，去学习前端的工程化。

当然，如果你立志是全栈，或者想做服务端的一些工作，再或者想通过 Node 学习服务端的技术和原理，都可以去学习 Node。请相信笔者，你不会失望的。

前端一直在『造轮子』中不断前进

造轮子 的意义是重新实现已有的功能，以达到更好的效果。这个词语，常见于技术圈，尤其是前端圈，逐渐被人贬义地用来『嘲讽』一个重新实现已有功能的工具、框架以及方案。那么，造轮子究竟是怎样一种行为？

首先，笔者并不排斥造轮子，至少有一位大神造轮子造得很成功，那就是 Linus Torvalds。Minix 不好用，就造了一个 Linux；Bitkeeper 停止授权，就造了一个 Git。并且两个新『轮子』已经成为世界上最好的轮子之二。这种创造性的造轮子，是令人赞赏的。

其次，不同的技术体系，互相学习，参考对方的思想，造自己的轮子，也是一个非常好的想法。尤其是前端，它通过学习其他语言、体系的架构方案，丰富自身，短短几年就上升到很高的高度。可以举得列子很多：例如 Angular 的 MVC + DI + IoC 的模式，很多人会直接想到 Java 的 Spring，甚至 Angular 也包含 AOP 的编程思想；再例如 MVVM 双向数据流的模式，本身就是微软的 WPF 首先提出的。轮子可以造，对开发有意义即可。

造轮子

最后，大家 反感造轮子，其实更多在于反感造一个没有任何创新的轮子，还天天到处宣扬自己的产物。你可以自己造一个没有任何创新的轮子，用来学习造轮子的过程，同时这也是深入轮子最好的方式，没有之一。当你了解当前轮子的根本构造之后，你就能在这个基础上进行更多的创新。

其他方面的学习

作为一个前端，最该学习的两个方面是产品和设计。学习产品思维，会帮助你从用户的角度审查你开发的产品，找出用户体验不优、交互不好的地方；而学习设计，则帮助你分析不优的地方的原因，并找出解决方案。当然，每个人的精力有限，不可能把这两个方面学得特别深，但最好都要有接触，有一定深度的学习。

深度学习

小总结

前文并没有直接跟大家说明怎么做职业规划，而是从发展方向、技术学习、主要业务场景、NodeJS、造轮子问题等多个方面，来给大家分析：作为前端，哪些需要做、哪些不需要做、哪些必须做、哪些可以做。大家可以根据自己的兴趣、能力等特性，并且和自己在公司所做的项目结合，决定做哪些、不做哪些、强制自己做哪些、有空余时间做哪些等等类似的决定。这里可以举个例子，例如：我的目标是成为一个技术专家，因此，我要深植业务一到两年，严格控制自己的代码规范，深入了解 React 体系，在移动端主攻 React Native，而且有时间看 Node 及 Babel 相关工具，目标是彻底理解 React 的技术实现和 Web Component 的开发思想。当你有这样一个目标时，你可以清楚知道自己做事的目的，可以清晰看到自己的成长。

要注意的是，如果你已经有工作的话，你的职业规划绝对不能脱离你现在的工作。实践出真知，工作带给你的实践环境，才是你成长的营养来源。

前端的未来

对于前端的未来，或者说是互联网技术的未来，我比较认同阮一峰老师的一个观点：将来程序员只分为两类，端工程师和 云工程师。端工程师，直面用户，为了用户能更好使用产品而殚精竭虑，包括传统的前端、Native、AR/VR、TV 端开发等；而云工程师，直面数据，将冰冷冷的数据转化为与用户息息相关的产品，包括分布式、大数据、机器学习等等。

前端未来

前端不管演变成什么，它所关注的永远是 用户体验，只不过端增加了，开发的方式也增多了而已。作为一个前端工程师，要时时关注业界动态，更多地学习新技术，提升自己的实力，来适应更大的挑战。

写在最后

作为一个初入前端圈的新人，你或许对上面描述的东西并不完全理解，这没有任何问题。做一个适合自己的职业规划，并不急于一时，其实最好是在工作一段时间后，和你的 leader 或者伙伴们一起对自己做一个评估，并根据前面所讲，给自己制定一个适合自身情况、符合自身兴趣的职业规划，并按照规划一步步不断提高自己，向前方的成功迈进。