开发前请认真阅读，避免出现特殊问题

一、概述

YonBIP/YonSuite低代码开发平台YonBuilder客户化开发编码规范文档

禁止应用构建开发的单据使用自定义项、自定义档案
应用创建所属领域和发布一级菜单建议保持一致，节点发布避免出现【****列表】，请调整列表页面命名
禁止直接在客户生产环境进行开发操作,开发、生产分离
禁止需求探索和开发同步进行
禁止数据建模实体发布后删除字段
尽量避免实体、页面设计器的反复增补修改
页面建模中禁止使用“页面规则”和“公式”，相应逻辑需要通过前端脚本实现。（传输包不支持页面规则和公式，只能作为实施配置内容）
禁止实体业务属性使用系统关键字
函数编写要符合JS开发命名使用规范
公共参数、配置、工具类、可复用方法建议封装为公共函数，增加代码可读性
前端函数禁止复杂循环及循环调用后端请求
前端函数尽量避免JS动态生成HTML、CSS样式
前端函数尽量避免循环操作真实DOM
前端函数引用三方JS在线地址，建议使用官方提供并压缩后的
后端函数尽量避免循环操作YonQL，优先使用YonQL批量操作
后端函数尽量避免长链路的调用开放平台接口、三方接口; 性能/稳定性很难保证
后端函数尽量避免调用开放平台单据类保存接口,建议通过业务流实现推单、回写功能
后端函数尽量避免调用开放平台查询类接口，建议优先考虑参照带入，参照过滤实现。单据类无系统预制参照的情况，可通过参照其他选项创建档案参照
后端函数调用开放平台或三方查询类接口必须实现分页,每页最大数量建议不超过100；

二、应用构建编码规范

2.1、应用创建规范

应用所属领域和应用业务能力保持一致

2.2、命名规范

2.2.1、实体字段命名

• 原厂扩展业务属性加前缀extend,如：extendMerchantCode**

以下关键字禁用

base    id    tenant_id    creator    createTime
modifier    modifyTime    pubts    dr    pk_temp
version    approvalFlow    pk_procdefins    pk_procdef    startorg
startdept    verifystate    isWfControlled    businessFlow    bizFlowId
isFlowCoreBill    bizFlowName    bizFlowVersion    source_id    sourcechild_id
source_billtype    bizFlowInstanceId    businessType    bustype    ITree
parent    level    path    sort    isEnd
name    code    enable    enablets    disablets
org_id     status

2.2.2、页面建模

节点发布避免出现【**列表】，请调整列表页面命名

2.2.3、函数

2.2.3.1、驼峰式命名规范

驼峰式命名法介绍：

驼峰式命名法由小(大)写字母开始，后续每个单词首字母都大写。

按照第一个字母是否大写，分为：

 ① Pascal Case 大驼峰式命名法：首字母大写。eg：StudentInfo、UserInfo、ProductInfo

 ② Camel Case 小驼峰式命名法：首字母小写。eg：studentInfo、userInfo、productInfo

2.2.3.2、变量

命名方法：小驼峰式命名法。

命名规范：前缀应当是名词。(函数的名字前缀为动词，以此区分变量和函数)

命名建议：尽量在变量名字中体现所属类型，如:length、count等表示数字类型；而包含name、title表示为字符串类型。

// 好的命名方式
var maxCount = 10;
var tableTitle = 'LoginTable';

// 不好的命名方式
var setCount = 10;
var getTitle = 'LoginTable';

2.2.3.3、函数

命名方法：小驼峰式命名法。

命名规范：前缀应当为动词。

命名建议：可使用常见动词约定

// 是否可阅读
function canRead() {
 return true;
}

// 获取名称
function getName() {
 return this.name;
}

2.2.3.4、常量

命名方法：名称全部大写。

命名规范：使用大写字母和下划线来组合命名，下划线用以分割单词。

命名建议：无。

示例：

var MAX_COUNT = 10;
var URL = 'http://www.baidu.com';

2.2.3.5、单行注释

说明：单行注释以两个斜线开始，以行尾结束。

语法：// 这是单行注释

使用方式：

  ① 单独一行：//(双斜线)与注释文字之间保留一个空格。

  ② 在代码后面添加注释：//(双斜线)与代码之间保留一个空格，并且//(双斜线)与注释文字之间保留一个空格。

  ③ 注释代码：//(双斜线)与代码之间保留一个空格。

示例：

// 调用了一个函数；1)单独在一行
setTitle();

var maxCount = 10; // 设置最大量；2)在代码后面注释

// setName(); // 3)注释代码

2.2.3.6、多行注释

说明：以/开头，/结尾

语法：/ 注释说明 /

使用方法：

  ① 若开始(/*)和结束(*/)都在一行，推荐采用单行注释。

  ② 若至少三行注释时，第一行为/*，最后行为*/，其他行以*开始，并且注释文字与*保留一个空格。

示例：

/*
* 代码执行到这里后会调用setTitle()函数
* setTitle()：设置title的值
*/
setTitle();

2.2.3.7、函数(方法)注释

说明：函数(方法)注释也是多行注释的一种，但是包含了特殊的注释要求，参照 javadoc(百度百科)。

/** 
* 函数说明 
* @关键字 
*/

/**
* 合并Grid的行
* @param grid {Ext.Grid.Panel} 需要合并的Grid
* @param cols {Array} 需要合并列的Index(序号)数组；从0开始计数，序号也包含。
* @param isAllSome {Boolean} ：是否2个tr的cols必须完成一样才能进行合并。true：完成一样；false(默认)：不完全一样
* @return void
* @author polk6 2015/07/21 
* @example
* _________________ _________________
* | 年龄 | 姓名 | | 年龄 | 姓名 |
* ----------------- mergeCells(grid,[0]) -----------------
* | 18 | 张三 | => | | 张三 |
* ----------------- - 18 ---------
* | 18 | 王五 | | | 王五 |
* ----------------- -----------------
*/
function mergeCells(grid, cols, isAllSome) {
 // Do Something
}

2.3、实体操作规范

• ① 禁止数据建模实体发布后删除字段
• ② 禁止实体业务属性使用系统关键字，清单请看：2.2.1 小节

2.4、函数扩展规范

2.4.1、前端函数

• 1 公共参数、配置、工具类、可复用方法建议封装为公共函数，增加代码可读性
• 2 前端函数禁止复杂循环及循环调用后端请求
• 3 前端函数尽量避免JS动态生成HTML、CSS样式
• 4 前端函数尽量避免循环操作真实DOM
• 5 前端函数引用三方JS在线地址，建议使用官方提供并压缩后的
• 6 前端函数不能写密码\ak等敏感信息

2.4.2、后端函数

• 1 后端函数尽量避免循环操作YonQL，优先使用YonQL批量操作
• 2 后端函数尽量避免长链路的调用开放平台接口、三方接口; 多个接口（保存/更新/删除）连续调用，异常逻辑很难处理事务回滚
• 3 后端函数尽量避免调用开放平台单据类保存接口,建议通过业务流实现推单、回写功能
• 4 后端函数尽量避免调用开放平台查询类接口，建议优先考虑参照带入，参照过滤实现。单据类无系统预制参照的情况，可通过参照其他选项创建档案参照
• 5 后端函数调用开放平台或三方查询类接口必须实现分页,每页最大数量建议不超过100；

2.4.3、YonQL

• 1 尽量避免循环内执行sql
• 2 子查询不推荐使用，性能差
• 3 如果使用了函数，尽量给结果起别名，防止同名函数别名覆盖。
• 4 公式导致性能变差,不推荐使用
• 5 查询推荐使用 "distinct” 去重

2.4.4、定时任务(后端函数方式)

• 定时任务的最大执行时长为1分钟。尽量避免在定时任务中处理大批量数据，循环插入等操作
• 工作时间禁止设置定时任务；时间范围应选择在 03:00 - 05:00
• 定时任务的执行周期要大于1个小时

2.4.5、数据库字符集

• 数据库导出的脚本要自己指定一下字符集"utf8mb4"，然后再导入到数据库。为以后索引使用(适用于专业服务) 。

2.5、应用发布规范

应用所属领域和发布菜单保持一致

2.6、应用迁移规范

2.6.1、主流程

场景：开发沙箱进行功能开发；测试沙箱进行功能验证；验证通过迁移至生产租户；生产租户发现BUG，需要重新在开发沙箱进行修复，再次走全流程。

2.6.2、先有生产后增补沙箱

场景：客户先购买了生产租户并在生产租户进行了开发 首次可以从生产环境将应用迁移至开发沙箱； 后续按照开发沙箱-》测试沙箱-》生产租户的方向进行迁移，尽量避免同一应用再次从生产迁移沙箱

2.7、集成配置/开放平台调用规范

• 1、保存类相关接口需要按照文档说明填写所有必填项
• 2、支持幂等的保存接口，需要按照一定规则生成幂等key. 相同数据生成的幂等key要保持一致。（可以采用请求参数转string后MD5加密，用结果值作为幂等key使用）
• 3、token的有效期是2个小时，建议第三方系统缓存token. 禁止每次调用接口都获取token
• 4、查询类接口建议每页查询数为500
• 5、批量保存类API，数量最大100