产品开发部制度细则第一章总则第一条为了规范产品开发流程，提高产品开发效率，特制订本制度。
第二条为了规范研发部员工工作。
第二章产品开发流程第一条进行产品的需求调研，了解客户的需要，挖掘业务潜在的本质。
形成业务用例规约。
第二条对业务用例规约进行分析，抽象出用例规约也就是系统用例。
第三条根据系统用例由形成简单页面设计，并进行评审。
第四条由美工设计出静态页面，并交有关人员进行评审，并形成测试文档。
第五条进行数据库简略设计。
第六条系统详细设计，主要讨论系统实现抽象框架公用部分，进行数据库详细设计，并完善测试文档。
第七条画业务流程图，包括业务流，数据流。
第八条对业务流程图，数据库，测试文档进行评审以及修改。
第九条进行包设计，类设计，形成详细设计序列图。
第十条形成代码框架，以及产品开发计划，测试计划。
第十一条编码，单元测试（包括代码检查）及修改。
第十二条集成测试及修改。
第十三条系统客户环境搭建，程序部署，以及客户环境的系统测试。
第十四条封版，移交项目部。
第三章产品开发规范第一条开发规范统一规定如下：完整、准确的描述出名字所代表的事物，所有（除去循环变量）的变量名请不要用如a、aa、a1等没有意义的单个或字母重叠。
所用方法的动词：Show显示首页，Find查询，Save添加，Delete删除，Update修改,Exports导出,Imports导入,Returns返回,Use启用，Check核定，Add添加，Delete All全部删除，Get得到；查询的内容后面加：Infor单个实体/List列表；判断方法前加is如：isXxx（）；第二条Package命名：按用例及功能划分，全部小写，如：payment。
第三条Action的URL命名：Action.action，驼峰式，如：savePayment.action（首字母小写，后面驼峰）。
第四条JSP的URL命名：用例名称_功能，如：payment或payment_list（全部小写）。
第五条JSP命名：用例名称_功能.jsp，如：用例名称_add.jsp，用例名称_list.jsp，用例名称_info.jsp。
第六条对于类的统一要求：首字母大写，类内部的方法，首单词字母小写，后面单词驼峰式。
如：BusiTools第七条实体类命名：用例单词首字母大写。
第八条Action类命名：Action种类：普通Action:用例名称+功能,AjaxAction:用例名称+功能+AJ;用例名称+Table号+动词+/AAC，（Table：Ta、Tb、Tc……）如：PaymentTaShow、PaymentTaFindAAC，PaymentTbDispense。
第九条Action类中的方法命名：动词+名词。
如：findXxxInfo （）,findXxxList()；第十条BC（服务）接口类命名：I+用例名英文单词。
如:IOpenAccount。
第十一条BC（服务）接口类的方法命名：动词+名词。
findXxxInfo（）；第十二条BC（服务）实现类命名：用例名称英文单词。
如：OpenAccount。
第十三条DAO类命名：实体+DAO。
如：OpenAccountDAO。
第十四条DAO里方法命名：insertXxx、deleteXxx、updateXxx、queryXxx.等，判断的方法，以“is”开头，中间方法用“get”，Xxx是实体名。
第十五条DTO类命名：用例名或有意义的名词+DTO。
如：OpenAccountDTO。
第十六条普通变量命名：有实际意义的小写单词。
第十七条临时变量命名：小写temp加“_”开头。
如：temp_money。
第十八条布尔变量命名：小写is加“_”开头，用肯定形式。
如：is_pay。
第十九条集合变量命名：名词+List、Set、Map、Vec后缀。
如：empList。
第二十条Static Final变量命名：全部大写，单词间用“_”隔开。
如：EMP_STATUS_FIRST。
第二十一条数组变量命名：小写单词。
第二十二条所有的方法都要有注释，注明创建日期，作者，方法的用途，参数说明。
第二十三条所用变量都必须初始化，BigDecmal的变量声明如BigDecimal money=new BigDecimal（0.00）。
第二十四条从界面取来的值必须去空格；第二十五条从数据库取出的，除数据库定义不能为空的以外的值必须判断是否为空；第二十六条DTO和实体中的金额变量，必须得用BigDecimal类型。
第二十七条日期型（YYYYMMDD）的变量用String。
时间型的用Date。
第二十八条方法的规模尽量限制在100行以内。
第二十九条避免设计多参数的方法，用hbm实体和DTO。
第三十条所有的方法都要有try-catch。
第三十一条DAO不能实例化，通过IOC注入。
第三十二条事务控制要在BC里面写。
第三十三条同一业务逻辑要写在BC中的同一方法里。
第三十四条业务逻辑要在BC中完成不要在DAO中，除少量的可以写在Action中。
第三十五条hbm中不要配置formula属性。
第三十六条SQl及HQL查询的时候要将查询的字段列出来。
第三十七条不要用session.flush（），session.clear（）。
第三十八条页面上的标签不要加空格。
<jsp:param name="url"value="adjustaccountServiceTaShowTailAC.actio n"/>不要写成<jsp:param name="url"value="adjustaccountServiceTaSh owTailAC.action"></jsp:param>第三十九条要用相对路径不要用绝对路径。
第四十条严格遵守业务流程图及测试文档的要求进行代码编写。
第四十一条修改问题时要想好修改思路，避免修改后出现新的问题。
第四十二条点击节点和点击切换框（具体情况具体分析）以及弹出框时要清除PAGINATION。
第四十三条页面上用到的js一定要在公用的里面引入，除了特殊的不能引到的。
第四十四条资源文件里面的key值不要有空格。
第四十五条要尽量使用公用的资源。
第四十六条删除尾表信息时，要根据头表删除尾表，不要用deleteAll（）。
第四十七条避免在存储过程中写游标。
第四十八条不要将循环体外的代码放在循环体内部。
第四十九条所有代码要进行格式代码。
第五十条去掉后台所有打印。
第四章公共开发内容维护第一条未经同意，不能修改，删除，注释别人的代码，只能引用。
第二条未经授权，不能修改框架公用文件。
第三条未经授权，不能修改，删除数据库结构。
第四条未经同意，不能修改，删除数据库内数据。
第五条未经授权，不能删除svn资源。
第五章任务派发第一条由产品负责人对系统进行分析，评估任务量，所需时间(包含加班时间)，所需开发人数，以及开发风险，形成产品开发计划。
第二条由评审委员会对产品开发计划进行评审。
第三条由开发组长下发任务，并进行任务说明。
第四条编码人员接到任务时要先分析并理解业务流程以及测试文档，规划好思路后再进行编码。
第五条任务内容在没有特殊变动的情况下不能变更任务的时间以及任务量。
第六条由于个人原因任务没有完成，并严重影响产品进度的编码人员，公司按情节轻重给予处罚。
第七条编码人员由于个人原因，需要加班的。
公司不负责加班费，餐费，以及打车费。
第八条开发组长及产品负责人要跟踪每个编码人员的开发进度，保证开发进度，（业务流程实现，测试文档测试通过）。
第六章SVN更新，提交流程第一条每天早上编码人员必须从服务器上更新最新代码。
第二条svn提交前必须先与资源同步，查看是否有冲突文件。
第三条svn更新，提交的时候，要注意冲突文件，要保证冲突文件提交的正确性，不要覆盖其他人的代码。
如果不能确认操作是否正确的时候，要向负责人寻求帮助，不能随意提交。
第四条svn提交时要保证代码没有编译性错误。
第五条不要对服务器svn资源进行操作，如果由于操作失误，对开发产生不良影响的，公司会给予严厉处罚。
第七章变更及修改流程第一条系统静态页面变更。
必须经过负责人同意才能变更产品静态页面，变更后要及时进行原型静态页面的修改。
第二条数据库结构变更。
必须经过负责人同意才能变更，变更后要及时记录数据库变更记录，case，开发数据库，及时通知框架负责人进行框架维护，通知项目部负责人进行项目数据库维护。
第三条系统设计（包括业务思路，业务流程图，测试文档）变更。
变更要经过负责人同意才能变更，变更后及时修改相应文档（如：业务思路，业务流程图，测试文档），要及时通知产品开发人员。
第四条系统框架（包括公用程序及组件）变更。
要经过相关的框架负责人同意后才能变更，变更后要及时通知代码编写人员。
第八章安全控制第一条数据库负责人每天进行数据库备份，保留近15天备份。
第二条产品资源负责人15天刻录产品资源光盘一张。
第三条产品研发部所有员工不能向外界泄露产品开发资源，一经发现公司将给予严厉处罚。
第九章附则第一条遵守公司制度，维护公司形象。
第二条负责人要尊重公司员工。
第三条所有程序员服从上级负责人分配。
第四条随时提出有力于部分及公司发展的合理化建议。
第五条研发部员工每天都要按时提交日报。
1.本制度解释权归产品研发部。
2.本制度适用于所有产品研发部人员。
3.本制度有未完善之处，在完善中形成的有关条款，。