|
这篇是我参加QCon北京2014的演讲内容：
提纲：
企业应用在软件行业中占有很大的比重，而这类软件多数现在也都采用B/S的模式开发，在这个日新月异的时代，它们的前端开发技术找到了什么改进点呢？
B/S企业软件前端开发模式大体上与桌面软件类似，都是偏重量级的，在前端可能会有较多的业务逻辑，这些业务逻辑如何被合理模块化，与界面分离，以便测试，成为这个领域的一个重要挑战。另一方面，由于企业应用的界面相对规整，偏重的是数据存取，没有太多花哨的东西，所以常见的界面控件也是可枚举的，如何让开发界面的工作能更快完成，甚至由不擅长编写代码的业务设计人员来做，与界面原型的工作合二为一，能提高不少开发效率。
在AngularJS等MV*框架出现之后，给这个领域带来一些契机，架构师们能够有机会去重新规划前端的架构，甚至是开发流程，从而让整个软件的生产更为高效。
本文将探讨它给这个领域带来的变化。
正文：
企业应用前端的特点
企业应用系统是一种很常见的软件系统，这类系统的特点是面向某个行业，功能较复杂，对界面的要求一般是整齐，不追求花哨。这类系统通常有C/S和B/S两个流派，其中的B/S方式因为部署和集成的便利，使用得较为普遍。
同样是在浏览器中做东西，写企业应用和网站的差别也很明显。企业应用的业务逻辑较重，前端有一定的厚重性，但是对效果并不追求很多，主要是各类控件的使用，表单的存取值等等。
企业应用产品的一些特点如下：
独占模式——一般用户使用互联网产品，都是片段时间使用，比如购物或者阅读，做完之后就刷新或者关闭浏览器了，而企业应用往往是工作的全部，从早上上班开始打开，到下班才关掉，一天绝大部分工作都在上面完成，比如一个呼叫中心的操作员。
重业务，轻视觉——企业应用对视觉的追求是比较低的，一般不会要求花哨效果，以业务操作的流畅性为第一目标。
界面规整，单一模式——企业应用的界面布局相对有模式可循，可以用很少的场景来穷举，界面横平竖直，比较规整，使用到的控件元素也是可穷举的，基本没有什么特效。
键盘操作——由于企业应用的用户都相对比较专业，在上岗之前需要经过统一培训，而且每个用户使用的频度较高，很多时候他们会用尽量快捷的方式来做操作，比如键盘，这一点在互联网产品中比较少见。所以，有时候大家为了追求好看，把系统原生的select用div来替换，在这种情况下反而增加了用户的麻烦。
逻辑复杂——我之前所在的行业中，业务逻辑很复杂，前端可能会需要写很多复杂的逻辑，JS代码大部分是在处理逻辑，而不是界面交互。
加载速度的侧重不同——互联网产品往往很重视首屏优化，但是其策略可能与企业应用不同。比如说，3个200k的模块，在网站型产品中可能优化成一个100k加三个150k的模块，但在企业应用中，很可能优化成一个400k加三个50k的模块。为什么会这样呢？因为内容型的网站讲究的优化策略是分摊，如果首次加载太慢，会很影响用户的信心，但企业应用用户的容忍度是较高的，他并不在乎刚打开的时候慢一些，因为打开了之后就要用一天，对于之后每步操作的模块加载速度倒是要求很高。另外，对于内存泄露的处理，也要求得比较高一些。整个这些策略，其实是来源于C/S系统的影响。
浏览器版本相对宽松——很多时候提到企业应用，大家的想法就是低端，IE6，但其实这个的原因是客户只购买软件，运维一般自己做，每年不会有很多持续的投入来改进，所以导致很多老系统不能持续升级。软件厂商其实反倒可以用更激进的策略去升级浏览器，用户对这个的接受度还是比较高的，使用系统的群体也是比互联网用户小很多的，抛弃老旧浏览器的事情也确实可以干，比如我就见过几年前某电信营业系统预装的都是Firefox。
企业应用常见的前端框架
在开发B/S企业应用前端的人群中，有很大一部分群体选择了服务端的组件化方式，比如JSF之类，它的弊端是与异构服务端的第三方系统集成比较麻烦。也有不少人使用Bindows和ExtJS这样的框架，最近的KendoUI也是个不错的选择。
每种类型选一个有代表性的来说说：
HTC 在浏览器端扩展标签——早期有些团队采用的方式，一般会跟XMLHTTP等结合使用，易于使用，界面代码整洁，但已被主流浏览器抛弃。
JSF等
在服务端生成界面——以后端为主的架构师最推崇的方式，受Struts的MVC模型影响很深，弱化了前端，使得前端蜕化为后端的一种附属。
GWT 编译阶段生成界面——写其他语言来生成HTML和JS，一般会依赖于一种前端UI库。这种方式也比较受后端架构师喜欢，因为他们觉得写JS很头疼，宁可写Java。
ExtJS 用JS封装界面组件，干脆就不要HTML了——这是另外一种极端，从Bindows开始，使用纯逻辑代码来描述界面，走着跟Java Swing一样的道路，也有不少人喜欢。但这种方式在没有好用的界面设计器的情况下非常痛苦。
Flex等 脱离HTML体系，另辟蹊径——这条路其实是对Java Applet的一种延续，好处是可以不受HTML体系的制约，独立发展，所以其实这些体系在企业应用领域的成熟度远超HTML体系。
曾经的企业B/S应用几件宝
有一段时间，我们几乎只有IE6，所以那个时候的前端开发人员很快乐，没有兼容的压力。那时候，我们如何构建前端应用呢？参见这里的分享。
HTC——这是最好用的声明控件的方式。
XMLHTTP——尽管还没有AJAX的概念，但我们已经可以用它做前后端分离的传输机制了。
VML——在IE里面画矢量图，不使用插件，有其他选择吗？
XSLT——把XML数据转换成HTML，跟现在的前端模板像吗？
popup——创建右键菜单最好的方式。
具体实例请参考用这些技术构建的一个典型企业应用。
单页应用和前端分层
当时这些系统的构建方式也可以算单页应用，我们用iframe来集成菜单，每个菜单有自己独立的功能，整个主界面是始终不会刷新的。
时光飞逝，这些年，前端有了什么本质的改变，产生了翻天覆地的变化吗？有时候我们回顾一下，却发现多数都是在增加完善一些细节，真正有颠覆性的有比如以RequireJS和SeaJS为代表的模块定义和加载库，npm这样的包管理器，grunt，gulp，百度fis这样的集成开发模式。为什么它们算是本质改进呢？因为这些标志着前端开发从粗放的模式，逐渐变化到精确控制的形态。比如我们再也不能不管代码的依赖关系，也不能一打开界面就不分青红皂白把所有可能要用到的代码都立刻加载过来，那个时代已经过去了，从任何角度讲，现代的前端开发都在精细化，从代码的可控，到界面体验的精细优化，到整个团队甚至公司甚至互联网上的组件共享，以及前端团队协作流程的改进，这已经是一个很成规模的产业了。
我们把眼光放到2013年，在这一年里最火的前端技术莫过于NodeJS和AngularJS，前者给我们带来的是一种开发方式的改变，后者是一种典型的前端分层方案。Angular是前端MV*框架的一个流派，用过的人都会觉得很爽。它爽在什么地方呢？因为它帮我们做的事情太多了，一个双向绑定，无所不包，凡是存取值相关的操作，基本都不用自己写代码。在企业应用前端功能里，表单的存取值和校验占据了很大的比例，这些事都不用干了，那简直太好了。如果就因为这个用Angular，那还有些早。有一些第三方代码被称为库，另外一些称为框架，Angular是框架而不是库。框架的含义是，有更强的约束性，并非作为辅助功能来提供的。
先看一下企业应用的通常形态吧，会有一个可配置的菜单，然后多半会采用MDI的形式，能打开多个业务功能，用选项卡的形式展示起来，可以随时切换操作。每个人每天常用的功能是可以穷举的，他进入系统之后，一般要用到下班才关掉。所以这种系统非常适合做成单页应用，开始的时候加载一个总体框架，每点击一个菜单，就加载这个菜单对应的功能模块，放在一个新的选项卡或者别的什么地方展示出来。
在早期做这种系统的时候，一般都会用iframe来集成菜单，这种方式很方便，但是每个菜单页都要载入共同的框架文件，初始化一个环境，数据之间也不能精确共用。所以现在我们做企业信息系统，不再适合用iframe来集成菜单，所有菜单的业务代码，会在同一个页面的作用域中共存。这在某些方面是便利，比如数据的共享，一个选择全国城市的下拉框，在多个功能中都存在，意味着这些城市的数据我们可以只加载一次。但从另外一个角度来说，也是一种挑战，因为数据之间产生干扰的可能性大大增加了。
我们回顾一下在传统的客户端开发中是怎么做的，早在经典的《设计模式》一书中，就提到了MVC模式，这是一种典型的分层模式。长期以来，在Web开发人员心中的MVC，指的都是Struts框架的那张图，但我们单页应用中的MVC，其实更接近最原始的《设计模式》书中概念。所以我们要在前端分层，而不仅仅把整个前端都推到视图层。
做单页应用，前端不分层是很难办的，当规模扩大的时候，很难处理其中一些隐患。分层更重要的好处是能够从全盘考虑一些东西，比如说数据的共享。跨模块的数据共享是一个比较复杂的话题，搞得不好就会导致不一致的情况，如果考虑到在分层的情况下，把各种数据来源都统一维护，就好办多了。
所以，以AngularJS为代表的前端MV*框架最重要的工作就是做了这些对于分层的指导和约束性工作，在此基础上，我们可以进一步优化单页应用这类产品。
前端的自定义标签体系
构建一个大型企业应用，最重要的是建立整套组件体系。一般针对某行业的软件，长期下来都会有很多固定的模式，可以提炼成组件和规则，从前端来看，体现为控件库和前端逻辑。控件库这个是老生常谈，在很多框架里都有这个概念，但各自对应的机制是不同的。
从写一个界面的角度来讲，最为便利的方式是基于标签的声明式代码，比如我们常见的HTML，还有微软的XAML，Flex中的MXML等，都很直接，设想一下在没有可视化IDE的情况用类似Java Swing和微软WinForm这样的方式编写界面，毫无疑问写XML的方式更易被接受。所以，我们可以得出初步的结论，界面的部分应该写标签。
很遗憾，HTML自带的标签是不足的，它有基本表单输入控件，但是缺乏DataGrid，Tree之类更富有表现性的控件。所以绝大多数界面库，都采用某种使用JavaScript的方式来编写这类控件，比如：
<div id="tabs">
<ul>
<li><a href="#tabs-1">Nunc tincidunt</a></li>
<li><a href="#tabs-2">Proin dolor</a></li>
<li><a href="#tabs-3">Aenean lacinia</a></li>
</ul>
<div id="tabs-1">
</div>
<div id="tabs-2">
</div>
<div id="tabs-3">
</div>
</div>
$(function() {
$( "#tabs" ).tabs();
}); |
如果这样，这些复杂控件就都要通过JavaScript来创建和渲染了，这与我们刚才提到的原则是违背的。那我们寻找的是什么呢，是一种能扩展已有HTML体系的东西。在早期，IE浏览器中有HTC，可以通过引入命名空间来声明组件，现在的标准浏览器中又引入了Web Components，在Polymer这个框架中可以看到更多的细节。说到底，这类方式要做些什么事情呢？
隔离组件的实现，让使用变得简单
支持自行扩展新的组件
作一些作用域上的隔离，比如Web Components里面，style标签上可以加作用域，表示这个样式只生效于组件内部
从另外一个角度讲，为什么我们非要这么做不可？最大好处来自哪里？对于大型项目而言，管理成本和变更成本都是需要认真考虑的。如果一个组件，需要在DOM中声明一个节点， 然后再用一个js去获取DOM，把DOM渲染出来，再填充数据的话，这个过程的管理成本是很大的，因为HTML和JS这两个部分丢了一个都会有问题，无论在什么时候，维护一个文件总是比维护多个文件要强的，我们看HTC那种方式，为什么它的使用成本很低，因为它可以把控件自身的DOM、逻辑、样式全部写在自己内部，整个一个文件被人引用就可以了。在现在这个阶段不存在这么好用的技术了，只能退而求其次。
所以，在这个点上，Angular带来的好处是可扩展的标签体系，这也就是标签的语义化。Angular的主打功能之一是指令，使用这种方式，可以很容易扩展标签或者属性。比如，业务开发人员可以直接写：
<panel>
<tree data="{{data}}"></tree>
</panel> |
这样多么直观，而且可以跟原有的HTML代码一起编写，不造成任何负担。语义化的标签是快速编写界面的不二法门。
业务逻辑
有了语义化标签之后，如果我们只写界面不写逻辑，那也够了，但现实往往没有这么美好，我们还要来考虑一下业务逻辑怎么办。
企业应用一般都是面向某行业的，在这个行业内部，会有一些约定俗成的业务模型和流程，这些东西如何复用，一直是一个难题。以往的做法，会把这些东西都放在服务端，用类似Java这样的语言来实现业务元素、业务规则和业务流程的管理。这种做法所带来的一个缺点就是对界面层的忽视，因为他只把界面层当作展示，对其中可能出现的大量JavaScript逻辑感到无所适从。很多从事这一领域的架构师不认同界面层的厚度，他们认为这一层只应当是很薄的，纯展示相关的，但在这个时代，已经不存在真正轻量级的界面了。
前面提到，我们在前端作分层，把展现层跟业务逻辑层完全隔离，带来的好处就是逻辑层不存在对DOM的操作，只有纯粹的逻辑和远程调用，这么一来，这一层的东西都可以很容易做测试。对于一个大型产品来说，持续集成是很有必要的，自动化测试是持续集成中不可缺少的一环。如果不做分层，这个测试可能就比较难做，现在我们能把容易的先做掉，而且纯逻辑的代码，还可以用更快的方式来测试。
之前我们做前端的单元测试，都需要把代码加载到浏览器来执行，或者自行封装一些“无头浏览器”，也就是不打开实际的展示，模拟这个测试过程。这个过程相对来说还是有些慢，因为它还有加载的这个网络传输的过程，如果我们能在服务端做这个事情呢？我们看到，最近很火的NodeJS，它从很多方面给了前端工程师一个机会，去更多地把控整个开发流程，在我们这个场景下，如果能把针对前端逻辑的单元测试都放在node里做，那效率就会更高。
二次开发平台
我们来看看，有了这么一套分层机制，又有了界面标签库之后，该做些什么呢？做企业软件的公司，有不少会做二次开发平台，这个平台的目标是整合一些已有的行业组件，让业务开发人员甚至是不懂技术的业务人员通过简单的拖拉、配置的形式，组合生成新的业务功能。
从界面的角度看，拖拽生成很容易，很多界面原型工具都可以做，但要如何整合数据和业务？因为你要生成的这个功能，是实实在在要拿去用，不是有个样子看就可以，所以要能跟真实数据结合起来。 但这事情谈何容易！就比如说，界面上有一个选择所属行业的下拉框，里面数据是配置出来的，对这个数据的查询操作在后端，作为一个查询服务或者是业务对象管理起来，有些传统的方式可能是在后端作这个关联，Angular框架可以把这个事情推到前端来。相比Backbone这样的框架来说，Angular由于有双向绑定，这个过程会变得特别省事。一个界面片段想要和数据关联起来，要做的事情就是各种属性的设置，所以动态加载和动态绑定都会比较容易。
比如：
partial.html
<ul>
<li ng-repeat="item in items">{{item.name}}</li>
</ul> |
main.html
...
<div ng-include="'partial.html'" ng-controller="CtrlA"></div>
... |
a.js
function CtrlA($scope) {
$scope.items = [{name:"Tom"}, {name:"Jerry"}];
} |
b.js
function CtrlB($scope) {
$scope.items = [{name:"Donald"}, {name:"Micky"}];
} |
在上面的例子里，这个列表显示什么，完全取决于ng-controller="CtrlA"这句，如果我们把这句搞成配置的，就很容易把数据源换成另外一个CtrlB，甚至说，即使在同一版本上做项目化，引入另外一个包含CtrlA其他版本的js文件，也基本无需更改其他代码，这就达到了二次开发的一个目的：尽可能以配置而不是编码去新增、维护新功能。
移动开发
现在的企业软件已经不能只考虑PC的浏览器了，很多客户都会有移动办公的需求。响应式设计是一种常见的解决方案，但是在企业应用领域，想要把复杂的业务功能设计成响应式界面的代价太大了，况且界面设计本身就是开发企业软件的这些公司的短板，所以我们的比较简单的办法是对PC和移动终端单独设计界面，这样就有了一个问题了，这两种界面的业务逻辑并没有差别，如果我们要维护两套代码，代价是非常大的，能有什么办法共用一些东西呢？
如果不采用分层的形式，那这个很麻烦，我们注意到两种系统的差异只在UI层，如果我们用分层的模式，可以共用UI层以外的东西。具体到Angular里面来说，比如service，factory，甚至controller都是可以共用的，只有directive和HTML模板随设备产生差异就可以了。
之前我们很少看到有基于Angular的移动端开发框架，但现在有了，比如Ionic，使用这样的框架，可以直接引用已有的业务逻辑代码，只在展示上作一些调整。这么做有很多好处，同时也对代码的架构水准有一定要求，需要把业务逻辑跟界面展示完全切割开。
这样带来的好处也是很明显的，独立的业务逻辑，因为它不依赖于界面了，所以很容易控制，做单元测试，集成测试，打桩等等，总之它是纯逻辑的东西，在后端可以用什么方式保证代码质量，在前端的业务逻辑也一样可以用，业务逻辑可以因此而清晰稳定。对于企业应用而言，这么做可以极大程度地复用以往的业务逻辑，只在负责最终展示的代码部分作差异化。
工程化
上面这些技术性的问题都解决了，剩下的都是规模带来的边际效应，这需要我们从工程化角度去考虑很多问题：
某个JS模块被修改，如何得知会影响谁？
某个界面片段被调整，会影响什么界面？
如何最小化发布？
如何一键测试、打包、压缩？
这些话题，篇幅所限，不在本文中叙述，可以查看我另外的关于Web应用组件化的文章。
|
