作者：李晓健。现担任苏宁视频云高级技术经理。软件技术专业，从事java开发，拥有8年开发经验，超过6年的专职前端开发经验，3年以上的团队管理经验；目前负责苏宁视频前端研发和架构工作，参与前端SDK组件的开发，推动苏宁视频云平台的架构改进和用户体验，为用户提供优质的服务。人生信条：始终相信只要有付出，就一定会有回报。
其实我们在新开一个项目的时候，在做框架的选型时也是可以根据页面结构去做一些参考。去选择一些适合我们页面结构的技术去做开发，也会大大降低我们开发的复杂度，比如我们的页面需要做成一个单页的形式，我们就可以去选一些MVC或MVVM的架构来做。
今天我们来说一下苏宁视频云前端的架构的演变历程。
第一阶段的项目架构
苏宁视频云最开始的项目架构，最开始的时候，我们的页面是用PHP、CSS、原生的javascript来做的。页面用PHP是因为我们的web服务是PHP的，里面有一些PHP的代码处理业务逻辑，这里的原生的JAVASCRIPT是没有用到任何的框架和类库的。我们有很多的自定义的组件，这些组件也都是我们自己去编写的。
上线的时候就是通过jenkins将代码进行压缩，然后发布到线上服务器。我们当时的开发流程是前端工程师开发好HTML文件，CSS样式，页面交互效果；再将写好的代码交给PHP工程师，他们拿到了我们的HTML文件，然后再手动转成PHP文件，再加入一些业务的逻辑代码。
最开始的时候我们的项目就是这样，这样看起来好像是处理一个比较初级有阶段，确实，这样看起来没有什么什么架构可言，因为里没有用到任何的类库和架构，整个项目都是用原生的代码去累起来的。
第一阶段的项目架构中存在的问题
前端开发人员开发完成后，需要PHP开发人员将html转成php
在这个过程中我们就发现问题比较多，比如说，我们前端人员将页面开发完成后，再将代码交给PHP的开发人员，他们需要将我们的html代码再做一次转换，并加入一些其他的逻辑。
这里就相当于有两套展示代码，有时页面上有一些小的问题需要修改，就直接在PHP文件上修改了，并没有同步到HTML文件里，这就造成了文件的不同步。以后再将html转换成PHP文件时，就会漏掉那些之前直接在PHP文件修改过的问题，就会使老的问题重复出现。
页面数量较多
我们的页面个数也比较多，像我们前面看过的那个页面结构，每一个左边的导航都是一个新的页面，因为头部还有一级导航，每一个一级导航都有他自己对应的左边导航，所以页面就会比较多。
单个页面请求文件过多
那时候我们的代码也都是纯原生的，所有的组件也都是自己开发，每一个组件既有js文件又有css文件。很多的组件又有依赖关系，如果一个页面用到了几个组件，就需要引入很多的js文件和css文件，一个页面所有文件加越来，不算图片大概就有三四十个。
代码的复杂度过高，对开发人员的能力要求过高
由于我们没有使用第三方的东西，所以代码量就会比较多，代码的复杂度也比较高。而有的很多开发人员从一开始学习就是从类库和框架开始学起的，对原生的js了解的不多，所以开发起来也比较困难，如果有新的成员加入团队，就需要很长的时候才能熟悉我们的架构，并进入开发，这就对开发人员的能力有比较高的要求。
重复的工作比较多,开发的工作量巨大
因为我们的页面多，当时的代码也没有做很好的分类，就是一味的往上堆代码，有新的功能，就全部用新的代码去堆，有很多的功能就是比较类似的，就导致了重复工作比较多，开发的工作量也比较大。
第二阶段的项目架构
中间正好有一次机会，产品说要对我们的产品进行重构和调整，当然产品说的重构是指功能上的，但是由于时间问题，只能一部分一部的去做，还需要上一个部分上线之后才能去做下一个部分。
和产品沟通下来，以页面上的主导航为一个单位进行重构和调整。基于这一点我们就对我们之前的架构进行调整。因为这个分块进行调整的，所以我们不可能把之前的架构推翻全部重来，这样不仅时间是不允许，也没法做到产品要求的按功能模块进行上线。
所以我们就在原有的架构基础上进行调整。
首先我们原生所有的组件肯定还是保留的。然后对页面进行了重新划分，不再是每一个每一个左边导航一个页面，而是分成一个大的功能模块一个页面，左边的导航通过前端路由去做。
这样的话我们只需要改当前需要重构的这个功能模块就行了，其他的功能模块还是保持不变。其实这样下来就相当于把改过的功能模块，由之前的多个页面合成了一个页面。
然后我们在前端直接用HTML文件来展示页面，直接将html文件发布到服务器，不再将hrml文件转成php文件。
因为我们之前的PHP文件并不是只是用来展示页面的，他还有一些逻辑在里面，所以这里我们也不能直接把PHP给去掉。然后我们就让PHP直接转到接口层，PHP只提供接口给我们前端，这样的话他之前的逻辑还是可以使用和保留，也不需要太大的改动。
PHP这一层还可以帮我们做一层前端没法做或者处理不了的问题。因为我们的系统数据有多个后台系统提供的，PHP可以帮我们前端做数据整合，由他去调用其他的后台系统，然后统一提供数据给我们前端，这样我们前端就只需要对接PHP一层接口就行了，PHP就从前端的展示层退到了前端和后端的一个中间层。
基于我们页面上还有很多相同的部分或者是需要动态生成的部，然后我们又引入了前端模板，我们选用的是arttemplate。上线流程和原来的保持不变。当我们把所有的功能都重构完成以后，这样就形成了我们的第二阶段的架构。
第二阶段中解决掉的问题
不需要再将HTML文件手动转成PHP文件
首先最明显的就是不需要再将HTML文件转成PHP文件，而且我们前端的展示文件代码只有一份，不会再出现因为文件不同步造成的重复问题不断出现的问题。这个也使PHP开发人员从前端中解放出来，他们可发专程的去做数据处理，不用再关心HTML、CSS、JAVASCRIPT这些东西了。
通过前端路由将多个页面合并成一个页面
然后我通过前端的路由奖多个页面合成了一个页面，减少了页面的个数。这样也使我们的代码文件量减少了不少，页面的体验也得到一定程度的提升，之前每点一个链接，哪怕是一个子功能都需要重新刷新一下页面，而现在只有功能主功能时才会刷新页面，切换子功能时会动态切换页面内容，不需要重新加载整个页面。
使用模板大大减少了重复代码，降低了代码的逻辑
因为我们使用了前端模板，这时很多页面相同的地方我们就可以使用同一个模板文件，这就大大降低了重复代码的存在，也降低了代码的逻辑。
第二阶段的项目架构中存在的问题
单个页面请求文件过多
虽然这个阶段的架构比前一个阶段好了很多，但是还是有少不的问题。因为我们的组件还是使用的是自己开发的组件，那些文件文件依然没有减少，页面的请求文件数还是有很多。
单个js文件中的代码较多
因为我们把之前多个页面合成了一个页面，但是总功能没有减少，而且这些功能代码全部都写到了一个文件中，所以我们的业务逻辑代码的js里的代码量会增加。
代码的复杂度过高，对开发人员的能力要求过高
一个文件里的代码量增加了，他的复杂度也会增加。代码的复杂度上去了，自然对开发人员的能力要求要更高。在这样的架构下，我们也开发了很长一段时间。
第三阶段的项目架构
正好又有一个不错机会可以让我们做重构，那就是我们的网站要改版。
大家都知道，改版可是一个大的改动，这个也没法一部分一部分的去上线，因为改完成之后，页面的风格可能就变了，也可以让网站以一个混搭的风格去上线。
所以需要改完整体上线。还有一点就是，对于前端开说，网站做整体改版，之前的很多代码可能都需要重新来写。
所所以团队经过商量，看看是不是可以直接放弃之前的架构，在不依赖之前架构的前提下做出来一个新的架构。这虽然会可能会增加工作量，但对于后期的开发会有很多的便利，而且网站全面改版后，测试也会全面覆盖。所以我们就放心的去做了。
首先需要确定的是我们的页面结构，决定依然延续二期的页面结构，以主功能为一个页面，左边的导航使用前端路由来做。然后去和产品确定了一下浏览器的兼容性，产品说，我们的客户都是签约客户，用户群体可控，兼容主流浏览器就行，但是IE需要兼容到IE9。
浏览器的兼容性也确定了，我们决定这次引用框架来做，不再去重复造轮子。接下来就是做技术选型了。
当前比较流行的框架是REACT、VUE、ANGULR。我们也决定在这三个中去选一个，最后经过对比，以及我们项目的特点和团队成员对这几个框架的了解程度，我们选择了REACT。既然我们依然需要使用前端路由，我们就选择了REACT系的 react-router。
我们还决定选择一个UI的框架，这些就可以有很多现成的组件可以用了，也会大大降低我们的开发难度和开发速度。然后我们选择了antDesign，因为他有丰富的组件和可定制性，使用非常灵活。因为react里有JSX语法，这种语法是无法直接在浏览器里运行的，需要将JSX语法转成js语法。
使用webpack和他的一些插件配置一套本地的工程化流程，可以对代码起先编译，合并，打包、代码的风格的校验等等。
既然我们有了一套工地的工程化的东西，而react又是基于模块来开发，而ES6+也是原生支持模块的，而且他还有很多新特性可以使用，源码也是直接使用ES6+来进行开发的，虽然目前浏览器对ES6+支持的还不是很完善，通过webpack的插件将ES6+转成ES5的代码。
我们本地打包之后的代码再交由jenkins去上线，因为jenkins是我们公司的上线流程，我们是无法改变的，所以这一步依然保留，不过这一次交由jenkins的代码已经不再是我们源码，而是我们经过合并处理的代码。所以文件数据会很少。
第三阶段的好处
可以直接使用antDesign的组件
因为antDesign它有非常丰富的组件，我们可以直接拿来用，而且他的文档和也非常完善。
通过modifyVars定制主题
我们的代码都是基于模块公去开发的，所以代码的耦合度也比较低，一个组件组件就是一个文件，代码的逻辑也比较简单。代码的复用性也比较好。因为组件是可以做到插拔试的，需要这个组件，直接放进去就好，不需要时直接拿掉就好，不会影响到其他功能。
antDesign的所有组件都是有他自己的主题样式的，但是他提供了定制主题，我们可以通过他他提供给我们的modifyVars的参数，将组件的样式替换成我们想要的样式。
通过webpack的多入口配置，大大减少一个页面的引入的代码量
wepack是以js作为入口文件的，我们通过配置他的多入口，就可以同时打包出多个页面的文件。
一个页面只需要引入一个公用的css和一个自己的样式文件，一个公用js和自己页面的逻辑js。
最终我们生成出来的文件也比较少，我们在打包时把多个页面都使用到的js和css 打包共用的js文件和css文件，然后再将每个页面独自使用的文件打包出来，这样我们一个页面需要引入的文件也比较少，也就只有公用文件和自己页面的文件。所以一个页面需要引入的文件数也就只有4个左右。因为我们都是以组件的方式来引入文件的，所以说基本上这个页面引入的文件都是我们使用过的，然后才打包到一起，所以文件也不会太大。
组件可以在多处共用
我们的组件也是多处共用的。
第三阶段我们解决掉的问题
通过babel的babel-plugin-import插件对antDesign组件进行按需加载
我们可以通过webpack的插件来按需加载需要我组件，也就是说，当前页面只需要加载当前页面的代码，而不说为了用一个组件把整个框架文件全加载进来，这样就可以减少文件的体积，可以使用页面更快的加载出来。
通过webpack将公用的代码抽离成一个公用的文件
通过webpack把可以把一些公用的文件抽离出来，然后第每一个页面再去引用这个公用的文件，大家都知道，浏览器自己是有缓存的，当一个文件加载了一次后，在他的有效期内，再有请求，他就直接从缓存中取，不会再去文件服务器上去取。所以说这个对我们公用文件是比较好的。
页面模块都是按组件进行开发，每个文件里只有当前组件的逻辑
我们自己的功能代码也是按组件去开发的，第个文件里只有当前组件的逻辑，所以逻辑也比较简单。我们把公用的组件放到一起，一个页面的相关组件放在一起，这样代码也比较清晰简单。代码的复杂度也会降低很多。
我们开发流程里加入了代码的风格验证，保证一个团队的代码风格是一致的。
我们的工作流程也加入了代码风格验证插件，这样可以保证我们一个团队不同的成员写出来的代码风格是一致的。
这就是目前我们现在这个阶段的架构。
未来的发展及展望
js渗透到各个领域
前面我们已经说到js已经可以做到WEB端，服务端以及客户端，将来我话我觉得他会渗透到更多的领域。
由于硬件设备的加强及网速的提升，H5也会有更好的发展
由于我硬件设备和网速的提升，纯属的H5应用应该会有更好的发展，因为现在前端的东西基本都需要通过网络来传输，如果功能丰富的话，文件的体积就会比较大，网络不好就会加载失败呀，或者文件加载比较慢，给人的体验很不好。
现在比较热的物联网也会WEB化
前端可能通过网络网络协议去和硬件编程想结合，促进物联网的发展，比如说我们觉的共享单车，他可以通过web端发出一个指令，就将车子解锁，就是比较典型的物联网应用。
由于浏览器性能的提升和更多接口的开放，web VR也会有很好的发展
由于浏览器的性能的提升和更多接口的开放，像WEB VR也会有比较好有发展。web人工智能等都会有很好的体现。
苏宁旗下子品牌苏宁视频云已累计服务客户超过2000个；苏宁视频云凭借PPTV 十年媒体技术和服务经验，融合流媒体技术、P2P、CDN 分发、海量存储、安全策略等构建的专注视频领域的一站式SaaS 服务平台。苏宁视频云集视频云直播、云点播、云上传、云转码、云存储、云统计等功能于一体，多平台全方位支持客户各种视频场景的业务需求。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31559352/viewspace-2217544/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/31559352/viewspace-2217544/
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
