前端工程师靠什么跳槽？

年底了，又将迎来一波跳槽小高峰。

算下来工作也两年半了，最终还是决定换个环境继续折腾。跳槽的目的无疑是为了更好的发展以及更高的薪酬。然而我并不打算讨论这些“政治问题”，而是想回顾下这些年来，自己在技术上的收获。

一个工作三年的前端应该掌握哪些技术？具备哪些硬技能？

我想每个人情况不同，并没一个标准答案，但确实是一个值得思考的问题。按照某3-5年前端岗位要求，起码应该达到以下几点：

以下几点

1.前端技术基础扎实，熟练掌握 HTML、CSS、Java;

2.熟悉前端框架 React 、Vue.js等，对前端工程化和组件开发有较深的理解；

3.熟练掌握 Web 开发相关知识，至少熟悉一门后端语言，例如Node.js、Java、Go等；

4.对技术有热情，有一定前端架构能力或者技术深度；具备企业级大型前端应用开发经验更佳；

5.团队合作意识强，能够多团队协作开发；

但这其实描述的非常泛，每个人都会在不同领域有所沉淀。而自己的关键字，应该是模块化 + 无线端了，当然还可能有团队协作、沟通、项目管理等一系列能力沉淀，不做展开，本文主要谈技术上的思考。

模块化思考

谈到模块化，不可避免的会涉及到工程化，组件化(相关区别网上很多，不做展开)。只是自己在工作期间写了大量业务模块，所以对模块化思考更多些。而 module 一词，在不同的语境中也会有不同含义，下面从分别从代码工程层面和系统平台层面进行介绍。

代码&工程

代码层面的模块化主要涉及语言规范和代码组织本身。光是对于JS模块化的演进，就可以写上好几篇了，比如CommonJS(NodeJS)、AMD(RequireJS)、CMD(seajs)，相关介绍网上很多，不做展开，所幸现在都用ES6+了。一个模块，可以是一段代码，一个文件，或者一个文件夹，这是代码组织的艺术。无论其形态如何，解决的问题都是一样的：

1.分而治之

牢记这个原则，基本不会出问题，但并不一定优雅，如何分治，如何解耦，如何提高可扩展性同时又不过度设计都需要相当多的经验，另一条需要注意的是：

2.最小适用

这点对无线端开发尤为重要。举个栗子，很多H5页面都会用到zepto，一般都是直接引入整个js，但zepto作为一个完备的工具库(兼具DOM/event/ajax/form/animation...)，可能有些东西我们并不需要，最佳的方式是只用页面中用到的模块即可（比如只用DOM+event），流量寸土寸金，代码也是。

其他的想到了再补充吧，有空可以多看看孙(dai)子(ma)兵(da)法(quan)，不作展开。技术的成长最直接的体现就是代码质量，每个程序员都会有看到自己以前写的代码就感觉xxx一样的想法吧。

系统&平台

代码层面的模块化是面向程序员，系统平台的模块化范围则更广，可能面向程序员，小白用户或者其他系统。

举个栗子，一个系统中可能会有登录模块、鉴权模块、积分模块等等，这些模块继续抽象完备又能形成一个独立的系统，继而开放出平台的能力，为更多用户提供PaaS、FaaS服务(咦？怎么越说越像某公司的套路？)。其实某公司很早很早很早就提出了“大中台，小前台”的组织模式，听起来高大上，在我看来其实就是组织架构层面的“模块化”，沉淀出越来越多的中台能力，驱动快速创新的前台业务，以搭积木的方式去开发系统。这其中要解决的稳定性、扩展性等问题主要偏后端，或许得再过一两年我才能完善这部分。

系统平台领域还有一种直接面向前端用户的模块化：可视化模块。举个栗子，每年双11/双12各种会场页面既不是人肉一个个写的，也不是人工智能自动生成的（或许再过不久有可能），而是前端开发一个个模块（比如头图，标题，商品坑等），运营拖模块搭建会场并进行投放数据而成。

蓦然回首，自己竟有一年多的时间都在弄这个。从源码搭建到模块开发再到一套成熟的协作流程，真是一段辛酸史，我尝试用精炼的文字来概况这类电商动态化运营模式下模块化的要点：

规范化

我见过一些模块，命名随意，也没有文档，基本是在面向自己编程，别人接收时：你直接看代码吧，很简单的。然而这不是一个简不简单的问题，是一个效率问题。代码模块化更多是为了内聚，运营模块化则偏向复用，这是需要长期维护的，自然需要一套支持长期维护的规范，而且这种规范最好一开始就树立好，否则越到后面治理起来越难。

人性化

运营模块不仅面向开发，同时也面向小白运营，我们开放给运营的配置操作一定要清晰明了，足够人性化，各个字段做好足够说明，这样能一定程度上降低运营配置带来的线上风险。

单一职责

模块所承担的职责尽量简单。我曾经犯了一个错误，那就是开发了一个“强大”的商品展示模块，可以支持各种不同形式的商品展示形式。但与之而来的就是配置上的复杂性，不仅给运营增加了配置负担，也提高了出错率。即使是提供同一类功能的模块，也要适度拆分，在复用性和可用性上作出权衡，把问题尽量简单化。

防御式设计

编程中出现的大部分问题，都是来自于意料之外的输入数据，更何况这些数据还出自运营之手。所以对于模块配置项必须要给予schema约束，对数据做好校验和兜底，在代码和平台层面都做好防御式设计。工作中遇到不少案例，因为读取字段为空报错而导致模块不可用，严重的情况整个页面都会挂掉。

开放还是封闭？

这其实是一个模块管理的问题，有这样一个场景：

场景

A部门前端小明开发了一个业务模块并公开在平台上，B部门运营看到后觉得不错就拿来直接用了，小明很开心，觉得自己的模块不仅帮助到了自个儿部门，还帮助到了其他部门！

但故事还有后续，B部门运营在使用模块上遇到问题都会找小明，觉得这里不行得改改，XX能不能调一下...

场景

小明：你们自己的需求找自己部门的开发啊

运营：可是我已经用了你的模块啊

本来是业务定制的模块，开放出去意味考虑更多通用性的东西，以及更大的维护成本，一定要慎重(突然联想到开源)。同时不同使用方之间的模块也要做好隔离，这样运营在选择时可以规避很多误操作。

是否值得模块化？

最后要说的就是不要为了模块化而模块化。很多东西觉得可以模块化，可以沉淀下来下次复用，但到最后你会发现计划永远赶不上变化，真正能复用下来的并不多。本着经济适用即可，切忽考虑过度，你花了大量时间在上面，可能需求后面就被一刀砍了。

以上经验皆源自实战，必然没有某些编程大作中描述完整。以前看书看到类似总结时大呼：我TM怎么不早点看这本书！现在想想，可能早点看也没什么暖用，高内聚，低耦合，可复用，可扩展谁不知道？实践出真知，人只有被打了才知道疼，招聘要求2年以上经验必然是有道理的。

无线端开发

这两年多的时间里基本都在无线端打拼，我很难描述自己究竟学到了哪些干货。HTML5?

CSS3? ES6+? Webpack? Vue.js? React? Weex?

这些东西谁都会，没啥好说的。这两年前端的工程化和组件化体系也都完善起来了，自己只能算是一个见证者，多去看看大佬们的总结会比较好。唯一想总结的，就是坚定了未来的方向。曾经有Native/hybrid/Web多种技术方案，一开始我是一个坚定的Web理想主义，觉得随着技术的发展Web性能终将不是问题，后来用了Weex后发现性能确实甩Web一大截，既具备Native的性能又有Native的设备能力。然而用的越深，发现这种方案的问题越多，很多细节上是无法处理好的，在产品上不得不做出妥协。后来又看了天猫超市Mobile Web的极致体验优化和业内一些分享，发现走Web路线也是可以做的很好的，关键点就在于容器的能力。从最近Google和UC的动作来看，会有越来越多的设备能力集成在浏览器内核中，前端开发体验只会越来越好，加上现在Hybrid技术方案已经比较成熟，很可能某些Hybrid中的能力会在未来直接变成浏览器实现标准。

未来技术的发展，必定是将问题变得越来越简单的，如果一项技术的诞生对使用者的要求变得更高，这必定不是一项普惠性的技术。

先写这么多吧，这三年的收获，或许最大的并不在技术本身，而是工作习惯和思考问题的方法，正如 Kent Beck 所说，

Kent Beck

“I'm not a great programmer; I'm just a good programmer with great habits.”

对于我们普通人而言，更重要的是养成好的工作习惯。而身边有一群优秀的人，就会潜移默化的感染你，与优秀的人一起共事，也会让自己变得更优秀