互联网金融产品移动前端发展简史标题虽然是互联网金融前端，当然这里还是拿陆金所为基础原型来讲述前端的历史。早期的陆金所前端2015年之前，陆金所的业务复杂度和开发人员规模都不算大，当时的业务主要还集中在PC端，移动业务相对算是残缺的，几乎没有业务是mobilefirst，所以对移动端的要求也并不是很高，移动端包括陆金所APP的主业务端和和合作伙伴相关的M站点，当时的APP端业务和M站业务共性也并不强，所以采取了两种截然不同的开发技术栈。Hybrid早期框架陆金所APP端的早期技术栈，主要是使用underscore.js的模板引擎，使用其强大的函数式能力（可惜当时FP还没有现在这么火），使用AMD异步加载，通过gulp单向打包到hybrid，必须随APP一起发布，并具有一定的静态ZIP包增量更新能力，选择器使用zepto，入门简单，开发成本低，非常适合当时的业务场景。此技术栈最大的弱点是debug阶段无法借助hotload机制，每一次改动都需要一个漫长的webview重新刷新加载过程，在复用性上还没有设计组件化机制，几乎每一个业务实现一套前端页面，没有模块拆分，某些页面的业务代码达到数千行，维护性差，没有抽象可复用部分，但开发效率和运行效率已经能很好的满足当时的需求。GitChatM站的早期框架陆金所M站的早期技术栈，主要是通过自己研发的NVWA框架，NVWA框架的核心思想是把开发变成配置，后端接口通过元数据，事件，条件，动态属性配置出满足业务要求的API，前端通过ECP(元素，容器，页面)能够通过拖拽组装出满足产品需求的UI，整个NVWA框架具有很好扩展性，并且提供给第三方系统进行集成。NVWA的Server端可以支持元数据管理，自定义接口、事件、条件和事件流。Client端可以支持开放编程，支持Element、Container、Page概念。不细讲会比较抽象，大家可以看看易企秀和麦客CRM也就部分理解其中的概念了。基于backbonejs和requirejs。缺点是通用代码抽象不完善，无法支持BU拆分，打包完最大的文件有时候达到3M左右、紧耦合、复用性不高、类似需求重复开发，仅仅支持m站，无法移植到Hybrid。GitChat新的业务要求随着陆金所的业务爆发式增长，特别是2015-2016。用户数从几十万增长到上千万。交易量从以万为单位发展到以万亿单位。需求数量（平均值）从5个/月发展到近100个需求/月。Native发版频次从1个/季到最高一周一版，另外还有大量Reg常规、OnlineQuick、紧急EMP、线上热修复hotfix等发版。移动占比也从很小的占比到当前的占比90%以上。而开发测试人员的增...
