年终跳槽小结-前端篇

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

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

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

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

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

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

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

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

5.团队合做意识强，可以多团队协做开发；

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

模块化思考

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

代码&工程

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

• 分而治之

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

• 最小适用

这点对无线端开发尤其重要。举个栗子，不少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 所说，

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

对于咱们普通人而言，更重要的是养成好的工做习惯。而身边有一群优秀的人，就会潜移默化的感染你，与优秀的人一块儿共事，也会让本身变得更优秀。而如今的你就有这样一个机会：

支付宝招前端啦！
支付宝招前端啦！
支付宝招前端啦！

这边有平台，有空间，有大牛，然而遗憾的是缺人才！年末了，正是一个好机会，咱们的招聘要求也很简单：

• 牛逼

不要被上面岗位描述的条条框框限制了，中国人都很谦虚，只要以为本身能够的就简历私我，反正不吃亏。暂时不打算换工做的也不要紧，能够先交个朋友嘛，之后有的是机会~

邮箱：liquanfeng326 @ iCloud.com以上，感谢 (..›ᴗ‹..)