有感而发 , 前端该如何与Java服务端配合开发

TOC

  1. 1. 直接发war包给前端
  2. 2. 完全采用接口方式开发
  3. 3. 前端只做静态
  4. 4. 帮前端建立一套Java开发环境
  5. 5. 使用maven (推荐)

Java 最烦的的几点就是安装麻烦,配置麻烦,运行麻烦。
其中每一点只要遇到问题就进行不下去。
这点相比PHP真的差远了,只要安装一个XMAPP,一条龙服务到位,而且文件不用编译,不用重启,既改既生效。
工作这几年下来,与前端的分工总不是那么理想,前前后后尝试了好几种方式,都是不怎么太理想,最近所在的公司是让前端安装了一模一样的开发环境,Eclipse!,然后所有的环境Java人员帮配好,但是一旦有修改文件,而又不是Eclipse里面修改(现在前端习惯使用 sublime text ),就不会自动同步对应的容器中,要回到Eclipse中刷新才生效,繁琐的多余的流程,让前端也很不爽。

以下列举几种用到过的协作方式,然后推荐一种:

直接发war包给前端

这种方式快,但也后患无穷。

前提:安装Jdk环境,安装Tomcat(或其他容器)

优点:

  1. 直接运行起来
  2. 可以让前端在webapps里面改东西,即改既生效,可以调接口

缺点:

  1. 文件修改后需要提取出来(麻烦)
  2. 如果接口报错,需要服务端再发包

完全采用接口方式开发

这种方式,就相当于全站采用(至少大部分)Ajax,前端这边直接调接口,本身可以允许在一个Apache环境或Nginx环境,只要解决跨域问题就可以。

优点:
跟App开发一样,只调接口,不依赖环境,最纯粹的分工。
PS:之前比较崇尚。
缺点:
也不算缺点,算产品定位了,大范围使用Ajax,在用户体验,数据异步加载等。还有对SEO也不怎么友好。

前端只做静态

这种方式也是产品定位与开发方式的一种,还有需要Java服务端人员懂的前端开发。前端人员只做模板,模板包含了效果,交互,提示说明等。之后服务端开发人员整合到模板引擎中去,不管是使用freemarker或单纯jsp都可以。
而前端开发人员,连接口都不用调。

优点:

  1. 前端不需要参与Java的交互,连接口都不用调,纯粹的将原型转为更好看的原型,然后加一些效果。
  2. 纯粹采用Java的模板引擎,或者让Java写JS,一些接口自己写,自己调,这方面少了沟通的成本,不过还是要出文档。
    缺点:
  3. 协作过程中需要频繁沟通,毕竟是将前端做的东西转为Java适应的模板。
  4. 如果页面出了问题,需要是前端问题还是服务端问题
  5. 如果产品升级,前端只改静态页面的话,服务端需要比对两个文件的差异,然后再提取需要的html, css, js 等到升级的页面。通常也需要更麻烦的沟通。
  6. 一旦静态升级过于频繁,服务端压力很大,很容易导致代码混乱,难以维护

评论:适合快速开发,且服务端需要有前端的基础

帮前端建立一套Java开发环境

这点就前面讲过的,Java开发人员用什么环境,前端就用什么环境,完全搬一套过来。

前提:需要帮前端安装一系列环境

优点

  1. 不需要考虑太多,让前端人员适应Java的开发过程,不过是调接口还是静态开发都可以
    缺点:
  2. 每天自己启动环境,启动服务,启动程序,前端需要熟悉Java人员的开发流程
  3. 只适合内部团队开发,如果在异地,除非前端自己懂的搭环境,否则远程很蛋疼。
  4. 受IDE的限制,有时候需要使用IDE改才生效,要不然在外部修改后需要回到IDE里面刷新(现在不知道有没这限制,之前有,很蛋疼)

使用maven (推荐)

跟以上的帮前端安装环境类似,不过好的一点,是比较干净。

前提:帮前端安装JDK环境,Maven环境

优点:

  1. 比IDE 好点,可以既改既生效
  2. 启动简单(比上面的那个),服务端人员写一个小脚本,不过是shell囧啊本还是bat脚本,前端只要双击即可自动编译,如:

    1
    mvn clean install tomcat7:run package -DskipTests
  3. 兼容性比较强。

缺点:

  1. 需要安装JDK和Maven,首次启动需要下载一些jar包,网络不好就不爽了。
  2. 也是适合内部团队开发,不过好点的是比较干净!
  3. 依赖Maven环境。

好了,这么晚了,随便写写。