3.开发原则与约束.docxVIP

开发命名规范版本信息* A代表新增，M代表修改，D代表删除；版本号发布日期提交人审阅人A.M.D更新位置更新摘要V1.02014-07-26李健进A拟初稿V1.12014-08-22李健进A2.8增加系统安全性内容V1.22014-08-28李健进M精简部分重复无意义描述V1.32014-09-03李健进A2.6增加异常捕捉内容V1.42014-09-15李健进A3增加数据库规范中部分内容V1.52014-10-27李健进A2.1.2 3.1.2增加对MVC各层作用的描述与主键生成策略约束目录1.前言51.1.目的范围51.1.1.目的作用51.1.2.应用范围51.2.阅读说明52.Java编码原则62.1.类、接口62.1.1.设计原则62.1.2.设计约束62.2.方法62.2.1.设计原则62.3.变量72.3.1.设计约束72.4.表达式与语句72.4.1.设计约束72.5.序列化82.5.1.设计约束82.6.异常捕捉82.6.1.设计原则82.6.2.设计约束82.7.日志92.7.1.设计原则92.8.线程安全性92.8.1.设计约束92.9.系统与资源安全性102.9.1.设计原则102.9.2.设计约束102.10.性能102.10.1.设计原则102.10.2.设计约束112.11.单元测试112.11.1.设计原则112.11.2.设计约束113.数据库设计原则123.1.数据库设计规范123.1.1.设计原则123.1.2.设计约束133.2.数据库开发规范133.2.1.设计原则133.2.2.设计约束144.EXOA二次开发原则144.1.二次开发方法144.1.1.二次开发规模评估144.1.2.修改原有模块144.1.3.新增模块154.1.4.新增应用系统154.2.二次开发规约细则155.代码管理原则165.1.代码管理165.1.1.设计约束165.2.版本控制管理185.2.1.设计约束18前言目的范围目的作用本规范的主要目的为指导、规范软件编程人员进行软件代码编写工作，提高软件开发工程师的软件编写能力。代码规范相当重要，代码规范提高软件代码的可读性，使得开发人员快速和彻底的理解新代码。好的代码风格不仅会提高可读性，而且会使代码更健壮，更为重要的是在修改时不容易出错。应用范围公司所有涉及程序编写的人员和部门。本约定适用于可执行系统的源代码文件。为了执行规范，每个软件开发人员必须一致遵守编程规范。阅读说明本规范主要分为设计原则与设计约束两大类。设计原则。主要为设计建议，根据建议可以写出更优质的代码。本文中为【非加粗字体】；设计约束。指的是所有开发人员必须要严格遵守的规约，不允许有违规行为。本文中规约以【加粗字体】标识。其中【灰色的加粗字】表示产品组内部强制执行，各项目建议执行。Java编码原则类、接口设计原则类的划分粒度要适当，不宜继承太深；建议一个类只做一件事，根据每个类的职责进行划分；多使用设计模式，尽量提高代码重用度；若多个类中使用相同方法时，请将其方法提到一个接口中或使用抽象类；在抽象类和接口都可实现的情况下建议选择使用接口，以更易于扩展及实现多重继承。设计约束程序结构遵守MVC规则：JSPACTIONSERVICEDAODB，即：DAO：放置不包含业务逻辑的纯粹数据库操作，为Service提供服务；Service：放置主要的业务逻辑代码，此类型代码一般为调用DAO提供的方法进行组合与包装。为Action层提供服务。若业务逻辑非常简单的情况下，Service层可以省略不写，同时业务逻辑代码写在Action层；Action：主要放置数据转换、校验、转发与业务逻辑调用的代码，若对应存在Service层，则Action层不应包含具体的业务逻辑代码；Jsp：分为前端代码与Java代码。其中Java代码应仅负责数据的获取与解析，不应包含具体的业务处理逻辑代码，更不应该存在Jsp直接写SQL语句进行操作的行为。方法设计原则一个方法只完成一项职责，在定义系统的公共接口方法外的方法应尽可能的缩小其可见性；避免在一个较长的方法里提供多个出口；当多个方法中同时使用一套逻辑相近的代码时，请将此类型的逻辑代码抽象成一个独立的方法；一个方法代码行数建议不超过200行。若超过，请将方法进行拆分。变量设计约束禁止在代码中出现无意义的数字（Magic Number），应该为此类型的数字定义一个变量名，提高代码可读性；禁止将一个非final实例变量声明为public，实例变量的传递与修改应在方法中实现（构造函数、getter、setter）。表达式与语句设计约束所有if、for、where等语句的执行代码段必须使用{}包括起来，即便是只有一个语句；禁止在一行代码中进行多个变量的赋值，如a=(b=c+1) ；超过3