滴滴：WebApp实践经验总结
beiz7387
8年前
<p>本文为滴滴公共FE团队在WebApp方向的一些实践经验总结，主要内容包括：WebApp首页技术架构、前端工程化在WebApp的实践、通用地图JS库的设计和实践、 统一登录SDK的设计、通用客户端JSBridge的封装、在公共部门做通用服务的一些感悟、个人成长总结。</p> <h2>1. WebApp首页技术架构</h2> <h3>需求分析</h3> <p>（1）滴滴多条业务线在一个 WebApp 页面里运行，业务线之间互不影响。</p> <p>（2）业务线发单流程基本一致，部分业务线支持自定义化。</p> <p>（3）业务线可以独立自主迭代上线，不需要公共团队的参与。</p> <p>（4）新业务线可以快速接入首页。</p> <h3>解决方案</h3> <p>（1）每个业务线提供自已的 biz.js，首页加载的时候会异步请求这些 JS 文件。</p> <p>（2）公共提供全局的 dd.registerBiz(option) 方法，供业务线 biz.js 调用，同时在 option 里提供 init、onEnter、onExit、orderRecover 等钩子函数，业务线的代码通过调用 dd.registerBiz 方法完成接入。</p> <p>（3）把页面拆分成多个区块，有一些公共区块如一级导航菜单和地址选择区块；也有一些业务线区块如 ETA 区块、发单区块、自定义区块等。公共会在业务线区块下根据 registerBiz 注册的业务线动态创建业务线独立的子区块，业务线可以填充这些子区块的 DOM，公共这边提供通用的样式。创建业务线区块的时候完毕会调用 init 钩子函数，业务线可以在这个函数里做一些初始化操作。</p> <p>（4）公共负责管理业务线的切换，来控制每个业务线子区块的 show 和 hide，这些细节业务线不用关心。在切入的时候会调用 onEnter 钩子函数，切出的时候会调用 onExit 钩子函数。</p> <p>（5）公共会提供业务线一些公共方法调用，比如统一的 sendOrder 发单方法。还会通过事件机制和业务线通讯，比如当公共定位完成会调用 events.emit('location.suceess',posInfo) 派发事件，业务线可以监听该事件拿到定位信息。</p> <p>（6）公共会提供一些封装好的通用组件，供业务线调用。</p> <p>（7）业务线的 biz.js 地址是通过服务端渲染前端模板的时候通过变量传到模板里的，这个 JS 地址业务线可以自主配置，达到业务线自主上线的目的。</p> <p>（8）新业务线的接入只需要提供业务线 biz.js，实现 dd.registerBiz 接口。公共不用关心具体接入的业务线，与业务线这边完全解耦。公共这边还提供了一套完整的 Wiki，方便业务线接入。</p> <h3>技术栈</h3> <p>（1）scrat 完成模块化 + 构建。</p> <p>（2）zepto + gmu 实现组件化。</p> <p>（3）前端模板 handlebar。</p> <p>（4）combo 服务。</p> <h3>部分代码示例</h3> <p>业务线接入的 biz.js 示例如下：</p> <pre> <code class="language-javascript">dd.registerBiz({ id: 123, _tpl: { // ... }, init: function (ids) { // ... }, onEnter: function () { // ... }, onExit: function() { // ... } });</code></pre> <h2>2. 前端工程化在WebApp的实践</h2> <h3>需求分析</h3> <p>（1）支持模块化开发，包括 JS 和 CSS。</p> <p>（2）组件化开发。一个组件的 JS、CSS、模板放在一个目录，方便维护。</p> <p>（3）多个项目按项目名称 + 版本部署，采用非覆盖式发布。</p> <p>（4）允许第三方引用项目公共模块。</p> <p>（5）要支持 CSS 预处理器，前端模板。</p> <p>（6）与公司的 jenkis 发布平台配合，上线方便。</p> <p>（7）前后端分离，前端可以独立自主上线。</p> <h3>解决方案</h3> <p>（1）使用 <a href="/misc/goto?guid=4959653887670485645" rel="nofollow,noindex">scrat</a> 做前端工程化工具，完美支持上述需求分析中的前五条需求。</p> <p>（2）每个项目用一个 git 的 repo 维护，然后有专门上线的2个 repo，一个存储静态资源，另一个存储页面模板。每个项目有一个shell脚本，脚本通过 scrat 编译当前项目，把编译后的结果分别 push 到上线的 repo。然后上线的 2 个 repo 关联公司的 jenkis 平台发布上线。</p> <p>（3）每个项目迭代上线前修改版本号，所有静态资源都会增量发布。上线过程先全量上线静态资源，线上模板仍然指向旧的资源，不会有任何问题。然后再上线模板，先上到预发布环境让 qa 回归，回归完后再全量上线模板，完成整个上线流程。</p> <h3>部分代码示例</h3> <p>一个WebApp项目的目录结构如下：</p> <pre> <code class="language-javascript">project |- component_modules（生态模块） |- components （工程模块） |- views （非模块资源） |- component.json （模块化资源描述文件） |- fis-conf.js （构建工具配置文件） |- package.json （项目描述文件） |- index.html |- …</code></pre> <p>一个组件的目录结构如下：</p> <pre> <code class="language-javascript">components |- header |- header.js |- header.styl |- header.tpl |- logo.png</code></pre> <p>按项目名称 + 版本发布的 fis-conf.js 配置规则如下：</p> <pre> <code class="language-javascript">var meta = require('./package.json'); fis.config.set('name', meta.name); fis.config.set('version', meta.version); // 自定义发布规则 var userRoadMap = [ { reg: /^\/components\/(.*\.tpl)$/i, isHtmlLike: true, release: '/pages/c/${name}/${version}/$1' }, { reg: /^\/pages\/(.*\.tpl)$/, useCache: false, isViews: true, isHtmlLike: true, release: '/pages/${name}/${version}/$1' }, { reg: /^\/pages\/boot\.js$/, useOptimizer: false, }, { reg: /^\/pages\/(.*\.(?:js))$/, useCache: false, isViews: true, url: '/${name}/${version}/$1', release: '/public/${name}/${version}/$1' }, { reg: /^\/pages\/(.*\.(?:html))$/, useCache: false, useOptimizer: false, isViews: true, release: '$1' }, { reg: /^\/pages\/(.*)$/, useSprite: true, isViews: true, url: '/${name}/${version}/$1', release: '/public/${name}/${version}/$1' } ]; var defaultRoadmap = fis.config.get('roadmap.path'); fis.config.set('roadmap.path', userRoadMap.concat(defaultRoadmap));</code></pre> <p>编译后部署的目录结构如下：</p> <pre> <code class="language-javascript">|-public （生成的静态资源目录） |- c |- project |-1.0.0 |- header |- header.css |- header.css.js |- header.js |- home ... |- project |- 1.0.0 |- lib |- index.html |-views （模板目录） |- …</code></pre> <h2>3. 通用地图JS库的设计和实践</h2> <h3>需求分析</h3> <p>（1）支持多种地图、多种地图场景的开发。</p> <p>（2）屏蔽底层地图库（高德、腾讯）的接口差异。</p> <p>（3）实现小车平滑移动。</p> <h3>解决方案</h3> <p>（1）底层对腾讯地图和高德地图分别封装（不会在源码中出现 if(qq){} 风格的代码)，依据 webpack 动态打包成 2 个 JS文件，上游根据需求异步加载 JS ，对外提供同一套编程接口。</p> <p>（2）抽象地图场景的概念，可以通过接口注册一个场景类，在场景中可以操作各种封装好的地图组件和方法，编写业务逻辑，实现需求。</p> <p>（3）小车的平滑移动通过封装地图 SDK 提供的底层 marker，轮询小车坐标点，实现小车平滑移动（CSS3），并把“移动 + 转向 + 移动...”一系列操作抽象出动画队列的概念。</p> <h3>技术栈</h3> <p>（1）原生 JS。</p> <p>（2）webpack 打包。</p> <h3>行程分享实践</h3> <p><img src="https://simg.open-open.com/show/daa4fb19398993b4d86e2f305110d721.png"></p> <p>行程分享这个场景中，有等待接驾、行程中、行程结束等状态，有轨迹，小车平滑移动等功能。我们要做的就是利用通用地图 JS 库暴露的接口去编写行程分享的逻辑。</p> <p>贴一下部分代码，看一下如何去使用封装好的地图 JS 库。</p> <p>我们可以先去写一个行程分享的场景：tripShare.js</p> <pre> <code class="language-javascript">var Map = window.map; var _ = Map.utils._; var inherit = Map.utils.inherit; var api = Map.utils.api; var config = Map.utils.config; var EventEmitter = Map.utils.EventEmitter; var Car = Map.component.Car; var StartPoint = Map.component.StartPoint; var EndPoint = Map.component.EndPoint; var TrackControl = Map.control.TrackControl; var TrafficControl = Map.control.TrafficControl; var TrafficLayer = Map.layer.TrafficLayer; var Polyline = Map.Polyline; function TripShare(map, options) { TripShare._super.call(this); // ... } inherit(TripShare, EventEmitter); TripShare.prototype.begin = function () { // ... }; // ...</code></pre> <p>然后我们这样去注册场景。</p> <pre> <code class="language-javascript">var Map = window.map; var fromlat = 31.17626; var fromlng = 121.425; var tolat = 31.20425; var tolng = 121.40398; Map.ready(function (mapInstance) { var map = mapInstance.createMap('container', {}); var TripShare = require('./tripShare'); var scene = map.scene.register(TripShare, { orderStatus: 1, url: 'xxxx', oid: 'aaaa', pathUrl: 'xxxx' fromlat: fromlat, fromlng: fromlng, tolat: tolat, tolng: tolng, usePath: true }); scene.begin(); scene.on('path.badCase', function(badCase) { // do anything }); });</code></pre> <p>我们可以调用场景的方法，又由于场景继承了 EventEmitter 事件中心，它会通过 trigger 派发事件，我们可以监听这些事件，去做一些事情。</p> <h2>4. 统一登录SDK的设计</h2> <h3>需求分析</h3> <p>（1）滴滴有众多业务线，每个业务线都有独立的域名，需要打通各个WebApp域名的登录态。</p> <p>（2）方便新老业务线、运营活动等页面接入登录。</p> <p>（3）提供简单、友好的接口。</p> <h3>解决方案</h3> <p>（1）与账号部门合作，通过跨域方式访问 passport 域名下的接口。跨域方案是通过 iframe passport 域名下的页面，利用 postmessage 进行通信。登录成功后会在 passport 域名下利用种下 ticket。后端提供判断是否登录的接口，前端请求这个接口的时候会从 passport 域名下读取 ticket 并把它作为请求的参数传给后端，这样一旦用户在 a 域名下登录成功，那么在 b 域名下调用是否登录接口，返回的就是登录成功的结果，这样就打通了多个域名的登录态。</p> <p>（2）封装复杂的登录交互细节，对外提供简单的交互接口。</p> <p>（3）提供完善 Wiki 文档，建立专门的钉钉服务交流群。</p> <h3>技术方案</h3> <p><img src="https://simg.open-open.com/show/f5cd56b917c9b4f59f6348c01deb4358.jpg"></p> <h3>技术栈</h3> <p>（1）原生 JS。</p> <p>（2）webpack 打包。</p> <h2>5. 通用客户端JSBridge的封装</h2> <h3>需求分析</h3> <p>（1）内嵌在滴滴 App 端里的页面，需要通过 JSBrigde 的方式获取端的一些能力。</p> <p>（2）屏蔽 iOS 端和 Android 端的一些底层通讯差异。</p> <p>（3）提供简单、友好的接口。</p> <h3>解决方案</h3> <p>（1）对 iOS 和 Anroid 的交互接口进一层封装，所有需要与端通讯的接口封装成 DDBridge.funcName(options,callback) 的方式。</p> <p>（2）对端的一些具象接口，比如分享微信、分享微博等做更高级封装，提供share接口，通过参数指定分享到不同的渠道。</p> <p>（3）提供完善 Wiki 文档，建立专门的钉钉服务交流群。</p> <h3>技术栈</h3> <p>（1）ES6 + eslint。</p> <p>（2）webpack 打包。</p> <h3>部分代码示例：</h3> <pre> <code class="language-javascript">export function initGlobalAPI(DDBridge) { each(config.api, (conf, name) => { DDBridge[name] = makeBridgeFn(conf); DDBridge[name].support = conf.support; }); initSupport(DDBridge); initVersion(DDBridge); initShare(DDBridge); initPay(DDBridge); }; export function makeBridgeFn(conf) { return function (param = '', callback = noop) { if (arguments.length === 1 && isFn(param)) { callback = param; param = ''; } let fn = conf.fn; if (supportPrompt) { promptSend(fn, param, callback); } else { bridgeReady((bridge) => { bridge.callHandler(fn, param, (data) => { if (isStr(data)) { data = JSON.parse(data); } callback(data); }); }); } }; };</code></pre> <h2>6.在公共部门做通用服务的一些感悟</h2> <p>入职滴滴一年，造了不少公司级别的“轮子”，不少轮子已经在业务线跑起来了，运行状况还算可以。我也总结了做通用服务要注意的几点。</p> <p>（1）一定要好用，用起来要简单。</p> <p>这是我一直贯彻的理念，如果通用服务不好用，那一定会受到质疑和吐槽。同样我们用开源的框架，也一定会选简单好用的，当年 jQuery，prototype，tangram 等 JS 库百家争鸣的时候，jQuery笑到了最后，为什么呢？很简单：jQuery好用啊，一个 $(xxx) 搞定一切。相比 tangram 那种 Baidu.T.createDom() 的方式，高下立判。</p> <p>我们在设计通用 JS 库的时候，一定要站在更高的角度去对需求做抽象。比如在设计统一登录 SDK，首先要想的不是复杂的交互逻辑、如何去实现、有哪些技术难点，而是去想，别人怎么用这个库，怎么用起来爽。登录的需求就是用户触发一个登录动作，登录完成能拿到用户一些信息，所以我就设计一个login(callback)接口，那么使用方只需要简单调用这个方法，就可以完成登录需求，而不用去关心登录各种复杂的细节。</p> <p>（2）该做封装的地方要封装，对外暴露的接口越少越好。</p> <p>封装很重要，举个通俗的例子，有一天我去洗手，发现水龙头的开关把手没了，把原始的开关暴露给我了，虽然也能用，但是体验就会很不好。水龙头的开关把手就是对原始开关的封装。我在做 JSBridge 库 的时候，也是一样的道理，如果让用户直接调用 iOS 和 Andrid 提供的原生 bridge 接口的，也能 work，但是非常难用，需要判断 iOS 和 Android 接口的差异，还需要考虑 bridge ready 事件后才能执行方法等，这些都是我原本不需要关心的细节。所以我们的库就是帮助用户封装掉这些“脏活”，对外提供简单的 DDBridge.funcName(options,callback) 接口，优化使用体验。</p> <p>为什么说对外暴露的接口越少越好，因为接口越多，则说明用户的学习成本越高，比如如火如荼的 Vue.js，其1.x 版本很多接口的功能大同小异，所以在 2.0 版本的 Vue 就干掉了很多接口，减少了用户的学习成本。同样的，我们在做 JSBridge 分享接口相关的时候，也通过一个share接口封装了端提供的微信分享、支付宝分享、微博分享等接口。</p> <p>（3）先思考再动手，设计合理的代码组织方式。</p> <p>在写代码之前，一定要先思考清楚，切忌上来就写代码，那样很容易写成一波流代码。合理的代码组织方式，有利于代码的扩展和维护，最基本的就是模块化。这里没有银弹，需要大量的实践和总结，学会抽象的看问题，看一些设计模式相关多书籍，多看优秀的开源的代码，可以先从模仿开始。</p> <p>由于我们写的是通用服务，用户也可能会提出各种需求，当遇到这个问题的时候，不能上来就写代码去实现甚至hack，而是先思考这个需求是不是可以抽象成通用的需求，如果不能抽象，我们如何更优雅的实现，之前的设计是不是有问题。总之，要多想多思考，也可以和小伙伴讨论，争取做到是在设计代码而不是堆代码。</p> <p>（4）追求体验极致。</p> <p>现在很多前端都在玩 Node，玩构建工具，玩 MVVM 框架，玩 ES6，好像感觉学会了这些就可以提高身价。其实，这些大部分都是工具，是服务我们平时工作的，不要忘了我们的本行还是前端，还是需要写页面的。其实前端有些组件和效果如果想要追求体验极致的话，也不容易。如果能做到极致，身价也不会低。举个例子，我在写 mofang 移动端组件的时候，有个筛选器组件 picker，类似 iOS 原生 UIPickerView 的东东，我当时拿到需求的时候，也从 GitHub 上搜索过，没有满意的，体验都很一般，于是我就对比 iOS 原生的 UIPickerView的体验，思考它的实现、一点点细节的调试，最终也撸出来体验几乎一致的移动端 H5 picker 组件。举这个例子其实想说明，我们在做通用服务的时候，要多花心思，如果能做出一些极致体验的东东，不仅对用户来说他们很乐意使用，对自己也是一种锻炼。</p> <p>（5）一定要写 Wiki。</p> <p>要写 Wiki！要写 Wiki!要写 Wiki！重要的事情说 3 遍。由于我们做通用服务，免不了和用户打交道，Wiki 就尤为重要了。我们需要把通用服务的接口，使用方式，常见问题等都写清楚。好的文档可以很好的指导用户如何使用我们的服务，这样可以大大的减少沟通成本，节约我们自身和用户的时间。</p> <p>（6）要学会销售。</p> <p>有些人可能会觉得写通用服务似乎比做业务的同学更高大上，其实不然，本质上我们都是在为公司打工，都是在输出自己的价值，只是做事的重心不同。那么做公共的同学的价值在哪里？就是让自己写的通用服务被更多的人用，去提升他们的工作效率。所以，我们要学会销售自己的服务，而不是写完一个的服务摆出一副你爱用不用的态度。如果你写出来的东西没人用，就算它再牛逼，对公司的价值也是 0。另外，我们还要学会从业务中去沉淀服务，要去发现业务中的痛点，可以提升效率的地方，然后用技术的手段和工具去解决它。</p> <p>（7）一颗服务的心。</p> <p>做公共的同学一定要有颗服务的心。我们售卖的是自己的服务，那么也一定要做好售后服务，除了 Wiki，各种沟通钉钉微信沟通群也要积极响应，耐心的去帮助用户解决问题，其实很多时候，都是靠着用户去帮我们去发现 Bug ，完善功能和优化体验的。</p> <h2>7.谈下我的个人成长</h2> <p>我入前端这行已经4年了，在学校的时候我是玩 .net 的，喜欢折腾。毕业后当然和大部分应届生一样，渴望进 BAT 这样的大公司，不过 BAT 几乎不招 .net 的岗位。由于我读研的时候做过一些网站方向的开发，所以就投了百度的一个相近的职位——Web前端开发。这里我要特别感谢我百度的mentor张袁炜，他是一个对技术要求很高的人，受他的影响，我也成为一个对技术有追求的人。四年来，我写过页面，写过网页游戏、写过Chrome插件、写过框架、写过组件、写过服务，由于一直在做不同的东西，每一年我都有所收获。</p> <p>兴趣导向，有的时候我感觉写代码和玩游戏是一样爽的事情，我也很喜欢看优秀的开源作品，看看他们的代码设计、技术细节，会吸收一些不错的东西到自己平时的工作中。</p> <p>前端这几年发展很快，新技术层出不穷，有的时候，我们要跳出自己的舒适圈，接纳一些新事物，新技术，去让自己不断学习，而不是满足于自己已掌握的那些技术。这里我不是去倡导滥用新技术，而是要保持一颗学习的心态，一颗包容的心态。</p> <p> </p> <p>来自：http://www.infoq.com/cn/articles/webapp-practical-experience-summary</p> <p> </p>