在 E9 的后台开发模式中，暂有三种推广模式，第一种是现行提供的 ecology-9-demo 这套开发模式，其中包含了部分前端内容，src 源码，WEB-INF 下部分 lib 包，第二种与第一种类似，只不过去除了前端的内容以及相对应的 lib 包，只是一个单纯的 java 项目，第三种是之前阐述的 maven 项目，但目前还有部分的问题。接下来会对三种开发模式进行对比，阐述每种模式的优势、劣势及其优化方案，阐述三种模式的共有问题
@Author : Jaylan Zhou
[TOC]
1.现行开发模式
环境示例
- src：Java源码
- WEB-INF/lib：环境所需要的 jar 包
- 前端部分内容
开发步骤
- 1.在 IDEA 的 Project Structure 设置中，进行 Import Module，选择从已有项目中创建，选择脚手架地址
- 2.按照 IDEA 提示导入 jar 包
- 3.开始开发
团队协作步骤
- 1.在 IDEA 的 VCS 中，检出库中的项目
- 2.按照 开发步骤 进行项目导入
- 3.开始团队协作开发
环境优势
- 可在此项目中进行部分 前端开发 的操作
环境劣势
- classbean 与 lib 为脚手架内置，每个 KB 版本都需要建立一个脚手架
- jar 包过大时，会影响 IDEA 的运行效率以及远程仓库的代码大小
- 项目构建比较麻烦，每次都需要导入一个新的脚手架，而不是新建项目，若是新建项目则需要复制前端的内容
- 若某个 KB 版本的脚手架 jar 包环境进行了修改，客户需手动同步此脚手架的修改
优化方案
- 专人维护一个 jar 包仓库，按照 KB 版本，将每个 KB 所需的 jar 包维护到远程仓库中，客户根据 KB 版本检出所需的 jar包并引入，这样就可以新建项目
- 前端的内容可以进行剔除，结合成 2.普通 Java 项目 的形式
- 若修改脚手架的环境，采用 3.Maven 项目 的形式，可以让客户无需手动更新脚手架并重新部署
此优化方案最终的形态，是 2.普通 Java 项目 + 远程环境仓库，可用此方案代替本方案，或采用 3.Maven 项目 的方案，以 Maven 私服来代替远程 jar 包仓库
2.普通 Java 项目
此环境与 1.现行开发模式 大致相同，是剔除了前端功能以及 lib 包的普通 Java 项目
环境示例
- src：Java 源码
开发步骤
- 1.在 IDEA 的 Project Structure 设置中，进行 New Module，创建一个 Java 项目
- 2.导入 Ecology 的 classbean 以及 WEB-INF/lib 下的 jar 包
- 3.开始开发
团队协作步骤
- 1.在 IDEA 的 VCS 中，检出库中的项目
- 2.导入 Ecology 的 classbean 以及 WEB-INF/lib 下的 jar 包
- 3.开始团队协作开发
环境优势
- 纯后台开发环境，项目结构简单
环境劣势
- 导入 jar 包时，需要找到不同 KB 的 classbean 的与 lib，可仿照 1.现行开发模式 的逻辑，将 jar 包内置到脚手架中，但那样也会面临其 classbean 与 lib 为脚手架内置，每个 KB 版本都需要建立一个脚手架 同样的问题
- jar 包过大时，会影响 IDEA 的运行效率以及远程仓库的代码大小
- 若配置 jar 包远程仓库，则需要专人维护，以及仓库权限代理配置的繁琐
优化方案
- 与 1.现行开发模式 相同，建立远程的 lib 仓库，进行环境 jar 包管理
3.Maven 项目
环境示例
- src：Java 源码
- pom.xml：项目环境管理
开发步骤
- 1.在 IDEA 的 Project Structure 设置中，进行 New Module，创建一个 Maven 项目
- 2.在 pom.xml 中，引入 Maven 私服中配置的对应KB的pom工程依赖
- 3.开始开发
团队协作步骤
- 1.在 IDEA 的 VCS 中，检出库中的项目
- 2.开始开发
环境优势
- 可结合 1.现行开发模式 以及 2.普通 Java 项目 的特性
- 在脚手架中剔除了开发环境所必须的 jar 包，交由 Maven 管理，避免了因为 Jar 包及其开发环境代码过大导致的 IDEA 性能问题及远程仓库代码体积过大的问题
- 维护人员只需修改对应 KB 版本的 pom 工程，即可完成对脚手架环境的修改，并有优秀的 环境版本管理控制
- 相较于其他两种方案，减少了团队协作开发间环境配置修改的繁琐性，只需同步 pom.xml 文件即可同步环境
环境劣势
- 依赖中可能引用 pom 工程，其内部会引用其他依赖，导致其 环境配置没有直接引用 Jar 包直观
4.共有问题综述
三种方案中，有一个共性的大问题：虽然可以解决开发时的环境问题，但是在调试时，仍需有与其对应的 DEMO 环境，来在本地进行调试
在开发完成后，不管我们采取上述哪种开发模式，都需要面临调试的问题，针对于无法直接在测试环境上进行调试的客户，需要针对于其 KB 版本，在本地搭建其 Demo 环境进行调试，此情景有以下的问题
- 需要搭建多套Demo
- 客户系统环境不同，Demo的数据库不同，复现情景很难
- Demo 体量大，环境配置复杂，极难维护
目前机构的二次开发，针对于这种情况，一般采取以下措施：
- 非复杂型项目，直接在与正式环境相似的测试环境上进行demo测试
- 如不调用差异化不大的代码，本地部署一个 demo，直接在本地demo上进行测试，再上测试环境测试
但是这种开发模式有一定问题，首先，本地demo的环境与正式环境不同，如客户没有测试环境或测试环境不开放，可能会产生很大的问题，或KB版本不同，可能会调用版本之间的差异代码，导致客户环境无法使用
针对于这个问题，我总结了以下解决方案：
单元测试 Junit
- 适用于逻辑测试，验证代码的逻辑是否正确，对于搭配数据库，前台接口测试等，并不能发挥很好的效果
- 可以结合Mock进行测试数据模拟，但也只能是简单的数据，针对于Web层的复杂型数据模拟起来比较困难
Junit 可以起到一定的调试作用，但是并不能完全取代 Ecology 环境进行代码调试
Docker 模拟测试环境
- 此方法需系统架构部配合，在 EC 内部提供将客户环境的一整套应用打包成Docker镜像
- 二开可以通过docker直接模拟测试环境进行测试，因为Docker的隔离性，会比较容易管理、
这个方法的问题是，将EC整套环境打入Docker比较难，同时将编译后的代码打包到Docker环境也不容易，Docker的环境也不易维护，上手成本高，使用起来没有本地使用直观
我个人比较倾向于在客户的测试环境上进行开发，在二开的开发过程中，大部分的客户会提供测试环境，这是二开面临的大多数场景，但也会有面临客户不开放测试环境，没有测试环境或测试环境连接极为复杂，网络不好，需要跳板机等场景，这种情况下为了提升开发效率，则需要以上的方法，或将客户的运行环境拷到本地执行
5.调试过程优化综述
6.结语
目前二开的开发模式，我总结出来了三套，前两套比较相似，跟Maven项目比差别只有Jar包的管理方式不同，对于三套模式，均有测试环境不易模拟的问题，此问题属于硬性问题，并不太好解决
