12 致远OA开发规范

开发案例(业务扩展接口)

1.客开开发前缀约束：

为了快速区分标准开发与客开开发，我们对客开程序包名，新增字段等做如下前缀要求：

1.以客户的名称作为：前缀。比如：客户中石油的简称是：cnpc。

关于客户简称：请客开在进行开发之前，向标准产品申请：客户简称。标准产品将统一管理客户名称。

2.程序包名：请优先使用客户的域名，作为包名。若：中石油的域名是：www.cnpc.comwww.cnpc.com。那么程序包名是：com.cnpc.*。

3.新增字段名称：为了防止和标准产品名称冲突，请客开新增字段名称遵守如此的规范：客户公司名称_字段名称，如中石油想要增加一个字段(userType)：cnpc_userType

4.数据库新增字段：为了防止和标准产品名称冲突，请客开新增数据库字段名称遵守如此的规范：客户公司名称_字段名称，如中石油想要增加一个字段(userType)：cnpc_userType

2.添加数据库字段与表

在客开进行业务开发的时候，必然会有数据库字段添加。

为了不和标准产品冲突，且不影响双方开发，并保持可升级，我们对数据库字段作如下规范：

2.1 请客开新增数据库字段名称遵守如此的规范：客户公司名称_字段名称，如中石油想要增加一个字段(userType)：cnpc_userType。

2.2 建议：以新增表的方式，新增字段。

原因是：和标准产品在数据库层，代码的Dao层以及sql语句上完全解耦。 数据库字段的“聚合”通过客开代码上的联合查询来完成。

当然：在标准产品数据库表上添加客开字段，是允许的。但是：建议：以新增表的方式，新增字段。

3.模块版本号：

3.1 所有模块必须定义自己的版本，版本名称：version

3.2 版本号规定：我们采用3段式：a.b.c ,如：0.0.1

  a.大版本：产品大版本迭代
  b.小版本：大版本下小功能模块迭代
  c.bug 修改号： 研发bug 修改

3.3 版本配置的地方：配置在插件模块下属性属性文件中。

如图：

 

此属性文件是A8的规范：

4.可升级接口设计：参数固定化

为了使得我们的产品可升级，我们必须保持方法签名的固定。由此: 我们需要将参数对象化，

如下代码：

错误做法：

public interface IA { /** * @return */ String save(String name,int age,xxxx); }

正确做法：

public interface IA { /** * @return */ String save(Person person); }

Person 的定义:

public class Person { private String name; ​ private int age; }

如此：我们通过参数对象化的方式，解决业务参数变化的问题。

您还可以通过重载的方式，来达到同样的目的：

public interface IA { /** * @return */ String save(String name,int age); ​ /** * 通过方法重载，添加新的业务接口。 * @return */ String saveWithGender(String name,int age,int gender); }

5.禁止class 覆盖。

以前的开发中，客开通过获取我们的源码，然后修改，然后编译成.class文件，发布到tomact：WEB-INF\classes 下，进行“覆盖式”开发。

如下图：

这种方式：具备可升级能力，同时有代码合并成本，由此：禁止使用class 覆盖方式。

请客开使用：扩展接口的方式和bean替换的方式开发。

6.beanName: 不可更改

因为ctp 修改了底层bean注入逻辑，致使：bean 注入不能依靠Type 注入。只能通过名称注入(以beanName来定位bean)。 由此：请业务组在定义bean的时候，请保证beanName不可更改。

7.接口版本：请在接口或者方法上，表明：该接口或者方法，是那个版本支持。

/** * 测试类 * @author mt * @date 2021/7/6 */ @Since("8.0sp2") public interface SinceDemo { /** * 支持8.0sp2 以后的所有版本 */ @Since("8.0sp2") void a(); }

如上图，请使用：@Since 注解，标记当前接口，支持的最低版本。

请研发注意：在接口设计或者接口实现的时候，请保证：向前兼容，如：8.1 包含所有8.0 的接口，但：8.0 按照场景包含：8.1 的接口

同时：在多版本开发中，使用类来显示分离版本之间的差异，满足设计规则的：开闭原则。如：SinceDemo8_0 ,SinceDemo8_0_lts。

如此：在我们进行版本“合并”的时候，减少合并工作。

8.埋点接口：多版本兼容。

a.第一步: 接口定义：请在app-aps 定义埋点接口：并标记支持版本，打包部署。

/** * 测试类 * @author mt * @date 2021/7/6 */ @Since("8.0sp2") public interface SinceDemo { /** * 支持8.0sp2 以后的所有版本 */ @Since("8.0sp2") void a(); }

版本号来源：来源于：当前开发分支 b.第二步: 对应项目实现接口，并标记：修改范围，虽然打包部署

@Override public ColSummaryVO showSummary(ColSummaryVO summaryVO) throws BusinessException { boolean isHistoryFlag = summaryVO.isHistoryFlag(); Long oldAffair = summaryVO.getAffairId(); User user = AppContext.getCurrentUser(); //dynamic 8.0 interface permissionDynamicApi isNeedCheck start boolean checked = true; if (permissionDynamicApi != null) { PermissionCheckBO permissionCheckBO = new PermissionCheckBO(); permissionCheckBO.setUser(user); checked = permissionDynamicApi.isNeedCheck(permissionCheckBO); } //dynamic 8.0 interface permissionDynamicApi isNeedCheck end ​ xxxx }

如上述：请按照如此格式埋点：//dynamic 版本 interface 涉及类名 设计方法 start

如：

//dynamic 8.0 interface permissionDynamicApi isNeedCheck start

//dynamic 8.0 interface permissionDynamicApi isNeedCheck end

c.第三步：使用工具，现在两个分支，获取差异的且目标版本可达的接口列表

d.第四步：使用工具：根据上述接口列表，自动显示需要移植的代码：让研发人员显示移植。随后修改版本号，发布，部署。

f.bug 修改时，修复代码需要在：所有支持版本上体现。如：动态接口：isNeedCheck() 有bug，修复后，修复代码需要在支持该接口的所有版本中，体现（如：8.0，8.1 等）。