1 define(['BusinessModel'], function (Model) { 2 var model = Model.requestModel.getInstance(); model.setParam(); 6 model.execute(function (data) { (data.person && data.person.name) { } }); 17 })

我觉得三端的开发中，前端的业务是最复杂的，因为IOS与Andriod的落地页往往都是首页，而前端的落地页可能是任何页面（产品列表页，订单填写页，订单详情页等），因为用户完全可能把这个url告诉朋友，让朋友直接进入这个产品填写页。

而随着业务发展、需求迭代，前端的页面可能更加复杂，最初稳定的页面承受了来自多方的挑战。这个情况在我们团队大概是这样的：

在第一轮产品做完后，产品马上安排了第二轮迭代，这次迭代的重点是订单填写页，对订单填写有以下需求：

① 新增优惠券功能

② 优惠券在H5站点下默认不使用，在IOS、andriod下默认使用（刚好这个时候IOS还在用H5的页面囧囧囧）

③ 默认自动填入用户上一次的信息（站点常用功能）

这里1、3是正常功能迭代，但是需求2可以说是IOS APP 暂时使用H5站点的页面，因为当时IOS已经招到了足够的人，也正在进行订单填写的开发，事实上一个月以后他们APP便换掉了H5的订单填写，那么这个时候将对应IOS的逻辑写到自己的主逻辑中是非常愚蠢的，而且后续的发展更是超出了所料，因为H5站点的容器变成了：

① IOS APP装载部分H5页面

② Andriod APP装载部分H5页面

PS：这里之所以把andriod和ios分开，因为andriod都开发了20多天了，ios才招到一个人，他们对H5页面的需求完全是两回事囧！

③ 手机百度装载H5页面（基本与H5站点逻辑一致，有一些特殊需求，比如登录、支付需要使用clouda调用apk）

④ 百度地图webview容器

于是整个人就一下傻逼了，因为主逻辑基本相似，总有容器会希望一点特殊需求，从重构角度来说，我们不会希望我们的业务中出现上述代码太多的if else；

从性能优化角度来说，就普通浏览器根本不需要理睬Hybrid交互相关，这个时候我们完善的框架便派上了用场，抽离公共部分了：

H5仍然只关注主逻辑，并且将内部的每部操作尽可能的细化，比如初始化操作，对某一个按钮的点击行为等都应该尽可能的分解到一个个独立的方法中，真实项目大概是这个样子的：

依赖框架自带的继承抽象，以及控制器路由层的按环境加载的机制，可以有效解决此类问题，也有效降低了页面的复杂度，但是他改变不了页面越来越复杂的事实，并且这个时候迎来了第三轮迭代：

① 加入保险功能

② H5站点在某些渠道下默认开启使用优惠券功能（囧囧囧！！！）

③ 限制优惠券必须达到某些条件才能使用

④ 订单填写页作为某一合作方的落地页，请求参数和url有所变化，但是返回的字段一致，交互一致......