Frone-end develop flow based on FED tool 5 years ago

# 基于FED的前端开发流程

# 前言

本文主要探讨的是前后端在开发过程中围绕数据接口的流程改进及FED在其中所发挥的作用，并不涵盖整个项目的开发流程。

# FED简介

FED 是一个前端开发工具平台，供前端编写简单的后台接口及相关工具，以调试开发页面; 前端可以在此环境下，使用真实的URL访问地址访问，并可嫁接于其它服务器调试页面（调试线上代码）, 可以写页面模板代码并使用测试数据调试输出，最终可生成文档。

FED 试图重新划分项目开发中前后端分工，明确各开发范围，提高项目并行开发效率，降低前后端开发的耦合度；同时为前端开发提供了可测的工具平台，使之在无后端实现情况下也可模拟后端接口及数据，测试页面功能。

# 有关前后端解耦

在前端开发的各个阶段解除对于后端数据的依赖：

1. 前端编码阶段：解除对于control层的依赖，自由定义数据格式。
2. 前端联调阶段：页面级别控制切换采用模拟数据或者是真实数据。
3. 前端维护阶段：直接从线上环境摘取数据，在线调试前端代码，适应各种场景。

解耦：让更合适的人做更合适的事。
方案：前端组件化，后端接口化。

# 传统的开发流程

传统流程下，前端根据UI及UE制作静态HTML页面，然后交付给后端转成页面模板再进行联调开发，前端严重依赖于后端数据接口。这样做的缺点是：

1. 页面模块无法复用，一旦遇到需求变更，公共模块的修改需要依次手动修改所有引用页面，操作费时繁琐且容易出错；
2. 页面中无法定义模板变量，最终转成的页面模板中通常需要定义一些模板变量诸如基础路径、图片路径等，目前的做法是在转模板时人工替换；
3. 开发时访问的页面路径与真实上线后的路径不同，页面中链接标签中设定的地址在转成页面模板时需要再一次修改；
4. 后期需求变更时，目前通常做法是直接修改页面模板文件，此时便需要前端开发者需要在本机跑起整个项目，搭建环境及部署运行项目，而前端通常不需要修改后端代码。 总而言之，前端编写静态HTML页面，无论对于前端还是后端，开发、调试、需求变更和后期维护均不方便、不敏捷、不友好。

# 理想的开发流程

1. 前端开发时直接编写页面模板，最终交付后端时的页面模板不需要做任何改动，与后端接口自然无缝对接
2. 前端开发时不需要运行整个项目，甚至不需要配置后端环境及签出整个项目的代码
3. 前端在开发过程中完全不依赖后端，双方遵循接口约定隔离开发
4. 同样的流程适用需求变更时

理想状态下，减少了中间环节，流程变得简单高效，前端开发者直接输出最终页面模板，直接对项目最终界面效果负责。

# 理想状态所需要的条件

• 与后端相同的模板引擎
• 适用于前端的完整的开发调试环境
• Mock数据服务器
• 与后端清晰的接口约定

# FED目前所解决的问题

FED 目前基于Node.js打造了一个基本的前端开发工具平台，主要提供了：

• WEB项目运行容器
• 包括后端常用的FreeMarker等模板引擎
• 本地Mock数据服务
• 代码即时编译等常用前端的功能

基于FED开发项目，前端直接编写页面模板代码，并在FED环境中开发调试，不再需要本机部署运行整个项目，大大提高了开发效率。

开发一个模块的步骤变成：

1. 启动FED
2. 编写页面模板代码
3. 定义Mock数据和接口
4. 打开浏览器访问页面调试
5. 调试OK提交前端代码入库

不再需要Tomcat，不再需要部署重启工程，不再受制于后端接口的开发，甚至不再需要工程的全部代码。 后端签出前端编写的模板代码后，在按照约定实现好接口的前提下，直接就可启动项目查看页面最终效果。

# FED对于测试的改善

FED实际上是一种Mock Server的实现，所不同的是，它还提供了模板引擎及前端开发工具环境，因此测试人员可以像使用Mock Server一样来利用FED编写模拟数据，从而进行更灵活更高效的前端页面测试。

后端的Action层接口测试可以通过编写JUnit单元测试来实现自动化测试，但前端测试时需要依赖后端所提供的数据，传统条件下，测试需要通过项目的管理后台手动配置不同的数据来进行测试，测试工作繁重、不灵活，有大量的重复和无用的工作，但通过FED便可以准确地定义需要返回的数据，而且所有定义的数据都可以非常方便地复用。

目前FED在实际应用中虽然还没有真正应用于测试，但通过进一步完善，完全是可以满足这种需求。 业界的其它解决方案

各公司技术架构、技术选型不同，所使用的工具也不同，暂时未发现一款适用性较广的工具解决方案。FED的设计实现也同样是对于现有的开发模式进行的优化改进。

• 百度FIS

FIS提供了一套贯穿开发流程的开发体系和集成开发环境，为产品线提供前端开发底层架构，这能帮助工程师提高开发效率，沟通协作效率，快速实现需求并达到代码的最优化。

缺点：FIS目前仅面向PHP，并不适用于JAVA；FIS的使用需要服务器端配合。

• 淘宝 淘宝的方案大致是前端提供给后端一些封装精良的组件，由后端直接调用开发页面，需要后端了解基本的前端知识；而前端负责维护前端通用类库和业务线组件库、解决兼容性问题等。由于淘宝的人员配置特点，需要后端参与一些前端开发工作。

相关讨论参见：https://github.com/aralejs/aralejs.org/issues/50

缺点：依赖于公司的人员配置特点，对前后端技术要求都比较高。

• 腾讯

很多项目组采用noBackEnd的开发模式，面向OpenAPI接口开发，调用的是内部业务层API接口，如用户注册API、好友关系API、JSON格式的KV存储API及文件处理API等。

• 其它解决方案

Backbone.js, Ember.js, Angular.js等框架所使用的与后端RESTful通信。

缺点：不支持后端页面模板这种开发方式。

# FED未来展望

未来FED将会采用 服务器-客户端 模式，将所有的Mock数据托管在服务器端，并提供友好的管理界面，使前后端开发人员均可随时通过此管理界面编写Mock, 约定接口规范，生成的Mock会自动（手动）同步到前端开发者的客户端FED中以供开发调试；同时可以自动生成后端开发的接口模板（Interface），后端可直接导入到工程中应用此接口，从而保证前后端接口约定的实现。

对于前端开发，FED也将会集成打包部署、代码压缩、图片优化等常用前端开发功能，实现前端开发的一站式平台。

# 总结

通过使用FED，可以降低对前端开发环境的需求（不需要使用Eclipse, 不需要运行整个项目），提高前端开发效率，压缩开发和调试成本；不依赖后端接口，前端开发时更加灵活，更能够迅速地完成需求变更；减少开发环节，提高前端开发者编码转换率，降低开发成本；构建了页面测试的平台基础，有助于前端的自动化测试实现。

FED的设计和实现源于我本人在实际项目开发中遇到的问题的总结和思考，已经应用于实际项目开发中，并取到了一定的成果，相信经过不断地完善，将会更加切合我们的项目开发需求，提高前后端协作开发效率。