3开发原则与约束

1、开发原则与约束开发命名规范开发原则与约束版本信息* a代农新增，m代衣修改，d代表删除;版本号发布日期提交人审阅人a.m.d更新位置更新摘要v1.02014-07-26李健进a拟初稿vi.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. 前言61.1. 目的范围61.1.1. 目的作用61.

2、1.2. 应用范围61.2. 阅读说明62. java编码原则72.1. 类、接口72.1.1. 设计原则72.1.2. 设计约束72.2. 方法92.2.1. 设计原则92.3. 变量92.3.1. 设计约束92.4. 表达式与语句102.4.1. 设计约束102.5. 序列化102.5.1. 设计约束102.6. 异常捕捉112.6.1. 设计原则112.6.2. 设计约束11 开发原则与约束2.7日志12设计原则12线程安全性122.1. 设计约束12系统与资源安全性132.4.1. 设计原则132.4.2. 设计约束142.2. 性能14设计原则14设计约束152.2. 单元测试15设

3、计原则15设计约束163. 数据库设计原则163.1. 数据库设计规范163.1.1. 设计原则163.1.2. 设计约束173.2. 数据库开发规范183.2.1. 设计原则183.2.2. 设计约束194. exoa二次开发原则20 开发原则与约束4.1. 二次开发方法204.1.1. 二次开发规模评估204.1.2. 修改原有模块204.1.3. 新增模块214.1.4. 新增应用系统214.2. 二次开发规约细则225. 代码管理原则235.1. 代码管理235.1.1. 设计约束235.2. 版本控制管理255.2.1. 设计约束25开发原则与约束1.1. i的范围l.l.l目的作用

4、本规范的主要口的为指导、规范软件编程人员进行软件代码编写工作，提高 软件开发工程师的软件编写能力。代码规范相当重要，代码规范提高软件代码的 可读性，使得开发人员快速和彻底的理解新代码。好的代码风格不仅会提高可读 性，而且会使代码更健壮，更为重要的是在修改时不容易出错。1.1.2.应用范围公司所冇涉及程序编写的人员和部门。本约定适用于可执行系统的源代码文 件。为了执行规范，每个软件开发人员必须一致遵守编程规范。12阅读说明本规范主要分为设计原则与设计约束两大类。设计原则。主要为设计建议，根据建议可以写出更优质的代码。本文中为【非加粗字体】开发原则与约束设计约束。指的是所有开发人员必须要严格遵守的

5、规约，不允许有违规行为。 本文中规约以【加粗字体】标识。其中【灰色的加粗？】表示产品组内部强 制执行，各项目建议执行。2. java编码原则类、接口1.1.1. 设计原则类的划分粒度要适当，不宜继承太深；建议一个类只做一件事，根据每个类的职责进行划分；多使用设计模式，尽量捉高代码重用度；若多个类中使用相同方法时，请将其方法提到一个接口中或使用抽象类；在抽象类和接口都可实现的情况下建议选择使用接口，以更易于扩展及实现 多重继承。2.2.2. 设计约束 程序结构遵守 mvc 规则：jsptactiontservicetdaotdb,即:开发原则与约束 service：放置主要的业务逻辑代码，此类型

6、代码一般为调用da0提供的方法进行组合与包装。为action层提供服务。若业务逻辑非常简单的情况下,service层可以省略不写，同时业务逻辑代码写在action层; action：主要放置数据转换、校验、转发与业务逻辑调用的代码，若对应存在service层，则action层不应包含具体的业务逻辑代码; jsp：分为前端代码与java代码。其中java代码应仅负责数据的获取与解 析，不应包含具体的业务处理逻辑代码，更不应该存在jsp直接写sql语句 进行操作的行为。开发原则与约束2.2方法2.2.1.设计原则 一个方法只完成一项职责，在定义系统的公共接口方法外的方法应尽可能的 缩小其叮见性；

7、避免在一个较长的方法里提供多个岀m；当多个方法中同时使用一套逻辑和近的代码时，请将此类型的逻辑代码抽象 成一个独立的方法； 一个方法代码行数建议不超过200行。若超过，请将方法进行拆分。2.3变量2.3.1.设计约束禁止在代码中出现无意义的数字（magic numbec ,应该为此类型的数字定义一个变量名，提高代码可读性;禁止将一个非final实例变量声明为public,实例变量的传递与修改应在方法中实现（构造函数、getter、setter）。开发原则与约束2.4表达式与语句设计约束所有辻、for、where等语句的执行代码段必须使用包括起来，即便是只 有一个语句； 禁止在一行代码中进行多个

8、变量的赋值，如a二（b二c+1）； 超过3个else分句请转成switch语句或创建子函数； switch语句的每个case中必须带有break；循环语句中必须有终止循环的条件或语句，否则容易导致死循环的情况。2.5.序列化2.7.1. 设计约束 创建序列化类时，serialversionuid必须设置一个随机的哈希字段，不应 笼统设置为-1l；若复制一个serializable的类进行修改时，必须重新设置新类的 serialversionuid； 针对瞬态的对象（如10流对象thread对象等）与不希望被序列化的对象，必须在对象声明前加上transient关键字。开发原则与约束26异常捕捉3

9、.1. 设计原则必须尽可能的精确捕捉异常，而不能笼统使用exccptiono3.2. 设计约束当捕捉到异常时，必须在catch代码区进行处理，并且在日志中记录错误信 息(system, out、log4j> oa h志等)；异常日志不应笼统提及抛出这个异常的方法的名字，应有使用说明性的文字描述与完整的异常栈输出(printstacktrace)； 禁止捕捉异常后不进行任何处理的写法。开发原则与约束2.7日志2.7.1.设计原则 debug日志记录尽量通用而全而，且与oa的debug开关配合使用，例子如下: boolean isdebug = "truen.equals(syst

10、em.getproperty(oaconstant.debug) ? true : false;if (debug) system.out.println(hdebug 日志：n);28 线程安全性2.8.1.设计约束在 jsp、servlet 及 struts 的 action 编程中,非final变量应尽量采用局部变量，减少使用实例变量。由于这些情况都是多线程情况，容易产生线性 不安全问题； 使用synchronized关键字的代码段或函数之间禁止相互引用，以免引起死锁;开发原则与约束应限制自定义线程个数上限，不设线程限制且并发的情况下（如在action 中start个新线程），可能会由于

11、线程量暴涨，从而导致native内存耗 尽，服务器瘫痪崩溃； 对于static关键字修饰的变量>synchronized关键字修饰的代码段或函数,必须考虑这部分代码能否在集群环境下正常运行。因为static的变量变化时无法在集群中简单共享，synchronized的代码段不能阻塞并发在集群里其他节点的代码。29系统与资源安全性2.9.1.设计原则与上传文件相关的功能（如上传附件等），必须针对后缀名进行判断与过滤： js、jsp、*htm* （女ii html> shtmk htm 等）、css； sql语句捉交时，由客户端传递的变量值必须使用传参形式传入，不允许使 用字符吊拼接方式

12、实现，此举动容易产生sql注入，造成安全隐患；针对插入与修改的功能，应校验由客户端提交的数据是否存在敏感的字符串style、<script> <!-、<%,防止产生 js 注入。 开发原则与约束2.9.2.设计约束 涉及到流（10流、ni0流等）、连接（connection连接、httpclient连接 等）的函数，必须要在f inally块中进行资源关闭，防止代码段异常时该执 行的释放的资源代码没被执行到； 禁止获取流后不在函数中持有对象的写法，如：streamut订s. getbytes （newf订elnputstream（new file （path）,此种写法

13、无法对流对象进行资源关闭； 文件路径分隔符（windows下的与linux下的力必须使用f订e. separator来获取，否则会产生操作系统平台更变时的文件读写错误。2.10.性能210丄设计原则避免在循环屮频繁构建和释放对象；避免一次客户端操作中多次操作数据库，大多数情况应尽量使用单次数据库查询以完成操作；尽可能早释放资源（10流、占大内存的对象等），不要过分依赖jvm进行gc操作。 开发原则与约束2.10.2.设计约束在不涉及线性不安全问题的情况下请勿使用synchronized关键字与同步类（使用stringbuilder代替stringbuffer >arraylist代替ve

14、ctor>hashmap 代替hashtable等）。使用时应尽量控制范围，最好是块级控制；不需要重新赋值的变量（含类变量、实例变量、局部变量）声明成final,可提高程序响应效率；在编辑string的情况下（如多个字符串的累加）必须使用stringbuffer类， 处理完成后将stringbuffer对象再转换为需要的string对象。2.11.单元测试211丄设计原则单元测试前请尽量使用findbugs等代码检查工具进行检查，可在一定程度 降低代码中的低级错谋，插件安装方法请参考findbugs插件操作手册 （eclipse 版） docx。开发原则与约束2.11.2.设计约束在代码

15、提交前必须对更改的功能手工进行单元测试，提交的代码不能出现明 显的错误（如点击后直接报500错等）。若条件允许，建议使用自动化单 元测试。3.数据库设计原则数据库设计规范2.9.1. 设计原则表设计时请尽量满足到3nf （即第三范式）；第一范式：1nf是对属性的原子性约束，要求属性具冇原子性，不可再分解; 第二范式：2nf是对记录的惟一性约束，要求记录有惟一标识，即实体的惟 一性；第三范式：3nf是对字段兀余性的约束，即任何字段不能由英他字段派生出 來，它要求字段没有冗余。 尽量降低表之间的低级冗余，降低操作时产生脏数据与不一致性的可能性,但允许出现高级冗余;开发原则与约束低级冗余，即重复性的

16、冗余。如在a表定义的字段在b表重复出现。主 键与外键字段不屈于低级冗余范畴；高级冗余，即派生性的冗余。一般这种兀余的fi的是为了提高处理速度。 如“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量” 派生出来的，这种冗余冇助捉高性能。新建表时，请合理考虑实际运行时可能会出现的情况，根据可能会频繁执行 的sql语句建立合理的索引。3.1.2.设计约束禁止在create脚本中设置默认获取当前数据库服务器中的系统时间。当前 时间应该在程序中获取，否则容易由于中间件服务器与数据库服务器时间不 一致导致问题；所有数据库表必须包含主键或复合主纟使用复合主键时，字段个数不能多于3个，否则可能会导

17、致主键索引失效; 主键生成策略只允许使用以keygenerator （common包中）生成的int类型主键或guid主键，禁止使用数据库自增的int主键;所有建库脚本必须按模块分开，且所有的表结构发生更改时，建库脚本必须要有alter语句。 开发原则与约束3.2.数据库开发规范3.2.1.设计原则尽量减少使用数据库的特性，如oracle的深度递归、分页函数等；若必须要使用这种特性，请获取exoa-config中的数据库类型，添加针对不同数据 库的特化处理代码。数据库类型的获取方法如下(默认为0racle):string databasetype 二confighelper.fastgetco

18、nfig(ncommonn/,databasetypelnoracleh)-tolowercase();使用where时必须考虑语句顺序，应该根据索引顺序、范围大小來确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小；若需要使用触发器时，必须耍考虑触发器的写法是否会带来较大的性能损耗；经常岀现在where条件中的字段应建立索引，如外键字段。having后的条件索引是无效的；查询时应尽量减少多余数据的读取，通过使用where 了句來减少返冋的记录数；对索引列的比较，应尽量避免使用not或!二，可拆分为几个条件。因为“not”和“！二”不会使用索引； 在where子句中，如果

19、有多个过滤条件，应将索引列或过滤记录数最多的条件放在前面;开发原则与约束 尽量使用exists代替select count (1)来判断是否存在记录，count函数只 有在统计表中所有行数时使用。3.2.2.设计约束禁止在where子句中的“二”左边进行函数、算术运算或其他表达式运算， 此举动会导致系统将可能无法正确使用索引，如price*10=sum；做关联查询时，若两个表关联的字段为重复性极低的字段(如id),则两 个表关联的字段必须加上索引；禁止可以枚举出来的数据的列建立索引。如布尔型只有t和f,由于这种索 引的区分度太低，数据库选择索引时几乎不会选用这类型索引执行，同时也 存在索引维护

20、成本，因此不宜建此类型的索引；当复合索引为多列时应将变化显著的列放到复合索引的首位，且复合索引不 宜超过16列； 禁止使用insert into table_name values (?, ?,)语法，必须使用insert into table_name (coll, col2,) values (?,?,)】, 一旦数据列发生顺序变动(如人为变动、数据库迁移)时，此语句无法使用;如无必要情况，禁止使用数据库特性化语句(如oracle的深度递归等)，可降低数据库迁移时的成本。 开发原则与约束4. exoa二次开发原则4.1.z1次开发方法4.l1.二次开发规模评估修改原有模块：原有模块功能不满

21、足需求的情况。新増模块：需求与系统现有模块差异较大，口新増功能要依赖0a坏境运行的情况。新增应用系统：需求规模较大，与0a系统现有功能基木无交集，且新增功 能可不依赖0a环境运行的情况。4丄2修改原有模块评佔原模块功能与需求的差异，差异过大要比较扩展与做新模块之间的长短。理解原模块的工作机制和设计原意，检查原模块是否己提供配置手段实现需 求，是否提供了扩展方法，若以上皆无，或仍不满足需求，才对原模块代码 进行修改。分析修改内容是否通用，是否会引入新的依赖，是否对数据库结构作变更， 后续能否进行产品升级。分析修改对实施的影响。开发原则与约束4.1.3.新增模块反复确认系统中无相近功能的模块。分析

22、新模块与系统其它模块的关系，明确交互的场景和接口，注意模块间的 依赖不要出现循环。新模块采用的技术方案不能与0a发生冲突。原则上不允许引入新的第三方 软件依赖。通过对业务的分析，预先考虑扩展方案。明确模块的实施方法，尽量做到配置可自维护，简化实施过程。4.1.4.新增应用系统反复确认系统屮无相近功能的模块。分析新系统与其它系统（包描0a）间的关系，与其它系统的交互尽量采用代 理模式进行隔离，代理通过调用其它系统的分布式接口完成交互。新系统尽量采用与0a相同的技术方案，以方便功能迁移。通过对业务的分析，预先考虑扩展方案。明确系统的实施方法，尽量做到配置可自维护，简化实施过程。开发原则与约束4.2

23、二次开发规约细则数据库编码、页面编码统一使用gbk,禁止使用gb2312o由于gb2312字符集不全，会导致部分生僻字变成问号;原则上不允许引入第三方包。若必须要引入，在不造成与现有第三方包版本 冲突的情况下，通过项目组讨论通过后方可引入；相同工作区下，各个核心包的版本号必须一致；禁止直接使用jdbc访问数据库。在不使用第三方orm框架的情况下，必须使用sqlutil进行数据库交互；除使用事务，其余的所有sql操作禁止获取sqlutil的connection方法进行操作；项目若需要有使用saas模式，整个工作区代码必须遵守saas规范，具体规 范详见于4saas模式编码规范与约束docx；禁止直接对核心表（mv_开头、uni_开头的表）进行增删改操作，这种操作必 须要调用核心包的对外公布接口，否则会导致核心公文缓存（如公文表单模 板缓存等）中产生脏数据。开发原则与约束5代码管理原则51代码管理5.1.1.设计约束 所有的代码提交必须写readme,且提交时写上commit的注释(comments)； readme文件需放置在ear工程的根目录下,一个的产品只允许有一个readme； readme撰写方式如下:开发原则与约