--、<%，防止产生JS注入。
2.9.2.设计约束
●涉及到流（IO流、NIO流等）、连接（Connection连接、HttpClient连接等）的函数，必须要在finally块中进行资源关闭，防止代码段异常时该执行的释放的资源代码没被执行到；
●禁止获取流后不在函数中持有对象的写法，如：
StreamUtils.getBytes（newFileInputStream（newFile（path））），此种写法无法对流对象进行资源关闭；
●文件路径分隔符（windows下的\与linux下的/）必须使用File.separator来获取，否则会产生操作系统平台更变时的文件读写错误。
2.10.性能
2.10.1.设计原则
●避免在循环中频繁构建和释放对象；
●避免一次客户端操作中多次操作数据库，大多数情况应尽量使用单次数据库查询以完成操作；
●尽可能早释放资源（IO流、占大内存的对象等），不要过分依赖JVM进行GC操作。
2.10.2.设计约束
●在不涉及线性不安全问题的情况下请勿使用synchronized关键字与同步类（使用StringBuilder代替StringBuffer、ArrayList代替Vector、HashMap代替Hashtable等）。
使用时应尽量控制范围，最好是块级控制；
●不需要重新赋值的变量（含类变量、实例变量、局部变量）声明成final，可提高程序响应效率；
●在编辑String的情况下（如多个字符串的累加）必须使用StringBuffer类，处理完成后将StringBuffer对象再转换为需要的String对象。
2.11.单元测试
2.11.1.设计原则
●单元测试前请尽量使用Findbugs等代码检查工具进行检查，可在一定程度降低代码中的低级错误，插件安装方法请参考《Findbugs插件操作手册（Eclipse版）.docx》。
2.11.2.设计约束
●在代码提交前必须对更改的功能手工进行单元测试，提交的代码不能出现明显的错误（如点击后直接报500错等）。
若条件允许，建议使用自动化单元测试。
3.数据库设计原则
3.1.数据库设计规范
3.1.1.设计原则
●表设计时请尽量满足到3NF（即第三范式）；
第一范式：
1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式：
2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式：
3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
●尽量降低表之间的低级冗余，降低操作时产生脏数据与不一致性的可能性，但允许出现高级冗余；
●低级冗余，即重复性的冗余。
如在A表定义的字段在B表重复出现。
主键与外键字段不属于低级冗余范畴；
●高级冗余，即派生性的冗余。
一般这种冗余的目的是为了提高处理速度。
如“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，这种冗余有助提高性能。
●新建表时，请合理考虑实际运行时可能会出现的情况，根据可能会频繁执行的SQL语句建立合理的索引。
3.1.2.设计约束
●禁止在create脚本中设置默认获取当前数据库服务器中的系统时间。
当前时间应该在程序中获取，否则容易由于中间件服务器与数据库服务器时间不一致导致问题；
●所有数据库表必须包含主键或复合主键；
●使用复合主键时，字段个数不能多于3个，否则可能会导致主键索引失效；
●主键生成策略只允许使用以KeyGenerator（common包中）生成的int类型主键或GUID主键，禁止使用数据库自增的int主键；
●所有建库脚本必须按模块分开，且所有的表结构发生更改时，建库脚本必须要有alter语句。
3.2.数据库开发规范
3.2.1.设计原则
●尽量减少使用数据库的特性，如Oracle的深度递归、分页函数等；若必须要使用这种特性，请获取exoa-config中的数据库类型，添加针对不同数据库的特化处理代码。
数据库类型的获取方法如下（默认为Oracle）：
StringdatabaseType=ConfigHelper.fastGetConfig（"common","databaseType","oracle"）.toLowerCase（）;
●使用where时必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小；
●若需要使用触发器时，必须要考虑触发器的写法是否会带来较大的性能损耗；
●经常出现在Where条件中的字段应建立索引，如外键字段。
Having后的条件索引是无效的；
●查询时应尽量减少多余数据的读取，通过使用where子句来减少返回的记录数；
●对索引列的比较，应尽量避免使用not或!
=，可拆分为几个条件。
因为“not”和“!
=”不会使用索引；
●在where子句中，如果有多个过滤条件，应将索引列或过滤记录数最多的条件放在前面；
●尽量使用exists代替selectcount
（1）来判断是否存在记录，count函数只有在统计表中所有行数时使用。
3.2.2.设计约束
●禁止在where子句中的“=”左边进行函数、算术运算或其他表达式运算，此举动会导致系统将可能无法正确使用索引，如price*10=sum；
●做关联查询时，若两个表关联的字段为重复性极低的字段（如id），则两个表关联的字段必须加上索引；
●禁止可以枚举出来的数据的列建立索引。
如布尔型只有T和F，由于这种索引的区分度太低，数据库选择索引时几乎不会选用这类型索引执行，同时也存在索引维护成本，因此不宜建此类型的索引；
●当复合索引为多列时应将变化显著的列放到复合索引的首位，且复合索引不宜超过16列；
●禁止使用【insertintotable_namevalues（?
?
……）】语法，必须使用【insertintotable_name（col1,col2,……）values（?
?
…...）】，一旦数据列发生顺序变动（如人为变动、数据库迁移）时，此语句无法使用；
●如无必要情况，禁止使用数据库特性化语句（如Oracle的深度递归等），可降低数据库迁移时的成本。
4.EXOA二次开发原则
4.1.二次开发方法
4.1.1.二次开发规模评估
●修改原有模块：
原有模块功能不满足需求的情况。
●新增模块：
需求与系统现有模块差异较大，且新增功能要依赖OA环境运行的情况。
●新增应用系统：
需求规模较大，与OA系统现有功能基本无交集，且新增功能可不依赖OA环境运行的情况。
4.1.2.修改原有模块
●评估原模块功能与需求的差异，差异过大要比较扩展与做新模块之间的长短。
●理解原模块的工作机制和设计原意，检查原模块是否已提供配置手段实现需求，是否提供了扩展方法，若以上皆无，或仍不满足需求，才对原模块代码进行修改。
●分析修改内容是否通用，是否会引入新的依赖，是否对数据库结构作变更，后续能否进行产品升级。
●分析修改对实施的影响。
4.1.3.新增模块
●反复确认系统中无相近功能的模块。
●分析新模块与系统其它模块的关系，明确交互的场景和接口，注意模块间的依赖不要出现循环。
●新模块采用的技术方案不能与OA发生冲突。
原则上不允许引入新的第三方软件依赖。
●通过对业务的分析，预先考虑扩展方案。
●明确模块的实施方法，尽量做到配置可自维护，简化实施过程。
4.1.4.新增应用系统
●反复确认系统中无相近功能的模块。
●分析新系统与其它系统（包括OA）间的关系，与其它系统的交互尽量采用代理模式进行隔离，代理通过调用其它系统的分布式接口完成交互。
●新系统尽量采用与OA相同的技术方案，以方便功能迁移。
●通过对业务的分析，预先考虑扩展方案。
●明确系统的实施方法，尽量做到配置可自维护，简化实施过程。
4.2.二次开发规约细则
●数据库编码、页面编码统一使用GBK，禁止使用GB2312。
由于GB2312字符集不全，会导致部分生僻字变成问号；
●原则上不允许引入第三方包。
若必须要引入，在不造成与现有第三方包版本冲突的情况下，通过项目组讨论通过后方可引入；
●相同工作区下，各个核心包的版本号必须一致；
●禁止直接使用JDBC访问数据库。
在不使用第三方ORM框架的情况下，必须使用SQLUtil进行数据库交互；
●除使用事务，其余的所有SQL操作禁止获取SQLUtil的connection方法进行操作；
●项目若需要有使用SaaS模式，整个工作区代码必须遵守SaaS规范，具体规范详见于《4.SAAS模式编码规范与约束.docx》；
●禁止直接对核心表（mv_开头、um_开头的表）进行增删改操作，这种操作必须要调用核心包的对外公布接口，否则会导致核心公文缓存（如公文表单模板缓存等）中产生脏数据。
5.代码管理原则
5.1.代码管理
5.1.1.设计约束
●所有的代码提交必须写readme，且提交时写上commit的注释（comments）；
●readme文件需放置在ear工程的根目录下，一个的产品只允许有一个readme；
●readme撰写方式如下：
1.readme提交格式：
提交序号（自编的流水号,数字）：
【模块名】日期改动者
改动序号（自编的流水号,可用顺序字母）：
project问题ID（若有）修改简述
改动的描述与备注（修改方法、注意事项等）
改动内容类型（+表示增加，-表示删除，*表示修改）改动文件
2.撰写注意事项：
日期统一使用同步CVS的日期，非修改日期，因此可将同步CVS前的所有问题集合在同一个提交序号内；
3.范例：
92：
【协同办公平台】20140404wangp
A：
#18772【工作平台—流程中心—流程审批配置—工作代理】代理开始时间早于系统时间时没有提示信息
增加判断：
代理开始时间：
不能选择早于当前系统时间
*/missiveWeb/WebContent/processing/delegate/delegateEdit.jsp
B：
#18664【工作平台—流程中心—流程发起—流程起草—参考资料】jpg格式图片打开是空白页
修改openFileWith（fileId,workItemId,ext）方法,对图片文件直接显示
*/missiveWeb/WebContent/processing/workitem/docInstReference.jsp
●需要打基线时，必须把基线更变情况列入readme中，如：
-包名（每次打包前必填）：
exoa（20140721）_V00_01_009-V01_03_012.ear
--------------------------------------------------------------------------------------------
-打包基线（每次打包前必填）：
exoa（20140721）_V00_01_009-V01_03_012
--------------------------------------------------------------------------------------------
5.2.版本控制管理
5.2.1.设计约束
●对外出包（发布测试版本、发布正式版本）的出口应该控制在一个人手上，该角色需要控制出包频率与基线定制。
详细请参考《5.出包的流程与规范.docx》；
●不允许修改已成为基线版本文件的任何代码。
升级会员 