2019独角兽企业重金招聘Python工程师标准>>> 
这篇是我参加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的方式来编写这类控件，比如：
$(function() {
$( "#tabs" ).tabs();
});如果这样，这些复杂控件就都要通过JavaScript来创建和渲染了，这与我们刚才提到的原则是违背的。那我们寻找的是什么呢，是一种能扩展已有 HTML体系的东西。在早期，IE浏览器中有HTC，可以通过引入命名空间来声明组件，现在的标准浏览器中又引入了Web Components，在Polymer这个框架中可以看到更多的细节。说到底，这类方式要做些什么事情呢？
- 隔离组件的实现，让使用变得简单
- 支持自行扩展新的组件
- 作一些作用域上的隔离，比如Web Components里面，style标签上可以加作用域，表示这个样式只生效于组件内部
从另外一个角度讲，为什么我们非要这么做不可？最大好处来自哪里？对于大型项目而言，管理成本和变更成本都是需要认真考虑的。如果一个组件，需要在 DOM中声明一个节点， 然后再用一个js去获取DOM，把DOM渲染出来，再填充数据的话，这个过程的管理成本是很大的，因为HTML和JS这两个部分丢了一个都会有问题，无论 在什么时候，维护一个文件总是比维护多个文件要强的，我们看HTC那种方式，为什么它的使用成本很低，因为它可以把控件自身的DOM、逻辑、样式全部写在 自己内部，整个一个文件被人引用就可以了。在现在这个阶段不存在这么好用的技术了，只能退而求其次。
所以，在这个点上，Angular带来的好处是可扩展的标签体系，这也就是标签的语义化。Angular的主打功能之一是指令，使用这种方式，可以很容易扩展标签或者属性。比如，业务开发人员可以直接写：
这样多么直观，而且可以跟原有的HTML代码一起编写，不造成任何负担。语义化的标签是快速编写界面的不二法门。
业务逻辑
有了语义化标签之后，如果我们只写界面不写逻辑，那也够了，但现实往往没有这么美好，我们还要来考虑一下业务逻辑怎么办。
企业应用一般都是面向某行业的，在这个行业内部，会有一些约定俗成的业务模型和流程，这些东西如何复用，一直是一个难题。以往的做法，会把这些东西 都放在服务端，用类似Java这样的语言来实现业务元素、业务规则和业务流程的管理。这种做法所带来的一个缺点就是对界面层的忽视，因为他只把界面层当作 展示，对其中可能出现的大量JavaScript逻辑感到无所适从。很多从事这一领域的架构师不认同界面层的厚度，他们认为这一层只应当是很薄的，纯展示 相关的，但在这个时代，已经不存在真正轻量级的界面了。
前面提到，我们在前端作分层，把展现层跟业务逻辑层完全隔离，带来的好处就是逻辑层不存在对DOM的操作，只有纯粹的逻辑和远程调用，这么一来，这 一层的东西都可以很容易做测试。对于一个大型产品来说，持续集成是很有必要的，自动化测试是持续集成中不可缺少的一环。如果不做分层，这个测试可能就比较 难做，现在我们能把容易的先做掉，而且纯逻辑的代码，还可以用更快的方式来测试。
之前我们做前端的单元测试，都需要把代码加载到浏览器来执行，或者自行封装一些“无头浏览器”，也就是不打开实际的展示，模拟这个测试过程。这个过 程相对来说还是有些慢，因为它还有加载的这个网络传输的过程，如果我们能在服务端做这个事情呢？我们看到，最近很火的NodeJS，它从很多方面给了前端 工程师一个机会，去更多地把控整个开发流程，在我们这个场景下，如果能把针对前端逻辑的单元测试都放在node里做，那效率就会更高。
二次开发平台
我们来看看，有了这么一套分层机制，又有了界面标签库之后，该做些什么呢？做企业软件的公司，有不少会做二次开发平台，这个平台的目标是整合一些已有的行业组件，让业务开发人员甚至是不懂技术的业务人员通过简单的拖拉、配置的形式，组合生成新的业务功能。
从界面的角度看，拖拽生成很容易，很多界面原型工具都可以做，但要如何整合数据和业务？因为你要生成的这个功能，是实实在在要拿去用，不是有个样子 看就可以，所以要能跟真实数据结合起来。 但这事情谈何容易！就比如说，界面上有一个选择所属行业的下拉框，里面数据是配置出来的，对这个数据的查询操作在后端，作为一个查询服务或者是业务对象管 理起来，有些传统的方式可能是在后端作这个关联，Angular框架可以把这个事情推到前端来。相比Backbone这样的框架来说，Angular由于 有双向绑定，这个过程会变得特别省事。一个界面片段想要和数据关联起来，要做的事情就是各种属性的设置，所以动态加载和动态绑定都会比较容易。
比如：
partial.html
- {{item.name}}
main.html
...
...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应用组件化的文章。
电商购物体验的把控与升级，传统制造企业的电商摸索之路，数据支撑的购物个性化推荐，O2O平台架构设计。更多电商话热点在ArchSummit深圳2015大会“电商和零售业的转型”专题。