欢迎您来到“名字什么都是浮云”的博客空间!

.NET程序规范文档

.NET程序规范文档

.NET程序规范文档

Previous Next
 

.NET程序规范文档

版权说明

原创

作者

名字什么都是浮云

 

验证 | 新增 | 查询 | 更新 | 测试 | 作废 | 导入 | 提交审核 | 版本发布 | 拷贝 | 事务 | 表结构

 

配置 | 程序中的SQL | 接口监控 | 异常监控 | SQL发布 | 功能发布 | 编程规范 | 命名规范 | 模块常见关键字

 

验证

对象非空验证

集合非空验证

字典非空、空键验证

数组使用索引必须验证长度,如arr[0]

循环必有终止

字段必须与数据库同步

类型必须标识可序列化

常用字段状态值严禁直接使用数字写死

 

代码重审,当一个功能开发完成后,一定要对每一行进行审查,这样能避免错误,比如拷贝的原程序不完整

 

新增

必须防止重复提交

 

 

查询

单据和明细金额必须使用一致的四舍五入方法

带金额的计算必须处理null避免金额溢出

查询必须过滤物理删除数据

查询有效性数据必须过滤作废状态

查询列表必须和列表统计数保持一致,可能的话尽量用一套逻辑

查询列表应当带时间展示

递归中严禁使用查询语句

循环中避免使用查询语句

 

正确使用查询:

  1. 非及时性数据,应查询读库
  2. 数据量不大,访问频率高,数据更改频率低,应使用缓存
  3. 导出数据,应采用分页压缩包下载方式
  4. 数据校验查询,必须使用及时性查询,避免校验缓存数据
  5.  

 

更新

带计算的单价,注意转换或计算后是否存在翻倍,溢出问题。

更新条件尽量带非空验证

更新与新增的相同逻辑中是否存在疏漏。

不同服务之间的功能更新,要检查是否存在重复操作(避免job里系统自动更新了,ERP还可以手动更新)

不同服务或网站之间拥有同一套功能,应当抽离共同点独立服务调用(避免同一个功能要更改多个位置且可能功能还出现差异的问题)。

更新明细行数数量可能多时,需要做分页处理,避免一次性更新大批数据造成超时异常

共享字段有更新时必须连带更新(例如用户有部门这个字段,用户下部门也有这个字段)

 

 

测试

一般功能开发完成后,至少要进行以下测试流程:

  1. 流程测试,对多组测试线进行正确流水测试
  2. 输入验证测试,对输入的错误、空、无效等数据进行有效性验证
  3. 显示字段验证测试,进行更新或查询后,对页面显示的数据进行准确性验证
  4. 初始化数据测试,对历史数据、新数据、现有数据进行流程测试。
  5. 表字段验证,进行更新后,验证表字段存储数据是否正确,是否存在无效数据
  6. 表关联字段验证,进行更新后,验证关联表字段存储数据是否正确,是否可以正常关联。
  7. 流水记录验证,进行更新后,检查更新前与后数据是否符合要求。
  8.  

测试前需要列出测试线和点。

测试线,指一个模块可以走的流程步骤有几种方式

测试点,指一个功能涉及的关联有那几个部分

 

 

作废

单据创建时会占用一定的资源,因此在作废时也需要释放一定的资源

 

导入

数据导入后必须要验证数据库主外键字段有效性、主要功能及其其他字段的有效性

数据导入失败时必须能让业务清楚到某一行的错误

数据导入成功时必须要提供下载结果的文件(该文件明确列出来导入多行后生成的新数据)

 

 

提交审核

提交审核应该包含保存及保存的校验(提交审核前一般为初始状态,可能数据改了未进行保存)。

 

 

版本发布

如果功能改动中涉及样式表、图片、js变更,发布后需要验证是否发布到网站上(因有时候发布可能因为版本未包含、或者已包含未发布失去等原因)。

发布时要检查是否代码提交完整(是否存在未保存的文件)

发布时要检查是否更新到最新代码(避免丢失公共程序)

发布应该选择release性能优化编译

 

 

拷贝

拷贝程序时要验证代码是否丢失。

要验证功能用途是否一致性效果。

 

 

事务

事务前要进行状态验证

事务异常时要进行回滚、监控记录

事务超时时要进行回滚、监控记录

事务中要加锁

事务中要处理并发问题

 

 

表结构

主外键字段要加索引

表必须带更新时间UpdateTime供报表同步

表必须带新增时间CreateTime

表必须带物理删除字段IsDelete

新表字段必须加结构描述

 

 

配置

第三方链接及其参数应该走页面配置化

数据字典与配置中心区别,数据字典允许不同服务之间共享业务数据配置,配置中心允许不同服务之间同步网站配置,配置中心又称分布式服务的共享webconfig

 

 

程序中的SQL

拼接的sql参数不宜过多,避免达到SQL参数限制2000

 

查询中的SQL语句包含的变量,如果是状态类型的严禁使用数字直接写死定义,可以使用枚举或静态字段。

 

接口监控

对于程序而言,未知异常不可计数,同样我们需要监控其异常。

  1. 同一天对于同一种异常信息应记录一条监控日志
  2. 页面上可以提供可以查询监控记录的界面
  3.  

 

 

SQL发布

对于严格的系统而言,我们需要考虑数据库的性能,因此对于每个开发者提交的sql需要进行审核。审核通过之后,在系统发布时进行SQL发布

  1. 包含内容SQL提交者、SQL、审核与发布状态
  2. 页面上可以提供可以提交审核的界面

 

 

功能发布

注意功能发布前,你必须对git或者svn提交的代码文件进行对比审查工作,这一点非常重要。

对于单个系统而言可能有多个人提交功能,因此需要对每个功能进行审核通过之后,才能进行系统发布

  1. 包含内容功能简要,开发者,审核与发布状态,发布版本号
  2. 页面上可以提供可以提交审核的界面
  3. 同一版本号的功能简要应合并,并展示在登录页面行幅提示,点击后展示版本更新信息

 

 

编程规范

  1. 方法参数列表不能超过4个,超过则使用对象传递
  2. 类型必须标识可序列化
  3. 方法失效必须标识Aboaselt特性
  4. 页面按钮触发事件必须带loading层
  5. 非数据访问层DB层,严禁编写SQL
  6. 对及时性要求不严格的查询必须加nolock
  7. 新增、修改必须带操作日志
  8. 单据审核必须带审核日志
  9. 单个方法内不允许定义15个以上变量
  10. if避免嵌套超过3层
  11. 方法严禁死循环调用
  12. 多个连续更新操作必须放入事务中
  13. 循环中不允许编写查询,尽量避免sql更新。减少数据库连接开支
  14. 更新表时必须更新UpdateTime
  15. 查询表时必须带IsDelete=否物理删除标识
  16. SQL语句必须整洁格式化
  17. 主外键关联字段必须加索引
  18. 新表结构必须加字段描述
  19. 命名应当采用现有系统的普遍命名,如系统中已定义该名称则进行沿用
  20. 管理后台按钮必须加权限控制
  21. 事务操作必须设置超时时间、防止并发,网络异常等问题
  22. 插入多行数据应使用表拷贝
  23. 同一种单据的操作不能重复提交
  24. 方法中要层次分明,结构清晰,一目了然,变量位置严禁随意定义。
  25. Redis不要循环大量数据读取key或者写入key,可能在异步情况下造成连接池被占用未释放的问题,导致卡顿
  26. Redis判断key是否存在时,应该判断值是否Null,而不是Count等于0,如果Count为0读数据库,可能会出现一直查不到数据,长时间查询数据库,产生卡顿

 

 

       

命名规范

类型名称

例子

模型类

xxInfo

按钮

btnCC

下拉框

ucXX

文本框

txtXX

列表页面

xxList

详情页面

xxDetail

选择页面

xxSelector

模板页面

xxTemplate

业务类

xxManager

数据访问类

xxDac

通用类

xxCommon

更新方法

Updatexx

新增方法

Addxx

审核方法

Auditxx

导入方法

Impxx

导出方法

Writexx

查询方法

Getxx

查询分页方法

GetxxPageList

加载方法

Loadxx (Load和Get区别:Load加载单一实体对象,Get是获取特定功能的查询结果)

 

模块常见关键字

名称

例子

基础管理

Basic

订单管理

Order/Sale

出入库管理

WSM/Warehouse

客户管理

Customer

客服管理

CustomerService

用户管理

User

供应商管理

Vendor

财务管理

Finance

合同管理

Bargain

运营管理

Online

采购管理

Purchase

配送管理

Delivery

 

 

 

 

 

 

 

 

 

 

 

Created with the Personal Edition of HelpNDoc: Free EPub producer

posted @ 2022-08-09 13:47  名字什么都是浮云  阅读(71)  评论(0)    收藏  举报