1、数据库层面
1）在做批量操作时，先用一句SQL从数据库中查询列表数据，然后再内存中去遍历，不要在循环中每次发起一个SQL请求；因为数据库连接很耗性能
2、代码层面
1）以后合并批量操作和单条操作，统一用strList来接受参数
2）为避免多余的拆箱和装箱操作，以后前台传参统一使用strMap，不用objMap
3）写代码遵循一个原则，至繁归于至简
3、命名规则
1）方法命名不加of，关联事务的命名仿照 updateAssessmentSubmit
2）关于列表展示的命名仿照 listFinalAssessmentPass
3）角色放后面，功能修饰放对象前面，仿照updateAssessmentBackKpb, updateAssessmentBackQt
4）原则遵循：对象放前面，动作修饰放后面
4、提示语句
修改叫填报，查询叫提供
必须选择一条记录进行操作！
操作失败，请联系管理员！
至少选择一条记录进行操作！
5、其他
注释不需要每个地方都写，要注意他存在的本质，像添加方法，我们的提示信息已经一目了然了，就不需要写注释了，而查询方法没有中文提示信息，我们就需要写注释。
别小看if else，这么设计是有它的理由的，能用的时候就用上
代码相关的部分放在一块，这样可以很方便的抽取出来
如果前台输入没影响我的程序运行，我可以规避他，我就不报错
尽量写一些公用性的提示信息，否则模块之间粘贴复制太麻烦了
如果和用户操作失误无关的错误，在后台的处理方法采用不提示错误信息，默默的让这种操作失败，比如报送、审核这些操作，如果用户通过平台途径操作，那么他肯定能成功，如果不能成功就是程序的问题或者别人通过非法途径攻击系统。
平台自定义的strMap、modelMap必须是平台自己实例化的，不要程序员自己去new
连缀表达式可以在架构中用到
SQL语句需要美化
灾难性检测，例如这次的角色管理配置功能项时出现的BUG
在后台，无论是什么操作（例如批量添加等），都应该将各自的方法写在各自的接口里面，一切为解耦考虑
应该按照规范英文命名
接口排序的方法按照页面功能的排序
公用接口放在最后面
jhcnd改成con
jhupdate改成update