简介：现有二次开发现已不需要导入源码进行编辑和调试，此篇文档着重阐述上篇文档由 现行开发模式 精简后的 Java 项目开发模式，以及其可优化的方案
@Author ：Jaylan Zhou
IDEA版本：2019.1.4
[TOC]
1.Java 项目开发模式优化方案
1.1目录结构
- src：Java 源码
- WEB-INF/lib：所需环境class及jar包所在地
1.2开发步骤
- 1.在 IDEA 的 Project Structure 设置中，进行 New Module，创建一个 Java 项目
- 2.建立一个lib文件夹，将所需的class文件以及jar包放入
- 3.引入lib资源
- 4.开始开发
1.3团队协作步骤
- 1.第一次建立的项目，需在对应的VCS系统中建立仓库，并将此项目同步至VCS仓库
- 2.检出或pull项目
- 3.开始开发
1.4 调试步骤
1.将编译后的代码，拷贝到 classbean 中
-
2.在 Ecology demo 对应的 Resin 中，修改resin.properties：
-
修改代码：
# 将 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9090（此处不一定为9090，可按照实际情况配置，在IDEA中对应即可） 粘贴到原始 jvm_args 配置中，前后要以空格分隔！ # 初始配置 jvm_args : -Xmx5550m -Xms5550m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC -javaagent:wagent.jar # 修改后的配置 jvm_args : -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9090 -Xmx5550m -Xms5550m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC -javaagent:wagent.jar -
图片示例：Resin修改.png
-
-
3.在Idea 中，新建 Run/Debug 配置，选择Remote，在port中，填入你在Resin中配置的远程调试端口，配置如下图
Remote配置.png
选择测试的Module
此处请注意，Module中你要打断点的类，一定要跟 classbean 中测试的类保证目录一致！否则测试不到
4.启动Resin
-
5.在IDEA中进行Debug，当出现如下状态时：
已连接.png
证明连接成功！此时运行需要测试的代码，会进入断点
1.5 编译路径修改
修改编译路径，可以在编译时，直接将class文件打入选中的classbean，无需复制粘贴代码，配合1.4 调试步骤可更好的提高效率
-
1.在 Project Structure 中，找到对应的module，按如下设置：
改变输出路径.png
选择其output path为对应Ecology的classbean即可
2.待优化点及优化方案
1.demo环境管理
方案中，有一个问题：虽然可以解决开发时的环境问题，但是在调试时，仍需有与其对应的 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的环境也不易维护，上手成本高，使用起来没有本地使用直观
我个人比较倾向于在客户的测试环境上进行开发，在二开的开发过程中，大部分的客户会提供测试环境，这是二开面临的大多数场景，但也会有面临客户不开放测试环境，没有测试环境或测试环境连接极为复杂，网络不好，需要跳板机等场景，这种情况下为了提升开发效率，则需要以上的方法，或将客户的运行环境拷到本地执行
