代码规范与冲刺计划

这个作业属于哪个课程	至诚软工实践F班
这个作业要求在哪里	https://edu.cnblogs.com/campus/fzzcxy/ZhichengSoftengineeringPracticeFclass/homework/12665
这个作业的目标	<了解统一工程实施标准的必要性>

工程编码标准

1. 引言

1.1. 背景

软件产品与资方业务无缝衔接，在其漫长的生命周期内随着资方业务不断调整，软件产品的复杂度随之大幅提高。因此建立一个统一的工程实施标准是十分必要的，有利于整个平台在不断演化过程降低维护的复杂度，降低维护开发成本，使得整个平台处于一个持续良好的架构中，在团队人员新老交替过程中不会造成衔接空隙，不会为平台注入隐形错误。

1.2. 规范级别定义

根据实际情况分为2类等级的规范：

Ø 必要规范（默认）：对于新建或优化改造系统，开发维护人员必须严格遵守和保持。对于历史系统和小范围调整的系统（2010年6月前上线的系统），开发维护人员可以根据实际情况进行实施。

Ø 推荐规范：推荐规范即非强制规范，只是推荐和鼓励开发维护人员实施的编码规范。

1.3. 规范实施建议

Ø 建立编码所涉及的各个元素的命名、注释等标准。

Ø 设定模块业务复杂度对应编码行数的约束标准。

Ø 制定编码通则，规范日志记录、异常处理、安全管理等各类操作。

Ø 建立利用基线库融合编码规范。

1.4. 参考

【暂无】

2. 代码工程通则

2.1. 操作规范

(一). java源代码和js源代码修改

开发人员应针对此次业务需求或者测试测试报告所涉及的源代码文件进行修改，未涉及的则严禁做任何变动。
严禁使用开发工具的格式化功能。因为格式化会导致换行，会造成svn版本冲突。
如果组件的函数算法不能满足当下的新增的业务需求，则应在该组件内新增一个新的函数，而不是去修改原先的函数算法，遵守开闭原则（只做新增，不做修改）。
当类组件或js脚本的源代码有改动时，因在注释内加入改动原因和日期。详见：注释规范。
禁止修改某类组件源代码来适配环境的需要，应新建该类组件的副本（名称为源组件类名_Test），并修改该副本的源代码，使用设置配置文件的参数来进行切换。
建立工程时或者导入工程需查看是否为utf-8编码格式，防止编译时出现乱码。
对于common目录的公共算法组件，只能修复其算法漏洞，不可在原有函数内增加逻辑。
严禁直接调用其他模块业务控制器的算法函数，因在第一级模块包内新建外观器，将需要被外部调用的算法函数定义在外观器。如果需修改当前业务控制器的函数算法，则必须至外观器查阅是否有开发被外部调用，如果有则严禁修改该函数算法，以防止其他调用该方法的模块逻辑出错。

(二). jar架包和js开源插件

可以使用maven来统一管理所有开发工程的jar架包。
应在每个开发工程的web目录底下建立一个文件夹（js_opensource）统一存放js开源插件。
当需要对jar架包和js开源插件进行版本提升，需开发组所有人同意方可执行，提升后需对工程进行重新编译和针对性模块的测试，用于验证版本提升无潜在的危害性。

(三). 配置文件修改

开发人员应针对此次业务需求或者测试测试报告所涉及的配置文件进行修改，未涉及的则严禁做任何变动。
配置文件必须查看文件编码格式是否为utf-8，防止发布到生产环境时出现乱码。
模块参数型配置文件（如：sf-env-config.xml和sf-status-config.xml）必须使用主-次分离，即：一份项目公共配置文件，每个模块自有的配置文件并使用include技术导入到公共配置文件。
在往配置文件新增参数时，应使用分割线进行划分，格式如下：

，如：

(四). 数据库修改

开发环境、测试环境、正式环境的数据库需严格使用权限控制，只有项目经理才有权限进行表结构的创建或修改。
数据库物理表结构必须与数据库设计说明书（pd文件）一致，在修改物理表结构之前必须先更新设计说明书。
在项目内指定一个工程用于存放sql脚本文件的目录（存放在工程根目录底下，名称为sql_svn分支名称），按如下标准进行操作：

当数据库结构产生变化时，项目经理除了更新设计说明书之外，应立即将变更的地方化成sql语句，写入脚本文件，文件名称为个人的svn账号_sql。
工程师需要将一些配置信息写入数据库时，应将数据的写入化成sql语句，写入脚本文件，文件名称为个人的svn账号_sql。
当要即将系统上线时，项目经理应将该目录底下其他工程师的sql脚本内容汇聚到自己的脚本文件内。汇总完成后，立即将其他工程师的sql脚本文件删除。

(五). 代码提交

项目开发团队在每天上班第一件事同步与提交一次svn，5点半同步与提交一次svn。
工程师在变更公共模块算法或者公共配置后，需第一时间通知大家，然后提交svn。然后其他工程师应第一时间进行同步。
为防止冲突，在代码（及配置文件）提交前，先从SVN中更新代码和配置文件，以便及早发现不兼容的代码变更和冲突。
提交代码（及配置文件）时，如果发生冲突时，先看历史说明，再找相关人员确认，坚决不允许强制覆盖，且必须检查是否有warning，并FIX所有的warning 。
开发过程定期使用FindBugs扫描代码，合并代码时不允许出现高等级问题。

(六). 垃圾清理

对于方法内已经被注释掉的代码，在系统上线之前就应给予删除。
必须将每个控制器类组件的单元测试代码，在测试完成后就应给予删除。
对于以后不再使用的方法或类，应标注未废弃(@Decrapted)。
对于导出未使用的架包，应给予立即删除。
项目的工程不允许出现黄色感叹号，如出现表明：有导入未曾使用的类、变量、私有方法未被调用等。因立即给予删除。
工程内不允许将配置文件备份在同一个目录内，防止误操作。系统上线之前应给予删除。

(七). 工程备份

系统每一次上线成功后，项目经理应立即将svn主干代码打成压缩包，并设置压缩包密码。交由团队经理统一保管。
项目经理每周必须对开发环境和测试环境的数据库进行备份，备份数为3，即：在备份到第4次必须将第1次备份文件删除。
项目每周必须对svn分枝内的工程备份2次（周一和周四），备份数为1。

2.2. 日志规格

(一). 日志等级与规范

由于测试环境、生产环境无法使用开发工具进行断点调试，因此必须养成依赖日志跟踪和故障分析的习惯。日志应划分级别进行规范化管理：

第一级debug：用于调试跟踪程序算法逻辑。
第二级info：可覆盖第一级，用于记录与外部系统交互的命令或者报文（如：sql命令或者http报文）。
第三级warn：用于记录潜在错误的信息。该潜在错误不会影响业务逻辑正常运行。
第四级error：用于记录程序执行发生的异常信息。该错误会导致业务运行不下去。

典型的算法逻辑与日志输出结合使用，见下图：

(二). 日志输出

生产代码禁止以该语言所使用的SDK原生的日志打印方式输出日志信息，必须用合理的第三方开源组件（如：log4j）将日志信息进行保存。
对于trace/debuf/info级别的日志输出，应有相应地条件开关，且这些开关参数必须写在相应地配置文件。当系统上线且调试完成后应关闭这些日志输出，否则大量的日志读写会增加系统io负担。
对于error/fault级别的日志输出，严禁有条件开关，但是每次系统上线时应立即将上一版本的错误日志文件删除，避免错误日志过大，影响紧急情况下的故障分析诊断。
在与外部系统对接提交的命令或报文（如：sql语句或者http报文）应使用info级别进行输出。
对于日志的打印，任何情况下都不允许日志错误导致业务失败。

2.3. 注释规范

(一). 基本原则

类：应该包括NewHeight的版权注释、类的作用说明、类的历史版本和修正记录，应使用星标注释法“/** …**/”。
属性：无论何种访问修饰符应对属性的含义进行注释，应使用星标注释法“/** …**/”。
方法：无论当前方法处于何种访问修饰符都应对其功能作用进行注释，应使用星标注释法“/** …**/”。在方法内部逻辑较为复杂的地方也应进行注释说明，应使用斜杠注释法“//”。
属性存取器（getter与setter）：应使用“获取+属性含义”和“设置+属性含义”进行注释，应使用星标注释法“/** …**/”。

2.4. 异常处理

捕捉到的异常，不允许不做任何处理就截断，至少要记入日志，或重新抛出。
在将异常记录至异常日志内时，需将异常堆栈内所有异常信息记入日志内，并按如下格式计入：

时间：XXX ，文件：XXX[最顶级异常发生所在文件名] 发生错误位于：类XXX[最顶级异常发生所在类] 的方法XXX[最顶级异常发生所在方法名]发生异常，行号为：[最顶级异常发生所在行号]，内容为：

调用的类：XXX[n-1层异常发生所在类]. XXX[n-1层异常发生所在方法]发生错误。

最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容。

2.5. 安全规范

(一). WEB安全

每页web具有增删改功能的页面表单需加入防止重复提交功能；
对于前台的web页面，严禁出现方便调试的后门页面。
不允许出现页面向自身重定向、或者多个页面间相互重定向的情况。如果控制不当，很容易造成系统宕机。
不在万不得已情况下，坚持不使用脚本eval函数和setTimeout函数。
每个web应用需配置相关拦截器，拦截请求提交的内容进行特别字符的检测和过滤，例如：<,!,&,一次性将特殊字符进行转换，例如将<替换为<等。
数据输出在页面上时，应使用C标签（<c:out>），禁止使用 EL表达式（&{….}）和jsp表达式。
在页面的最一开始显式地标明Charset，以防止再被插入其它标明字符集的Meta信息，以允许UTF-7攻击。
CSS样式表中禁止包含javascript或expression等可执行组成。
在某些代码扫描平台中，request和response的方法调用被视为不安全代码，但由于逻辑上又需要调用这两个对象的方法，因此建议将request和response需要调用的方法封装在一个jar架包内。
由于spring 框架的视图控制器为单例，因此视图控制器内的成员属性禁止显示实例化，避免数据错乱。
在java类中对某些数据进行加密处理时，应设置密钥长度超过2048个字符。
java类的成员属性如果是用于存储敏感信息，则该属性名称一定不能是易猜测的。属性名禁止以loginName和password这种敏感词来命名。
禁止引入第三方开源插件自带的demo文件。
.html和.jsp页面上禁止出现绝对路径，应该使用相对路径。也禁止使用路径回溯符(../)，以免被攻击后跳出程序本身的限制目录实现任何文件下载。
java后台代码紧致使用sql直接拼接标签值方式，应使用jdbc占位符方式来执行sql，以免被sql注入式攻击。
页面标签的属性值应使用引号括起，以防止属性值没有被引号括起，或某些事件响应函数可以被用户输入所改变。
数据库名应在最前+“#”，以免被攻击者直接通过浏览网页或输入url下载应用的数据库。
Web应用服务器组件部署时，必须变更系统默认的用户名密码，并且关闭常用端口和不必要的端口。
平台（产品）部署时，必须将配置文件内容进行加密，严禁直接存放明文。
平台（产品）必须对输入数据进行严格的客户端验证和服务器验证，防止注入式攻击。
平台（产品）在进行附件上传时，必须对附件进行后缀名验证、大小过滤，并且保存附件的地址严禁存放在web应用服务器组件目录底下，并且尽可能说服客户增设文件服务器，并将上传的附件以HTTP协议传输方式存放至文件服务器上
平台（产品）在登录时尽可能加上验证码做二次校验。

(二). 敏感信息的保护

用户的敏感信息包括密码、短信验证码、支付验证码、身份证号、银行卡号、银行密钥，商户密钥等信息。用户敏感信息不能泄露，否则可能会带来不安全因素。在将用户敏感信息存入数据库时，需进行相应等级的加密成密文，禁止敏感信息已明文存放至数据库。如果用户敏感信息以附件方式导入，将其加密成密文写入数据库后，第一时间将该附件删除。
可能会导致敏感信息泄露的方式有:Logger、URL的get参数（因为URL的get参数会在apache日志中被输出）。
配置文件全内容都需加密，防止被非法获取和篡改。
文件路径尽可能采用根目录物理绝对路径+父目录相对路径+文件名称，对根目录路径进行加密处理。如果能使用网络虚拟路径访问到该文件，就尽可能使用网络虚拟路径。
图片一般不采用路径访问，而应采用流机制访问图片。
对于业务关键字段需要加上防篡改的功能，否则可能造成业务重复执行或者被客户端恶意修改。
对于敏感信息字段根据其隐私程度进行加密保护，加密等级为3级：常规级（如：登录名、身份证、手机号码）、加强级（如：登录密码、账户名）、绝密级（如：支付密码、账户余额、出账金额、入账金额等）。每一加密级别需对应相当的加密机制和防篡改措施。
加解密算法的密钥不能存放在配置文件内，避免配置文件泄漏而导致密钥曝光，应使用类的常量来存放。

2.6. 通用准则

(一). 禁止事项：以下属于“严禁”条例的触犯者会被处以严厉惩罚

方法内的代码行严禁超过50行，应遵守分步实现--整体组合的原则。
禁止无意义的命名，类、接口、方法、属性都必须注释，并且贴近项目需求说明。详见《3.java编码通用标准》内各个小节的《注释》
除了静态类(该类内的所有元素都为静态)外，必须先定义好接口才能编写实现类，对象只能是接口类型。严禁只有实现类未写接口，而且对象是类的类型。
严禁在控制器类组件的方法内出现参数硬编码。应将硬编码存放在参数常量类内（例如后缀名Argument的常量类）。
极力避免在开启事务的连接通道内包含查询操作，应将查询操作挪出该连接通道外。
应尽可能使用批量sql操作，极力避免循环单量sql操作，如下：

严禁针对属性编程，而针对实体对象编程，已提高方法的扩展性。

严禁对sql值拼接，因为会导致sql注入式攻击，应使用sql占位符(?)替换发。

极力避免字符串拼接，应使用占位符替换法（可利用基线库的占位符持久化组件placeholder），提高代码可读性。

严禁使用公有静态的集合变量作为缓存组件，应使用servletContext（简称application）或session等标准的java web服务器缓存，原因为：在高并发时，ArrayList和HashMap不是线程安全，会发生资源抢占、死锁等问题

1.错误的代码示例

严禁将session或servletContext(以下称:application)内数据的保存或读取的代码散落在模块三层控制器内，应针对即将放入session或application的数据实体编写缓存控制器，命名为：实体类名+ Session(Application)。并将缓存控制器类组件放至于工程的架包common内。

1.错误的代码示例

2.正确的代码示例

严禁在同一个开启事务的连接对象内既执行sql语句又执行存储过程。

1.错误的代码示例

(二). 配置信息

对URL、文件路径、文件名称、目录名称、外部系统接口服务路径、分隔符、连接符等全局参数存放至基线库的sf-env-config.xml配置文件中，并利用基线库ConfigManager（配置文件控制器）进行读取，并存放至相应模块配置参数类组件的常量属性内，严禁将这些全局参数直接硬编码至控制器类组件内。
应将视图名称、存储过程名称、触发器等SQL元素参数存放在模块配置参数类组件的常量属性内，严禁将这些参数直接硬编码至控制器类组件内。
将错误状态码值和错误提示文本存放至基线库的sf-status-config.xml配置文件内，并将状态码值存储在模块业务控制器的常量内，严禁直接将错误提示文本直接硬编码至模块类组件内。
对于类型的码值、开关的码值等参数码值应保存至业务控制器的常量内，严禁直接将码值直接硬编码至模块类组件内。

(三). 资源访问

对系统资源的访问，使用后必须释放系统资源。这类资源包括：文件流、线程、网络连接、数据库连接等。
对于文件、网络等IO流操作，必须使用finally关闭并清理资源。建议使用基线库StreamUtil组件进行操作。对于读写的数据要经过编码格式转换，以防止乱码。
对于线程，线程资源必须由基线库的线程池提供，不允许在应用中自行显式创建线程。
对于网络连接与数据库连接，必须由基线库的连接池提供，不允许应用中自行建立网络与数据库连接。
对于二进制数据的流读写操作，应使用BufferInputStream和BufferOutputStream这两个组件操作，对于字符串的流读写，应使用Reader和Writer这两个组件进行操作。建议使用基线库StreamUtil和TxtUtil组件进行操作。

(四). 缓存控制

缓存分为：数据缓存（全局共享缓存和用户独享缓存）与资源缓存。
全局共享缓存只适用于系统全局配置信息与参数、数据字典、地区信息、公共的核心实体信息。
用户独享缓存只适用于用户个人的部分信息（不含隐私性数据或者必须为密文）等少量数据。禁止将大量数据放入独享缓存内。
静态文件都必须使用HTTP服务器进行缓存，静态文件为：css样式文件 \ html文件 \ js脚本文件 \ 图片文件 \ txt文件等。
文件内容数据禁止存放在数据库的大字段内，而应使用文件模块和内容数据生成静态文件。
严禁将绝对路径保存至数据库内，只能保存相对路径。

(五). 表单重复提交

现主流的动态网页(.jsp或.apsx)都采用的MVC架构进行编写，即：将表单提交至后台java侧的视图控制器，由它接收表单报文的标签数据进行后续加工，加工结束后将输出结果推送至页面上。但现主流MVC框架都是采用页面转发机制，因此会造成表单重复提交（典型的案例为：在修改页提交表单后跳转至列表页，进入列表页立刻刷新该页面会导致又一次提交了修改页的表单）。

发生的原因：在页面转发时，浏览器虽然已经将上一次的页面卸载掉，但由于转发会导致地址栏不会被修改成当前页面的路径，因此浏览器会保存上一次页面的表单内容，这是导致表单重复提交的弊端来源。
发生的前提：1.采用页面转发机制。2.进入下一个页面未提交该页面的表单，而是立即刷新该页面。
防止手段：1.采用页面重定向机制。2.使用token方式进行重复表单的校验（例如：spring mvc框架防重复提交的组件就是采用该机制）。

(六). 瞬时双击（瞬时多次提交）

由于传统的表单同步提交的弊端（1.无法表单局部数据提交2.用户需等待无法同步进行其他操作），因此现主流都是采用ajax异步提交数据方式。但由于是异步提交，因此用户可以同步进行其他操作，因此有可能会造成瞬时双击（瞬时多次提交），最典型的案例为：当用户在新增页时点击【保存】按钮后，瞬间再一次点击该按钮，则会发送两次异步请求至服务器侧，最终造成在数据库内出现两条重复数据。

发生的原因：在异步提交时，未阻止提交的事件发生，且服务器处理数据的时间大于两次提交间隔时间。
发生的前提：1.ajax异步提交2.在浏览器未接收到服务器侧对当前异步请求处理后的数据，可以进行下一次异步请求。
防止手段：在异步提交时，采用防双击开关（js全局变量）进行控制。在初始情况下，开关码值为0（表示允许提交），在异步提交时判断该码值是否为0，如果是则将该码值修改为1（表示禁止提交）并进行ajax提交，并弹出提示遮罩层，在接收到服务器响应的数据后（不管结果是success还是error），在将码值恢复为0。

3. java 编码通用标准

3.1. 包

3.1.1. 命名

包名应与模块组件名称或核心实体名称（去除前缀和后缀）一致，例如：

(一) 叶子级模块组件（用户管理）内的核心实体（用户信息）名称为：SG_USER，包名为：user

(二) 一级模块组件（系统设置）无核心实体，所以包名应为：system

(三) 公共模块组件，包名应为：common

包名应该用小写字母，不要出现下划线等符号，名词用有意义的缩写或者英文单词，示例：

//推荐 com.newheight.dao java.lang.util

//避免com.Esse-tech.buSiness

包名长度不应超过10个字符。
一般在应用项目开发内，除了模块组件包的命名，其他类型的组件所在包的命名，如下：

(一) 可为公共的通用的算法工具类组件，包名为：util

(二) 可为公共的适配第三方插件或架包的组件，包名为：adapter

(三) 调用外部或第三方系统接口进行数据交互的组件，包名为：esi

(四) 被外部系统或第三方系统调用的接口服务组件，包名为：bus

3.1.2. 注释

3.1.3. 样式风格

包的导入应该按照相关性进行分组，如下表示：

import java.io.IOException;

import java.net.URL;

import java.rmi.RmiServer;

import java.rmi.server.Server;

import javax.swing.JPanel;

import javax.swing.event.ActionEvent;

import org.linux.apache.server.SoapServer;

3.1.4. 设计准则

包对称的应是功能模块或者技术要点、难点的组件。包不可对应三层架构的层次。例如：将业务逻辑层两个业务控制器类组件（UserService接口、UserServiceImp实现类）归于一个包（service）。
包的层次不应超过5级。
包内文件数量如果没超过2个，则不应建立包。
包的名称应和页面文件夹名称（如果有）一致，相对路径一致。

3.2. 接口

3.2.1. 命名

接口名称使用字母或下划线这两者字符来命名，名称长度不得超过25个字符。
叶子级的业务模块遵循三层架构的数据加工控制器的接口命名应遵循如下命名规则：

(一) 业务逻辑层（业务控制器），接口名为：核心实体名称+Service。

(二) 数据持久层（持久控制器），接口名为：核心实体名称+Dao。

节点级的业务模块的功能外观器的接口命名应遵循如下命名规则：

(一) 外观器，接口名为：包名（首字母大写）+ Service。

接口命名采用接口命名采用Pascal 形式的表示方式，接口如果只有一个实现子类则子类的命名为接口名+Imp。例如：DataAccess , DataAccessImp
使用名词组合或形容词去命名一个接口，接口声明了一个对象能提供的服务，也描述了一个对象的能力。一般以“able”和“ible”作为后缀，代表了一种能力。例如：

public interface Runnable{

public void run();

}

public interface Accessible{

public Context getContext();

}

当前组件不是业务模块也不是能力组件，是针对某类数据或信息进行读取、写入、解析等作用，则命名规则为：信息名称 + Persistence、Reader、Writer、Manager、Resolver、Translator、Converter、Controller、Transmitter。

(一) 后缀名Persistence：各类数据结构（例如：实体bean、xml、json等）之间的结构转换持久化的组件。

(二) 后缀名Reader：读取器，从某几种通道读取某种数据或者从某种通道读取某几种数据。

(三) 后缀名Writer：写入器，将某种数据写入某几种通道或者将某几种数据写入某种通道

(四) 后缀名Controller：控制器，某种数据读写至某几种通道或者某几种数据读写至某种通道

(五) 后缀名Resolver：解析器，从某种数据中提取出某几种信息或者从某几种数据中提取出某种信息。

(六) 后缀名Translator：解释器（译码器），将某几种明文翻译成密文或者某几种密文翻译成明文。

(七) 后缀名Converter：转化器，将某几种数据类型转换成另几种数据类型。

(八) 后缀名Manager：管理器，对某几种资源文件的管理或者某种信息的增删改查管理

(九) 后缀名Transmitter：传输器，某几种资源文件传输至远程服务器进行保存或者某种资源文件保存至几种远程服务器进行保存。

3.2.2. 注释

示例代码如下：

/**

* Persistence表示各种数据结构(bean\map\request\datatable\xml\json)之间持久化器

* @FileName Persistence.java

* @author fish

* @version 1.0.0

* @createTime 2015年5月19日下午8:15:25

* @history

* 1.

* 2.

* 3.

public interface Persistence {

/。。。代码省略。。。。／

}

3.2.3. 样式风格

接口中元素的布局顺序，说明如下：

接口的文档描述
接口的导入声明
接口的静态属性
接口的方法，如果为重载方法，则从参数最少的升序至参数最多的。

3.2.4. 设计准则

应遵循依赖接口编程原则，具有加工行为的组件应先定义接口再有实现类。除非该组件是用于提供简易工具函数（即：该组件只提供静态方法，不提供实例方法）。
接口所定义的方法处理结果如果是状态码或者所需的参数是状态码，应将这些状态码定义成接口常量（默认是public static final 型），不能直接将码值硬编码至实现类内。而像路径参数、字符编码参数等应定义在以后缀名为Argument的常量类内。
接口的设计应遵循一个重要原则：接口隔离原则。
接口的继承关系不应超过2代。

3.3. 类

3.3.1. 命名

名称使用字母或下划线这两者字符来命名，名称长度不得超过25个字符。
类的命名采用接口命名采用Pascal 形式的表示方式，接口如果只有一个实现子类则子类的命名为接口名+Imp。例如：DataAccess , DataAccessImp。
接口如果有多个实现类，那么接口命名应为抽象信息名称+后缀名，实现类（创建工厂）的命名为抽象信息名称+Factory，实现类（具体业务加工）的名称为具体信息名称+Provider。
具有加工行为的控制器类名应为：信息名+后缀名。常见的后缀名如下：

(一) 后缀名Util：工具类，用于提供常用类（如：IO、String、File等）的扩展封装的行为方法。

(二) 后缀名Adapter：适配类，用于提供对第三方系统或第三方架包行为的封装适配的方法。

(三) 后缀名Module：视图控制器，用于提供接收表单输入数据或推送加工结果给页面的http请求处理方法

(四) 后缀名Argument：参数类，用于提供配置参数（如：路径、名称等）常量

(五) 后缀名Factory：工厂类，功能算法的组合者，用于提供接口对象创建的方法和骨架方法。

(六) 后缀名Provider：算法提供者，用于提供骨架方法的核心算法。

(七) 后缀名Handler：处理器，页面组件后台处理器，用于提供将数据打印html片段的方法。

(八) 后缀名Converter：转化器，将某几种数据类型转换成另几种数据类型。

(九) 后缀名Support：基类。

(十) 后缀名Type：类型类，用于提供类型代码常量和类型转换的方法。

(十一) 后缀名Exception：异常类，用于表示特定异常信息的实体。

3.3.2. 注释

示例代码如下：

/**

* PersistenceFactory表示各类数据结构与MAP之间持久化器对象的创建工厂

* @FileName PersistenceFactory.java

* @author fish

* @version 1.0.0

* @createTime 2015年6月29日上午1:34:49

* @history

* 1.

* 2.

* 3.

public class PersistenceFactory implements Persistence {

/。。。代码省略。。。。／

}

3.3.3. 样式风格

类中元素的布局顺序，说明如下：

类的文档描述
类的导入声明
类的静态属性
类的实例属性（从private至protected排序）。
类的静态方法（以private\protected\public排序）。
类的实例方法（以private\protected\public排序）。如果为重载方法，则从参数最少的升序至参数最多的。

3.3.4. 设计准则

应遵循单一职责的设计准则，将类划分为：实体类、控制类、边界类。
边界类：此类为控制类特殊的一种，也称为视图控制器。一般此类既有属性（业务控制器、实体类）也有方法。此类用于接收页面表单或第三方系统提交的输入数据、推送加工结果至页面或第三方系统。
控制类：用于对数据业务加工的类。一般此类只有方法没有属性。此类又细分为三种：视图控制器、业务控制器、数据持久控制器。

视图控制器：也称为边界类，将业务控制器提供的方法进行组合。
业务控制器：用于提供业务逻辑加工方法，即：根据业务需求，对数据进行逻辑判断并将数据持久控制器提供的方法进行组合。
数据持久控制器：用于提供数据读写至存储池（数据库、记事本等硬盘文件）的方法。

实体类：用于临时存储数据的类。此类只有属性没有方法。此类又细分为三种：视图实体类、业务实体类、数据实体类。

视图实体：用于保存页面标签数据，其属性与标签一一对应。本实体命名一般为数据实体+_标签名称简称。例如：数据实体为Department，则装载至页面标签内的视图实体为：Department_cmb。
业务实体：用于保存业务逻辑加工后的数据。
数据实体：用于保存存储池内的数据，其属性与存储池的字段一一对应且同名。

应遵循优先组合而不是继承原则和里氏代换原则，一般继承的家族关系不超过3代。
一般而言，参数类和类型类只有常量和静态方法，工具类、适配器、处理器、转换器只有静态方法。
尽可能使用单例类，而不是静态类（此类只有静态方法），但是作为单例类不应含属性只能含有方法。

3.4. 属性、变量、常量

3.4.1. 命名

属性或变量名称使用字母或下划线这两者字符来命名，名称长度不得超过25个字符。
属性、变量、常量的命名应符合其代表意义。
属性名称不应包含get、set、****is这三个单词。以防止跟属性读写器方法重名。
视图实体的属性名称应与页面标签名称一致，数据实体的属性名称应与存储池的字段同名。
常量名称，使用大写字母，并使用下划线做间隔。例如：MAX_TIMES, DEFAULT_NAME。
变量使用 Camel 表示方式。变量名首字母必须小写，如果该变量名有多个单词组成，后面的单词首字母大写，单词与单词之间不要使用"_"做连接，例如：userName, objectFactory, entrys, list。并且变量的名字应该和类型名称一致

void setTopic(Topic topic) // 避免: void setTopic(Topic value)

// 避免: void setTopic(Topic aTopic)

// 避免: void setTopic(Topic t)

void connect(Database database) // 避免: void connect(Database db)

// 避免: void connect(Database oracleDB)

当同时定义多个属于同一个类的变量时，把类型作为实例的后缀，如：Point startPoint; //这样做是为了从实例名就可以推断它的类型名称。
对于对象集合，变量名称应使用复数。

Collection points; int[] values;

对于抽象类，应该使用 Abstract 前缀。

AbstractReportBuilder，AbstractBeanFactory

对于表示编号的变量，应加 No 后缀。

tableNo, userNo,employeeNo

避免使用否定布尔变量

bool isError; // 避免: isNoError

bool isFound; // 避免: isNotFound

3.4.2. 注释

属性（无论任何访问修饰符）的注释示例如下：

/**

* 用户姓名

private String name ;

常量的注释示例如下：

/**

* 字符编码，默认为UTF-8

public static final String CHARSET = “UTF-8” ;

变量根据需要进行注释，规则为：//

3.4.3. 样式风格

无

3.4.4. 设计准则

属性的访问修饰符一般为private，而且需为该属性配备读写器方法。父类的属性一般为protected，以方便让子类继承使用。
变量声明，采用 Camel 表示法不要在一行声明多个变量。

//推荐

int level;

int size;

//避免

int level, size;

保证明确的类型转换，不要默认进行隐式类型转换

intValue = (int) floadValue; //避免 intValue = floatValue

数组指示符紧跟类型变量

int[] a = new int[20]; // 避免: int a[] = new int[20]

一个变量要代表独立的意思，不要在其生命周期赋予它不同的概念。

int tempValue;

tempValue = maxValue;

…

tempValue = minValue;

…

tempValue = anotherValue;

tempValue 在生命周期内表示了各种各样的意图，增加理解代码的难度。应该为每个独立概念定义单独的变量：

int tempMaxValue;

int tempMinValue;

int tempAnotherValue;

如果变量仅仅出现再for循环体中，则变量应定义在循环头上一行中，而且循环计数变量应定义在循环头部中且命名应有其代表意义。

int sum = 0;

for ( int index = 0 ; index < 100 ; index ++ ) {

sum += value[index];

}

3.5. 方法

3.5.1. 命名

方法名应该使用动词开头，使用 Camel 表示方式,一般由动词+名词组成。首字母必须小写，如果该变量名有多个单词组成，后面的单词首字母大写，单词与单词之间不要使用"_"做连接。单词不要使用名词，例如：getName, initialize, addParameter, deleteUser
方法名不应包含类名的部分单词，如：类名为FileManager，方法名应为save()，// 避免saveFile()和manage()
缩写字母也应该保持首字母大写

exportHtmlSource(); // 避免: exportHTMLSource();

openDvdPlayer(); // 避免: openDVDPlayer();

使用 get／is／set 对类属性进行访问，这是 Java 社区的核心编码规范。有时也可以使用 has，can。例如：

boolean hasLicense();

boolean canEvaluate();

常在一起使用的对称词汇，这些词汇一起使用，方法的表达意图自然可以互相推测和演绎。方法的前缀如下：

属性读写方法：get / is / set

带有是非判断校验行为的方法：is / can / has / exist / check / validate / equals / identify

带有添加、插入等数据追加行为的方法：add / insert / append

带有删除、移除等数据删除行为的方法：delete / remove / eliminate

带有更新、修改等数据替换行为的方法：modify / update / replace / edit

带有查询、加载、查找等获取数据行为的方法：find / query / get / load / fectch / select

带有实例化、创建等资源初始化行为的方法：instance / create / initialize

带有析构、释放等资源销毁行为的方法：dispose / finalize / destroy

带有开始、发起等启动行为的方法：start / begin / launch

带有执行、调用等命令运行行为的方法：/ run / execute / call / order / do / service

带有暂停、挂起等临时停止行为的方法：suspend / stop / shutdown / sleep

带有激活、继续等恢复运行行为的方法：active / resume / renew

带有结束、完结等终止运行行为的方法：end / finish / terminate

带有开启、关闭等开关行为的方法：open / close

带有上传、下载等上下行行为的方法：download / upload

带有显示、隐藏等视图表现行为的方法：show / display / hide / vanish

带有撤销、确定、提交等事件处理行为的方法：cancel / dimiss / confirm / fix / reject / submit

带有推送、提取等栈队列行为的方法：put / push / pop / shift / pull

带有首页、上一条、尾页等游标检索或翻页行为的方法: first / last / up / down / next / previous

带有获取长度、大小等度量获取行为的方法：size / length / min / max / indexOf / count / sum

带有来源和去源等转换行为的方法：to / by / go / from / back / forward

带有读取、写入等输入输出行为的方法：read / write / print / in / out

带有循环、遍历等循环行为的方法：loop / circulate / rotate / repeat

带有递增、递减、生序、降序等排列操作的方法：increase / decrease / ascend / descend / sort

带有序列化行为的方法：serialize / deserialize / encrypt / decrypt

带有提示行为的方法：alert / prompt / hint / mask / tip / confirm

带有存储或持久化行为的方法：save / store / hold

带有连接、分割等线性行为的方法：join / connect / split / divide

3.5.2. 注释

示例如下所示：

3.5.3. 样式风格

方法修饰关键字定义顺序，注意访问修饰符（public, protected, private）一定要在最前面

<访问修饰符 > static abstract synchronized unuaual final native methodName
代码缩进，应该使用 4 个空格为一个单位进行缩进。

public String invoke() throws Exception {

....

String profileKey = "invoke: ";

try {

....

UtilTimerStack.push(profileKey);

if (executed) {

....

test = true;

}

}catch{}

}

条件语句的主要形式，即使单条语句，也要使用括号括起来。

if ( condition ) {

statements;

}

if ( condition ) {

statements;

} else {

statements;

}

空循环体也要使用完整的{}块

for ( initialization ; condition ; update ) {;}

l switch 语句的使用格式

switch (condition) {

case ABC :

statements; //穿透，一定要做出注释

case DEF :

statements;

break;

case XYZ :

statements;

break;

default :

statements;

break;

}

l try-catch 使用格式

try {

statements;

}

catch (Exception exception) {

statements;

}

finally {

statements;

}

空格的使用

运算符两边应该各有一个空格。
Java 保留字后面应跟随一个空格。
逗号后面应跟随一个空格。
冒号两个应各有一个空格。
分号后面应跟随一个空格。

a = ( b + c ) * d ; // NOT: a=(b+c)*d

while( true ) { // NOT: while(true){

doSomething( a, b, c, d ) ; // NOT: doSomething(a,b,c,d);

case 100 : // NOT: case 100:

for( i = 0 ; i < 10 ; i++ ){ // NOT: for(i=0;i<10;i++){ ...

当代码执行逻辑发生切换时应用一空行分开。逻辑上紧密相关的代码块应该用一个空行分开。

当对if 语句中的条件进行折行时，应该使折行的条件语句相对主功能，语句再行缩进 4 个空格，以突出主要功能语句

if ((condition1 && condition2)

|| (condition3 && condition4)

||!(condition5 && condition6)) {

doSomethingAboutIt();

}

//避免使用这种缩进，主功能语句不突出。

if ((condition1 && condition2)

|| (condition3 && condition4)

||!(condition5 && condition6)) {

doSomethingAboutIt();

}

三元条件运算符可以使用如下表达方式，条件要用括号括起来。

alpha = (aLongBooleanExpression) ? beta : gamma;

3.5.4. 设计准则

在方法的代码内应遵循以下几条准则：

方法内的代码行按标准不应超过34行，最大不应超过50行。
子类重写父类方法时应尽可能调用父类方法已实现的逻辑，禁止直接将父类方法代码直接拷贝到子类方法内。
方法应遵循算法与组合分离的原则，N个方法承担步骤的算法算法，一个方法承担步骤的逻辑组合。
方法参数原则上不应超过1个以上的主动体，且方法参数顺序应为：主动体、被动体1、被动2…
如果类内所有方法都含有相同的主动体参数，则应将该主动体参数提升为该类的属性。
私有方法不应在内部直接对属性进行加工处理，而应将属性做为参数传递至方法内部进行处理，此优点具有提高可读性，又可防止相互调用而产生逻辑错误。
算法提供类组件内具有开关性质的方法应在外观类组件内进行适配实现，此准则遵循独立原则，防止开发人员调用外观类组件进行加工，而调用算法提供类组件进行关闭，增加逻辑上的复杂度。
在三层架构中，不应在里层捕获异常，而是向最外层抛出异常，由最外层去捕获异常。
应遵循桥接优先、重载优先准则，应将类型做为方法的参数，而不是方法名部分。如下：

public boolean write( String content ) ;

public boolean write( String content , int type ) ;

//避免 public boolean writeTxt( String content ); public boolean writeExcel( String content );

避免长的布尔表达式，应换成多个更容易理解的表达式。

bool isFinished = (elementNo < 0) || (elementNo > maxElement);

boo- isRepeatedEntry = elementNo == lastElement;

if (isFinished || isRepeatedEntry) {

…

}

// 避免

if ((elementNo < 0) || (elementNo > maxElement)|| elementNo ==lastElement) {

…

}

不要在条件语句中执行方法，以提高可读性

InputStream stream = File.open(fileName, "w");

if (stream != null) {

…

}

//避免

if (File.open(fileName, "w") != null)) {

…

}

在对列表、字典等集合数据进行遍历时，应尽可能使用迭代器或for each进行遍历，而不应使用索引号进行遍历。

for( Object bean : list ){} //避免 int size = list.size(); for( int index = 0 ; index < size ; index++ )

**
**

4. JS编码通用标准

4.1. 文件

4.1.1. 命名

文件名称使用字母或下划线这两者字符来命名，名称长度不得超过10个字符。
基线库的脚本文件以sf_最为前缀，业务项目通用的js文件（存放于common/js目录）以c_最为前缀，模块的js文件以m_作为前缀且用当前目录为名称（例如：当前模块页面所在的目录为dm，则该模块的js文件名称为m_dm）。

4.1.2. 注释

由于js文件可包含N个类，因此文件注释应说明本js文件提供哪些方面的功能组件，示例如下：

4.1.3. 样式风格

无

4.1.4. 设计准则

一般而言，js文件作用类似于java的架包，可将处理同一层面的类组件归结在同一个js文件内。
在页面中应只导入有用的js文件，而不是全部js文件。

4.2. 类

4.2.1. 命名

类名称使用字母或下划线这两者字符来命名，名称长度不得超过15个字符。
基线库的脚本类以SF_最为前缀，业务项目通用的脚本类（存放于common/js目录）以C_最为前缀，模块的脚本类以M_作为前缀且用当前目录为名称(首字母大写)（例如：当前模块页面所在的目录为user，则该模块的js文件名称为M_User）。
类名后缀参考3.3类／3.3.1命名。

4.2.2. 注释

示例如下：

4.2.3. 样式风格

类中元素的布局顺序，说明如下：

类的文档描述
类的实例属性
类的静态属性
类的静态方法（以private \public排序）。
类的实例方法（以private \public排序）。如果为重载方法，则从参数最少的升序至参数最多的。

4.2.4. 设计准则

模块前台页面操作所需的js函数都应归结至模块脚本类内。该脚本类应只包含实例方法。
所有模块共有的js函数都应归结于项目脚本类内，该类只包含静态方法。
一般而言，js脚本类组件只为控制类，如果需使用实体类来保存表单标签值或者后台加工结果，则该实体类应使用对象字面量来表示，而且该实体类定义在控制类相关的方法内或者定义为控制类属性内。
匿名类应谨慎使用。
应使用function来定义类，禁止使用new Function来定义。
在继承父类时，应使用父类的call方式来继承父类属性、使用基线库脚本类SF_Object方法extend来继承父类实例方法。

4.3. 函数

4.3.1. 命名

函数名称使用字母或下划线这两者字符来命名，名称长度不得超过15个字符。
由于脚本函数没有访问修饰符，因此只能使用命名格式来区分公共方法和私有方法。私有方法一般为方法名前后加下划线表示。如：

函数名后缀参考3.5方法／3.5.1命名。

4.3.2. 注释

由于js函数没有重载的概念，参数和返回值没有实现定义类型，因此注释变得极其重要，应遵循如下注释风格：

4.3.3. 样式风格

参考 3.5.3样式风格。

4.3.4. 设计准则

应尽可能使用jquery框架和基线库脚本库来编写方法内的代码，以此来规避浏览器兼容性问题。
函数应归属于类，禁止建立全局函数。
由于脚本类组件是使用函数来定义的，因此函数要么只能定义成类，要么只能定义成方法。不能两者兼备。
由于脚本函数没有重载机制并且参数无类型定义，因此只能使用注释来区分函数的形参为必填或者选填，还有形参是何种类型。因此函数定义时应将必填参数排在最靠前，选填参数排在最靠后。
由于函数没有明确返回值及其类型定义，因此也必须使用注释来说明。并且返回值应遵循类型不变原则，禁止返回值为一种类型以上。
判断参数、变量是否为空时，要使用多种空表示的组合进行验证，因此必须使用基线库脚本库内的数据类型操作组件来进行空值判断。如：null、undefined、NuN。
函数内部使用this指针时应特别小心，防止使用call方法调用该函数时而改变this指针的指向。
禁止使用eval函数。

4.4. 属性、变量、常量

4.4.1. 命名

这三者名称使用字母或下划线这两者字符来命名，名称长度不得超过10个字符，并且常量应都为大写。
参考3.4.1命名

4.4.2. 注释

参考3.5.1注释

4.4.3. 样式风格

无

数据库设计标准

1. 引言

1.1. 背景

数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求，因此构建规范的数据库工程技术规范是必然的也是必需的。

为了优化数据库的设计，提高数据库设计的合理性和数据访问高效性，同时便于阅读和理解数据库的结构，以提高数据共享的质量和效率，促进数据库编码的标准化，特制订一套数据库设计规范。本规范通过对建库的名称、结构、建库过程、性能优化、安全措施等几个技术方面的约定，目的就是提供一套规范、合理、科学的建库技术体系。

1.2. 规范级别定义

根据实际情况分为2类等级的规范：

Ø 推荐规范：推荐规范即非强制规范，只是推荐和鼓励开发维护人员实施的规范

1.3. 规范实施建议

Ø 制定统一的元素命名规范。

Ø 建立字段类型的使用标准

Ø 建立SQL、索引、存储过程、自定义函数等元素的编写规范和约束条件

Ø 设定数据库逻辑设计和物理设计的标准。

1.4. 术语定义

范式

关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的第一范式，简称1NF。在第一范式中满足进一步要求的为第二范式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。

关联

关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同时间的数据项之间和表实体本身之间，构成了数据库规范化的基本核心问题。它分为一对一、一对多、多对多这三种关联形式。

关系模型

关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在关系模型中、实体与实体之间的联系都是用关系来表示的。

视图

视图是一个定制的虚拟表，可以是本地的、远程的、带参数的；其数据可以是来源于一个或多个表、或者其他视图；它是可更新的，可以引用远程表；它可以更新数据源。视图是基于数据库的。

约束

数据库管理系统必须提供一种机制来检查数据库中的数据，看其是否满足语义规定的条件，这些加在数据库数据之上的语义规范，称之为约束。约束又可以分为完整性约束、唯一性约束、外键约束等。

主键

每张表都应该包含相同的一个或一组字段，他们都是保存在表的、每一条记录的唯一标识，通常这些字段（即：主键）需要在建立数据表时就设定并标记。而且主键的值具有不可更新性（即：用户不可编辑）必须有一定生成规则，且不依赖用户业务规则。例如：系统中展现的会员ID尽可能不作为主键，虽然它是唯一，因为会员ID的生成规则是依赖用户业务需求。

外键

外键是一个关系中的一组属性（一个或多个列），它同时也是某种关系的主键。它是关系之间的逻辑连接点。一般现代的数据库工程建设中，只在概念模式（E-R图）中体现出外键，在外模式（表）中不设定外键，缘由于数据库迁移时由于外键约束导致迁移失败。

1.5. 参考

【暂无】

**
**

2. 数据库工程

现代的信息化系统里数据库是最重要的组成部分，也是整个系统的核心。数据库从设计到实施、测试，都围绕着三层模式在进行，即：概念模式、内模式、外模式。数据库建设应符合工程流程，如下图：

![img](file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml\wps6B34.tmp.jpg)

需求分析阶段应综合业务系统的应用需求，形成规范的需求调查表、需求规格书、功能需求表，有可能还可以提供著录返利。
在概念设计阶段形成独立于机器特点、独立于各个数据库管理系统产品的概念模式，用E-R来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。
然后根据用户处理的要求你，安全性的考虑，在基本表的基础上建立必要的视图形成数据的外模式。
在物理设计阶段根据数据库管理系统的特点和处理的要求，进行物理存储安排，设计索引，形成数据库的内模式。
建库过程的每一步都是对其前一步骤的检验，对于发现的错误或偏差需要进行及时的评估，并进行修正完善。

2.1. 工程结构

研发团队应挑选一款应用软件来建设数据库工程，管理这些工程文件，推荐使用市面上主流的数据库设计工具PowerDesigner（以下简称：PD工具），下图为数据库工程结构的截图（注：工程名称格式，项目名称_db）：

![img](file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml\wps6B35.tmp.jpg)

RelationStructs：用于绘制、显示E-R图的实体关系图（概念模型）的工作区。
OtherStructs：用于存放视图、存储过程、序列、触发器、自定义函数等其他组件的工作区。
SqlFile：用于存放从数据库导出的SQL脚本代码文件的工作区
TableStructs：用于设计E-R图的实体属性图，即：实体表（逻辑模型）的工作区，从该工作区可以导出已经设计的虚拟表的SQL语句，置入数据库执行，从而完成物理表的生成。
Tables：一旦开始设计虚拟表，PD工具自动生成的文件夹，用于存放已设计的虚拟表。
Views：一旦开始设计视图，PD工具自动生成的文件夹，用于存放已设计的视图。
Procedures：一旦开始设计存储过程，PD工具自动生成的文件夹，用于存放已设计的存储过程。
Files：一旦建立SQL文件，PD工具自动生成的文件夹，用于存放已创建的SQL文件。

2.2. 实体关系图

实体关系图是根据业务需求绘制而成，用于描述系统的概念模型，体现出各个实体之间的关联关系，加深研发团队对需求理解的正确性，保证数据的完整性，绘制该图时需遵守如下准则：

不能出现孤立的实体，即：无关联关系的实体。
在两个实体关联关系中，要体现出关联形式（几对几的关系）。
图示需完整的描述出系统的概念模型，不能片面绘制，即：只描述出系统的某些模块。
由于业务系统是由各个应用程序端组成，因此图示应以各个应用程序端分开绘制。
本图示十分重要，因此必须进行严格的评审。

本图存放在RelationStructs工作区内，如图例：

![img](file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml\wps6B36.tmp.jpg)

2.3. 其他组件

由于业务系统数据的重要性，在性能、安全性、兼容性等方面都对数据库建设工程提出了较高要求，这就导致不仅仅只使用数据库建表技术，而需要数据库其他组件配合共同完成。这些组件为：

视图，一般用于简化SQL查询语句和确保数据表的隐蔽性。
自定义函数，在SQL语句中不可直接使用数据库自带函数，应使用自定义函数对自带函数进行封装，SQL语句中调用自定义函数，这样就能保证应用端程序能跟数据库脱耦。
存储过程，提高复杂SQL语句执行的效率。
序列，Oracle特有
触发器

应在数据库系统中编写这些组件的脚本内容，并将这些组件的基本信息（名称、作用说明）记录至OtherStructs工作区内。如图：

![img](file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml\wps6B37.tmp.jpg)

2.4. SQL脚本

保存从数据库导出的SQL脚本内容，保存在SqlFile工作区。SQL脚本名称为：创建者_创建日期，如图：

![img](file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml\wps6B38.tmp.jpg)

2.5. 实体表

实体属性图保存在TableStructs工作区内，由于本图示为建表的重要环节，因此必须准守以下几个原则：

定义主键时，要写好生成规则，但不能依赖用户业务规则。例如：展现在界面的会员ID或者员工工号，不应作为主键。主键是用来标识一条记录。
在设计字段时，要区分该字段是：主键、唯一键（例如：会员ID）、常规键、自动键（值为自动递增），块级键。
在设计字段的数据类型时，原则上只使用字符型（varchar或nvarchar）、日期型(date)，不使用数字型(int或double或float)，因为使用数字型后一旦需求上要求精度发生变化会导致系统异常。如果字段为日期型时，应写明日期的格式。
要谨慎使用块级字段（大字段），原则上一张表只能有1个大字段，有时为了提高检索效率，可将大字段从主表脱离出形成一张次表。
在设计字段的数据长度时，跟根据实际需求做些适当增加，不可所有字段都是同样长度。尤其是对于数字型的字段要保持足够的长度来容纳数字的精度。

![img](file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml\wps6B39.tmp.jpg)

**
**

3. 库

3.1. 命名规范

Ø 库名构成：WS_<项目名称英语单词的缩写>

Ø 库名全部使用大写且长度不得超过15个字符。如果太长，请使用单词的缩写。

Ø 库名称不能使用汉字或者使用中文拼音、中文拼音的首字母或者阿拉伯数字。

Ø 保证库名称没有和保留词、数据库系统或者常用访问方法冲突。

Ø 绝对不能在库对象名称的字符之间留空格。

**
**

4. 表

4.1. 命名规范

Ø 表的中文名称为：表的描述（表的作用），表的英文命名则根据表的附属不同而不同，如下说明：

如果当前表归属于应用项目的模块则，英文名称：

1.主表：SH_<一级模块的英语单词缩写>_<表中文名称的英语单词缩写>

2.次表：SH_<一级模块的英语单词缩写>_<表中文名称的英语单词缩写>_NX

如果当前表归属于独立的处理引擎或者服务总线，则英文名称：

主表：SE_<引擎名称英语单词的缩写>_<表中文名称的英语单词缩写>
次表：SE_<引擎名称英语单词的缩写>_<表中文名称的英语单词缩写>_NX

如果当前表归属于基线库，则英语名称为：

主表：SF_<表中文名称的英语单词缩写>
次表：SF_<表中文名称的英语单词缩写>_NX

Ø 表名全部使用大写且长度不得超过10个字符。如果太长，请使用单词的缩写。

Ø 表名不能使用汉字或者使用中文拼音、中文拼音的首字母或者阿拉伯数字。

Ø 保证表名称没有和保留词、数据库系统或者常用访问方法冲突。

Ø 绝对不能在名称的字符之间留空格。

4.2. 注释

Ø 用中文说明该表的用途，并尽量提供以月为单位该表数据量的大约变化量。

4.3. 设计规则

Ø 表的设计应该符合第三范式的规则，但不应过分追求，应做适当的冗余。

Ø 表应有唯一的主键，原则上不允许使用复合主键。主键的数据值原则上不允许使用UUID32位随机字符串，而是设定一定规则来生成主键的数据值，最低级的规则为：<表中文名称的英语单词缩写>_序列号。

Ø 表如果包含多个大字段（blob或者clob），则应进行分割。将常规类型的字段归结到一张表（主表），将大字段类型的字段归结另一张表（次表）。次表与主表的主键名称和主键的数据值必须完全一致。

Ø 一般表内行的总数不要超过1000万条，如果已预见到会超过，则应在设计时就应考虑如何横向切割表。

Ø 如果当前表为星型中心表，则该表应增设用于记录子表总行数的字段，用以方便关联信息记录的统计。且子表的主键值与父表的主键值许设定关联生成规则，如：父表主键值为UD001，子表主键值为UD001_UK001。

Ø 如果当前表存放的历史数据或不参与经营加工的数据，应设定一段时间将表的数据迁移到历史表的方法或自动化机制。

Ø 如果当前表为树型结构，遵循树型表的规则（ID，父ID，排序、级别），ID与父记录ID、排序与父排序，这二者需设定关联生成规则。

Ø 除非有特殊要求，否则不应设置主外键约束，防止后期迁移产生的问题。

**
**

5. 字段

5.1. 命名规范

Ø 命名结构：<表中文名称的英语单词缩写>_<字段中文名称的英语单词缩写>。

Ø 当前字段为主键，则名称为ID。

Ø 当前字段为外键，则命名结构为：<关联的表中文名称的英语单词缩写>_ID。

Ø 字段名不能使用汉字或者使用中文拼音、中文拼音的首字母或者阿拉伯数字。

Ø 字段名称应全库唯一且全部大写，命名尽可能符合中文意义，且不同单词之间使用"_"。

Ø 字段名不得超过15个字符，如果太长，请使用单词的缩写。

5.2. 设计规则

Ø 除非有特殊要求，否则除大字段类型之外，所有字段的类型应为nvarchar类型。

Ø 明显不能为空的字段必须禁止为空，例如：年龄。

Ø 可以为空的字段应根据实际情况，设定该字段的默认值。

Ø 具有序号含义的字段应尽量采用自增序列号，可以有效避免重号和跳号。

Ø 如果某列的值是通过数学运算从本行中其他列得到，可以采用计算列功能实现，以减少前端代码编写工作量，但计算逻辑不应过于复杂。

Ø 除非该字段表示为路径，则可以用分隔符连接成字符串存放至该字段，否则所有字段不能用分隔符连接多行数据，因为违反“不可分割”的原则。

Ø 主键，值不可更新（用户不可编辑），值的生成规则不依赖业务规则或者具备业务用途。原则上不允许使用复合主键。主键的数据值原则上不允许使用UUID32位随机字符串，而是设定一定规则来生成主键的数据值，最低级的规则为：<表中文名称的英语单词缩写>_序列号。

**
**

6. 序列

6.1. 命名规范

Ø 命名结构：WS[ SE | SF ]SEQ<表名，去除前缀“WS”“SE”“SF”>

Ø 序列名称不能使用汉字或者使用中文拼音、中文拼音的首字母或者阿拉伯数字。

Ø 字段名不得超过15个字符，如果太长，请使用单词的缩写。

6.2. 设计规则

Ø 序列的最大值和最小值必须明确，而且序列值的累加值一般为1。

Ø 数据库迁移前的序列值为数据库迁移后序列的最小值。

**
**

7. 视图

7.1. 命名规范

Ø 命名结构：SH[ SE | SF ]V<视图中文名称的英语单词缩写>

Ø 视图名称不能使用汉字或者使用中文拼音、中文拼音的首字母或者阿拉伯数字。

Ø 字段名不得超过15个字符，如果太长，请使用单词的缩写。

7.2. 注释

用中文说明该视图的用途、该视图的基表以及是否可以通过该视图修改其基表

7.3. 设计规则

Ø 不要使用SELECT * 语法建立视图，以避免基表结构发生变化时，使用该视图不能得到期望的数据。

Ø 生成视图的SQL Query必须要有WHERE子句，以限制视图中的数据量。

Ø 只能在当前数据库中创建视图。

Ø 不允许在视图之上再建立视图。

Ø 定义视图的查询不可以包含ORDER BY、COMPUTE或 COMPUTE BY子句或INTO关键字。 l不能创建临时视图，也不能在临时表上创建视图。

Ø 可以考虑利用视图索引提高性能。

**
**

8. 存储过程

8.1. 命名规范

Ø 命名结构：SH[ SE | SF ]P<存储过程中文名称的英语单词缩写>

Ø 视图名称不能使用汉字或者使用中文拼音、中文拼音的首字母或者阿拉伯数字。

Ø 字段名不得超过15个字符，如果太长，请使用单词的缩写。

8.2. 注释

在存储过程create语句之后、第一行可执行语句之前，必须要有该存储过程的功能说明，包括如下内容：

/*******************************************/

/* 中文名称： */

/* 功能描述： */

/* 输入参数名称含义类型默认值 */

/* */

/* 返回值含义 */

/* 编写人：编写时间： */

/* 修改人：修改时间： */

/* */

/*******************************************/

8.3. 编码规则

Ø 全部存储过程的编码由一对BEGIN。。。END括起来。

Ø 代码行的长度不得超过一屏。续行以SQL关键字或运算符号打头。

Ø 每个结构化语句块都应该有注释。如果是循环结构，必须有可到达的结束条件。续行、结构化语句应比其上一级语句缩进编写。

Ø 应按照相同的顺序访问多个表或视图，以减少资源的竞争，避免阻塞或死锁。

Ø 如果存储过程的作用是提供检索结果，那么不要使用SELECT * 的形式提供，应明确写出相关的列名。

8.4. 异常处理

Ø 使用TRY…CATCH捕获错误，进行处理

**
**

9. 索引

9.1. 命名规范

Ø 命名结构： [ IX | UIX ]_ <字段英文名称>，其中：IX表示索引列不是主键或外键，或者是复合索引。UIX表示唯一索引。

9.2. 设计规范

Ø 在考虑是否为一个列创建索引时，应考虑被索引的列是否以及如何用于查询中。

Ø 返回大结果集（与源表数据相比）的查询不会使用非聚簇索引。

Ø 一个表如果建有大量索引会影响 INSERT、UPDATE 和 DELETE 语句的性能，因为在表中的数据更改时，所有索引都须进行适当的调整。另一方面，对于不需要修改数据的查询（SELECT 语句），大量索引有助于提高性能，因为 SQL Server 有更多的索引可供选择，以便确定以最快速度访问数据的最佳方法。

Ø 在查询经常用到的所有列上创建非聚集索引。比如：日期列。1.在FOREIGN KEY列上建立索引。2.在Order By的列上建立索引。3.在范围查询的列上建立索引。4.在精确匹配查询的列上建立索引。

Ø 覆盖查询可以提高性能。覆盖查询是指查询中所有指定的列都包含在同一个索引中。创建覆盖一个查询的索引可以提高性能，因为该查询的所有数据都包含在索引自身当中；检索数据时只需引用表的索引页，不必引用数据页，因而减少了 I/O 总量。尽管给索引添加列以覆盖查询可以提高性能，但在索引中额外维护更多的列会增加更新和存储成本。

Ø 对聚集索引使用整型键。另外，在唯一列、非空列创建聚集索引可以获得性能收益。

Ø 在基数集很小的列上一般不创建索引，比如性别。

Ø 填充因子会影响数据表的更新性能，因此对于更新频繁的数据表，请选择一个恰当的填充因子大小，一般情况下选择 80 即可满足大多数需求。

**
**

10. 用户自定义函数

10.

10.1. 命名规范

Ø 命名结构：F_<函数英文名称>。

10.2. 注释

在用户定义函数create语句之后、第一行可执行语句之前，必须要有该用户定义函数的功能说明，包括如下内容：

/*******************************************/

/* 中文名称： */

/* 功能描述： */

/* 输入参数名称含义类型默认值 */

/* */

/* 返回值含义 */

/* 编写人：编写时间： */

/* 修改人：修改时间： */

/* */

/*******************************************/

10.3. 编码规则

Ø 全部用户自定义函数的编码由一对BEGIN。。。END括起来。

Ø 代码行的长度不得超过一屏。续行以SQL关键字或运算符号打头。

Ø 每个结构化语句块都应该有注释。如果是循环结构，必须有可到达的结束条件。续行、结构化语句应比其上一级语句缩进编写。

Ø 应按照相同的顺序访问多个表或视图，以减少资源的竞争，避免阻塞或死锁。

Ø 如果用户自定义函数的作用是提供检索结果，那么不要使用SELECT * 的形式提供，应明确写出相关的列名。

10.4. 异常处理

Ø 使用TRY…CATCH捕获错误，进行处理

**
**

11. 触发器

11.

11.1. 命名规范

Ø 命名结构：T [B | A][ I | U | D ]_<表英文名称>，其中：

B ：Instead Of触发器

A ：After触发器

I ：Insert触发器

U ：Update触发器

D ：Delete触发器

11.2. 注释

在触发器create语句之后、第一行可执行语句之前，必须要有该触发器的功能说明，包括如下内容：

/*******************************************/

/* 中文名称： */

/* 功能描述： */

/* 编写人：编写时间： */

/* 修改人：修改时间： */

11.3. 编码规则

Ø 因触发器对性能影响非常明显，触发器的建立必须经过项目经理、架构、DBA共同讨论通过，确认可以使用。

Ø 全部触发器的编码由一对BEGIN。。。END括起来。

Ø 代码行的长度不得超过一屏。续行以SQL关键字或运算符号打头。

Ø 每个结构化语句块都应该有注释。如果是循环结构，必须有可到达的结束条件。续行、结构化语句应比其上一级语句缩进编写。

Ø 应按照相同的顺序访问多个表或视图，以减少资源的竞争，避免阻塞或死锁。

Ø 由于存在对性能的潜在负面影响，禁止在触发器中使用游标，并尽可能的简化触发器的处理逻辑。

Ø 使用基于行集的逻辑而非游标来设计影响多行的触发器。

Ø 不允许使用递归触发器。

11.4. 异常处理

Ø 使用TRY…CATCH捕获错误，进行处理。

**
**

12. 数据库工程通则

12.1. 设计原则

数据库层次分明，布局合理

1. 不应针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。

2. 采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。

高度结构化，数据标准化、规范化

1. 根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字****。

2. 当心被分隔符分割的数据，它们违反了“字段不可再分”********原则。

3. ****中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。

冗余合理设计，维护数据的一致性、正确性

1. 表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。

2. 如果性能是关键，不要固执地去避免冗余********。

3. ****非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。

4. ****一个表中组合主键的字段个数越少越好。

5. ****主键PK的取值方法：可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。

6. 设计出的表要具有较好的使用性，主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧

设定必要的安全性

1. ****坚持数据库审计原则。

2. **** 确定文件的访问控制。确保文件不会被人修改、删除。这些文件包括数据库系统文件、数据库文件、日志文件以及备份文件等。

3. ****数据库管理账号按权限划分等级。

4. ****对数据库内按安全级别对敏感信息进行加密处理。

5. ****定期对数据库进行防灾备份，尽可能3天全量备份每天增量备份

12.2. 性能优化

在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。
发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键 PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。
temp数据库的性能的好坏影响到此台服务器的所有数据库，故temp数据库的性能非常重要，建议temp数据库与业务数据库文件分别存储在不同的磁盘，以提升性能。
数据文件与日志文件分开存储。
建立多个文件组或数据文件，如果有多个物理磁盘，文件可以存放在不同的物理磁盘上，一可以不受到系统单个文件大小的限制，二是可以把压力负载到各个磁盘提升性能。
单个表的索引最好不要超过5个，记录重复多的字段没有建立索引的必要，表的主外键需要建立索引，适当建立覆盖索引，每个表必须建立聚集索引，选择最小惟一的字段。
连接查询时最好不要超过4个表，尽量在连接表上加上筛选条件。
字段尽量不允许为NULL，因为如果允许为NULL的话，数据库要多做一些工作而影响性能。
在执行UPDATE和DELETE语句时，WHERE过滤条件尽可能为主键，如果不是则应当将过滤条件作为组合索引，否则很容易发生死锁。
应尽量避免在 WHERE 子句中使用OR、IN、NOTIN来连接条件，否则将导致引擎放弃使用索引而进行全表扫描。如果避免不了则应该为过滤条件建立索引，将OR优化成IN，如果没有索引，IN的性能要远远优于OR。但是IN内的值最多为1000个(Oracle)，因此使用IN来连接条件时必须慎重。

使用"union all"的性能比"union"更高一些。因为当SQL 语句需要UNION两个查询结果集合时，这两个结果集合会以UNION-ALL的方式被合并，然后在输出最终结果前进行排序。如果用UNION ALL替代UNION，这样排序就不是必要了，效率就会因此得到提高。

UI/UE标准

1. 目的

为解决公司生产的软件存在布局、操作、用户体验等UI/UE上的问题，特此设定本规范，

2. 鼠标

(一). 鼠标放置在超链接、折叠扣、分页选项标签等具有引导向作用的区域，该鼠标应变为手柄状，或者区域应有明显的变化。如高亮显示、字体变大、背景色发生改变。

(二). 鼠标移至列表行或者列表块等列表区域时，该列表区域的样式要区别于其他列表区域。如：如高亮显示、字体变大、背景色发生改变。

(三). 鼠标移至文本输入控件时，会再控件下放出现输入格式提示信息且控件边框高亮显示。

3. 页面与表格

(一). 列表各字段列宽度要适合，不亦太小，也不要太宽显示。

(二). 字段列表大部份信息都靠左对齐，但同样宽度的数据要居中。如性别，手机号等固定宽度的数据都要居中。

(三). 列表一行之多3个【图片按钮】，且必须居中。如采用【链接性文字按钮】则居左显示。

(四). 列表信息过长时，列表应该显示前15个字符信息+…（点）+鼠标放上去要显示全部信息。

(五). 默认一个页面数据显示10条数据信息。

(六). 如果列表一行内包含两个按钮以上，强烈建议使用区块标签来展示。

4. 信息提示

(一). 在执行新增功能之后，如在无特别要求情况则页面应跳转至列表页面，且进行操作成功与否的信息提示（淡化效果）。

(二). 在执行修改功能之后，如无特别要求情况下页面应跳转至被修改行所在的列表页面，且被修改行背景应高亮显示和作成功与否的信息提示（淡化效果）。

(三). 在执行删除功能时，应先弹出警示信息用户确定后方可执行删除功能。若数据为当前页（不是首页）最后一行则在删除之后应跳转至上一页，其它则停留在当前页。并且进行操作成功与否的信息提示（淡化效果）。

(四). 对输入值进行错误验证时，出错提示要言简意赅，尽量限制在5个汉字内，平且字体以红色显示在输入框的后面。

5. 排序与分页

(一). 在进行数据多行分页展现时，默认情况下每页显示10行且以字段“创建时间”降序排列。

(二). 排序类型、方式下拉框无需加横线或双横线，直接显示排序类型名、方式名。

(三). 当在非第1页面进行排序时，排序成功后自动跳到第1页。

6. 操作区域与布局

(一). 在页面布局时，应采用区域划分法。根据数据展现、功能操作、操作注解等需求进行合理划分区域。区域包含两个子元素：标题和内容。

(二). 如果内容的展现宽度和高度过大，则应使用分页标签、折叠、缩略这三种方式对内容展示区进行缩减。

(三). 区域与区域的边框应保持对齐。

7. 文本输入控件

(一). 当输入的数据已达到超过文本输入控件的最大字符长度时，则数据无法再录入。

(二). 各输入文本框都要在文本框上提示，文本框输入信息后，鼠标放上去，可产生信息提示。

(三). 查询操作区域的查询条件下拉框默认显示“请选择”。

8. 点选控件

(一). 在单击点选控件之后，如果执行数据新增、删除、修改这三类功能之后，则应进行相应的跳转和提示（详见：4.3信息提示）。

(二). 执行添加操作的点选控件名称默认为【保存】。在添加完数据之后，如无特别要求情况下页面要返回列表页的第一页，新增的数据应该展现在第一条（默认按创建时间、降序显示）。

(三). 执行修改操作的点选控件名称默认为【保存】。在修改完数据之后，如无特别要求情况下页面应跳转至被修改行所在的列表页面。例如：如在第2页的第3条，即第23条数据，修改完后，页面应该回至第2页，第3条数据高亮显示。

(四). 执行删除操作的点选控件名称默认为【删除】。在删除数据同时，应弹出警告窗口在用户确认后在执行删除功能。若数据为当前页（不是首页）最后一行则在删除之后应跳转至上一页，其它则停留在当前页。

(五). 执行批量删除操作的点选控件默认为【批量删除】。在执行批量删除功能时，应判断用户是否勾选复选框，如没有则弹出警告提示，如已勾选应弹出警示信息让用户确认后方可执行删除功能。在数据被删除之后，列表应重新加载数据并返回第一页。

(六). 如若数据固定的少量选项，则应使用单选按钮。如性别，婚姻情况

9. 重复提交

(一). 当页面操作要转入后台执行程序代码时，应锁住操作控件防止用户二次提交。如：点击按钮后将按钮的可用状态位设置为“不可用”。

10. JS脚本

(一). 页面操作所需的JS脚本代码必须编制在JS脚本文件中，在操作页面链接该JS脚本文件。

(二). 通用的JS脚本文件统一放在/common/script下，js脚本名称结构为C_<自定义名称>。

(三). 各模块所需的个性化JS脚本文件存放在模块目录内，JS脚本文件名称为M_<模块目录>

11. CSS样式

(一). 页面操作所需的CSS样式代码必须编制在CSS样式文件中，在操作页面导入该CSS样式文件。

(二). 通用的JS脚本文件统一放在/common/style下，css样式文件名称结构为C_<自定义名称>。

各模块所需的个性化CSS样式文件存放在模块目录内，CSS样式文件名称为M_<模块目录>。

预期目标

完成应用端的系统模块、个人中心、二手交易市场、校园信息墙

posted @ 2022-05-31 20:33 比奇堡的小机灵鬼阅读(30) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

代码规范与冲刺计划

工程编码标准

1. 引言

1.1. 背景

1.2. 规范级别定义

1.3. 规范实施建议

1.4. 参考

2. 代码工程 通则

2.1. 操作规范

2.2. 日志规格

2.3. 注释规范

2.4. 异常处理

2.5. 安全规范

2.6. 通用准则

3. java 编码通用标准

3.1. 包

3.1.1. 命名

3.1.2. 注释

3.1.3. 样式风格

3.1.4. 设计准则

3.2. 接口

3.2.1. 命名

3.2.2. 注释

3.2.3. 样式风格

3.2.4. 设计准则

3.3. 类

3.3.1. 命名

3.3.2. 注释

3.3.3. 样式风格

3.3.4. 设计准则

3.4. 属性、变量、常量

3.4.1. 命名

3.4.2. 注释

3.4.3. 样式风格

3.4.4. 设计准则

3.5. 方法

3.5.1. 命名

3.5.2. 注释

3.5.3. 样式风格

3.5.4. 设计准则

4. JS编码通用标准

4.1. 文件

4.1.1. 命名

4.1.2. 注释

4.1.3. 样式风格

4.1.4. 设计准则

4.2. 类

4.2.1. 命名

4.2.2. 注释

4.2.3. 样式风格

4.2.4. 设计准则

4.3. 函数

4.3.1. 命名

4.3.2. 注释

4.3.3. 样式风格

4.3.4. 设计准则

4.4. 属性、变量、常量

4.4.1. 命名

4.4.2. 注释

4.4.3. 样式风格

数据库设计标准

1. 引言

1.1. 背景

1.2. 规范级别定义

1.3. 规范实施建议

1.4. 术语定义

1.5. 参考

2. 数据库工程

2.1. 工程结构

2.2. 实体关系图

2.3. 其他组件

2.4. SQL脚本

2.5. 实体表

3. 库

3.1. 命名规范

4. 表

4.1. 命名规范

4.2. 注释

4.3. 设计规则

5. 字段

2. 代码工程通则