基于DEP开发的约束和规范EAS产品部技术架构部纪大松导读阐述基于动态扩展平台DEP开发的注意事项和约束，通过本规范指导开发工作。适用读者实施人员、现场二次开发人员、研发中心客户化开发人员。适用版本金蝶EASV7.0SP1。请注意：本文件只作为产品介绍之用，不属于您与金蝶签署的任何协议。本文件仅包括金蝶既定策略、产品及功能方面的信息，不能以本文件作为要求金蝶履行商务条款、产品策略以及开发义务的依据。本文件内容可能随时变更，恕不另行通知。1概述..........................................................................................................................................31.1目的..............................................................................................................................31.2读者..............................................................................................................................31.3参考..............................................................................................................................32指导原则..................................................................................................................................33约束和规范..............................................................................................................................33.1版本管理......................................................................................................................33.2属性命名......................................................................................................................43.3扩展方案......................................................................................................................43.4静态引用......................................................................................................................43.5脚本调试......................................................................................................................43.6元数据修改..................................................................................................................51概述1.1目的1.2读者实施人员、现场二次开发人员、研发中心客户化开发人员1.3参考DEP开发流程图。2指导原则可管理。通过版本管理等手段实现二次开发成果的迭代，通过命名规范等约束开发人员行为，实现开发内容的高可用。可恢复。通过适当的备份，保证开发阶段性成果，进行必要的风险管理。防止某些操作导致无法挽回的损失。易合并。通过命名前缀等一些手段减少冲突发生的次数，简化元数据引擎的合并，避免合并冲突对象的一些规则导致的未知情况发生。保稳定。约束生产环境下的开发操作，保证生产环境的稳定。3约束和规范3.1版本管理基线。任何开发和修改都需要基于某个版本，这个初始版本称为基线。基线可以根据项目情况进行迭代。建议以生产环境中的方案为基线，后续开发均以其为基础。如果生产环境中的方案发生变动，需要调整开发基线。版本。以版本的形式管理阶段开发成果，版本包含版本号，修改内容等信息。建议以“项目名称+日期+序号”的形式建立版本号。版本生成频率。根据项目特点及资源组成制定策略，一般扩展内容增加越快，更新周期就越短。这样更有效保证开发成果不丢失。备份。部署生产环境时，需将生产环境中的方案进行备份，建议单独管理生产环境的备份。3.2属性命名命名前缀。各组织、机构或开发小组，需按照项目情况规定特定的字母前缀，进行命名约束，减小冲突发生概率。比如金蝶客户化开发可以采用“KD”作为前缀。属性一般包含名称和别名。名称不能用中文，必须为字母的组合或字母+数字的组合。名称前加命名前缀。别名一般为具有业务语义的文字。比如职位增加一字段职位类别，名称为“kdtype”，别名为“职位类别”。3.3扩展方案方案命名。方案名称为首字母大写的字母的组合。名称应突出项目特点，可以针对于某个客户、某个行业或某个业务领域。粒度大小。方案内容较多则会导致并行开发效率降低，单个功能点调试能力减弱；内容较少则会导致方案之间的耦合度较高，单个方案不足以描述业务，多个方案管理难度较大等。建议以业务领域或某个专题进行划分，将相关联的业务对象导入在同一个方案下。如果只是做局部调整，则将需调整的内容导入即可，比如某个界面或实体。启用禁用。生产环境下，方案不要频繁的启用禁用，启用禁用不仅会增加系统处理压力，还可能造成系统不稳定。3.4静态引用静态和动态是相对而言。BOS开发的元数据或java代码属于静态内容，它们和数据库帐套无关，DEP开发的内容属于动态内容，与帐套和动态扩展方案相关。基准布局、扩展脚本属于静态内容，它们不区分用户和组织，而动态查询方案、布局方案属于动态内容，它们依赖于分配。不建议静态内容引用动态内容。如果项目中需要这种方式开发，需开发人员保证开发内容的健壮性，规范的容错机制。3.5脚本调试禁止在生产环境中进行调试。保证生产环境中不存在调试信息。建议在方案导出时，清除调试信息。3.6元数据修改禁止通过修改元数据源文件或后台数据来修改元数据属性。对于必要的数据修复，需在研发中心相关人员指导下进行。
