一个后端程序员的前端之路

2,572 阅读6分钟
原文链接: mp.weixin.qq.com

早在 2012 的时候我就以一个后端程序员的身份开始复制粘贴修修改改前端程序员写的代码,当时最大的感受就是:果然写前端的都是天马行空恣意妄为,那些跳来跳去的调用和 callback 真的就像完全未经设计随意而出的艺术品,没人能猜得透。于是乎,那是对于写 JavaScript 我其实是拒绝的,因为实在给自己找不到一个哪怕不完美的理由去维护那 shit 一样的的代码。

然而 2013 年上半年,公司没有了前端岗却保留着大量的前端业务,甚至需求比之前更旺盛,迫于形势不得不接管了所有的前端开发。当时的业务已经初具一定规模,非常复杂而且代码量庞大,在原有代码的基础上进行新功能开发和维护是件非常痛苦的事情:

  • 重复逻辑不能复用,只能复制粘贴

  • 调用栈跳跃性强,几乎没有任何规律可言,还常常分布在几个源文件中

  • html 页面充斥着 ejs 模板,命名毫无规则

  • 事件绑定的 dom 直接使用元素名称,一旦页面结构发生微妙变化,事件绑定代码就需要更改

当时我对 JavaScript 的认识还只停留在使用原型进行继承的一种 web 浏览器端语言,虽然那个时候 nodejs 早已经横空出世,backbone 火得不行。但是为了改善我接手前端业务所面临的各种问题,2013 年4月份左右,我开始着手重构公司主要业务的全部前端代码,包括大量 css。

4年前的技术选型

  1. gruntjs 是当时当之无愧的构建工具,用来完成所有前端的编译、打包、压缩、发布等

  2. 鉴于移动端对性能(2013年)以及代码本身可维护性要求,舍弃 ejs 模板,改用字符串拼接

  3. backbone 等 MVC 方案过于复杂,短期内难以掌握,而且不适合公司那种对用户体验要求很高的场景(其实是当时的手机性能普遍不高),因而不引入任何第三方 framework,自己基于 jquery 手动实现一个极简 framework

  4. framework 包括

  • 全局静态变量配置,包括 host,google 分析等

  • 字符拼接的 html 模板

  • 基于 history push state 和 url 修改的简单路由

  • api 请求层,提供请求参数以及响应数据的过滤封装

  • 统一的命名规则和事件处理,事件命名遵循 github 的使用的规则,使用 js-前缀区分事件 dom 和 普通 dom

以当时的能力,重构持续了近一个月,所有页面的 dom 重写,css 重写,css 重写参考和学习了 Jonathan Snook 的 https://smacss.com/。

这套技术选型打磨出的基础架构,支撑公司业务几乎所有产品的前端,包括当时合作的豌豆荚、360 手机助手、百度手机助手、腾讯手机助手等厂家,在之后 2 年之内在公司几乎没有前端的情况下,这套前端的基础架构一直都在各种业务场景和产品中使用。那个时候 react 正在火,angular 已经火了。

为什么没有赶时髦换成 react 或者 angular?

  1. 现有基础架构已经能很好满足业务需求,并且在性能、稳定性、扩展性、维护性都经受了考验

  2. react 当时只是一个 UI framework,适用性有限,生态未形成,也可以说在当时的业务场景中很少会遇到类似 Facebook 遇到的问题,angular 虽然大而全,但学习曲线更陡峭,创业公司人手不足,团队更希望对这些技术可以随时拿得起放得下,angular 显然过于笨重

  3. 在团队遇到的问题都可以使用已有的技术选型解决的情况下,并且在性能、维护性等各个方面都能满足要求,新增技术实体无疑是增加了各方面的成本:人力成本、时间成本、机会成本

众多 framework 中选中 ember 做后台管理系统 CMS

2015 年,公司的内容管理系统越来越复杂,由于参与人数多而且杂,且大部分写 CMS 的人并不是很懂 JavaScript,面向 CMS 的需求又变化多端,经常改变,导致页面的功能经常发生更改而且不易追踪,维护性越来越差。

当时迫切需要一个解决方案来解决 CMS 中的可维护性问题,经过各方面比较权衡最终选择了 emberjs,事实证明这个选择是正确的,参考 为什么选择 emberjs 开发 dashboard 和 CMS 类系统。

emberjs 这 2 年的发展,每次升级都是平滑进行,几乎完全向后兼容,团队几乎可以在第一时间进行升级,享受到新的特性,ember-cli 工具是当前主流 framework (vuejs,reactjs,angular,riot) 中最易用,最高效的,在各自 framework 生态并不完整的情况下,emberjs 可以非常容易使用任何 jquery 的库,因为其本身是基于 jquery 的,得益于此,CMS 中的几乎所有控件在没有精力开发时都能找到完美的替代品,这又得益于 jquery 这近 10 年的发展。

经过大半年的实践,团队出品了几个相关的 ember 的组件:

  • https://github.com/wecatch/ember-semantic-ui 基于 semantic-ui 的组件集

  • https://github.com/wecatch/ember-easy-orm 前端表单、api请求层

  • https://github.com/wecatch/ember-cli-simditor simditor 编辑器

在前端爆发式发展的情形之下,选择似乎是比重新发明还要难的事情,虽然选择一种技术方案有很多理由,但仅仅因为概念新颖、思想超前而缺乏现实考量的选择是对团队甚至公司利益的一种损害。

大胆实践,生产中投入使用 react、vuejs

2016 年业务稳定,团队有更多时间和机会进行的技术探索和扩张,短短不到几个月时间迅速实践和使用了 react 和 vuejs ,不但开拓了思路,某些场景之下生产力显著提高,并生产出一套 react ui 组件集 https://github.com/jerryshew/react-component

变化中的选择

JavaScript 世界的变化速度迅速而且激进,一个特性完全未普及或者经受了考验,又有新的特性出现,面对这样的变化节奏,团队如何做出选择显得至关重要。

回顾这几年对前端技术的选择有几个原则是始终坚持的

  • 长期使用的产品,稳定性和可维护性是第一位,比如构建 CMS 的 emberjs

  • 权衡,引入任何技术都需要以当时团队实际背景以及未来 2-3 年的发展为基础来考虑

  • 选择前期的思考和研究值得投入

虽然在实际的业务中我已经很少在写前端,对 JavaScript 的态度从一开始的拒绝到现在已经渐渐喜欢上这门语言。

虽然我相信一见钟情,但是现实往往都是日久生情。