现行二次开发模式优化方案

简介：现有二次开发现已不需要导入源码进行编辑和调试，此篇文档着重阐述上篇文档由 现行开发模式 精简后的 Java 项目开发模式，以及其可优化的方案

@Author ：Jaylan Zhou

IDEA版本：2019.1.4

---

[TOC]

---

1.Java 项目开发模式优化方案

1.1目录结构

• src：Java 源码
• WEB-INF/lib：所需环境class及jar包所在地

环境.png

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的环境也不易维护，上手成本高，使用起来没有本地使用直观

我个人比较倾向于在客户的测试环境上进行开发，在二开的开发过程中，大部分的客户会提供测试环境，这是二开面临的大多数场景，但也会有面临客户不开放测试环境，没有测试环境或测试环境连接极为复杂，网络不好，需要跳板机等场景，这种情况下为了提升开发效率，则需要以上的方法，或将客户的运行环境拷到本地执行