对一个小项目的总结
刚刚做完一个小项目，感触很多，虽然以前做过更大的，但由于时间问题，没有好好的总结。这次终于可以静下心来，留下点滴聊以自慰。第一次写博客，欢迎拍砖！言归正传，下边直接谈心得！
1：关于数据库操作语句的放置位置
总原则：尽量不要放在循环中，应在循环之外批量执行
比如说删除语句，大多数情况，我们都是按where条件删除的，如where
a=‘value’，我们将这个sql放在循环里，value的值不断变化，实现删除一
批数据，这样子做的后果是：我们要执行多条sql语句，多次进行IO操作，很
不好。推荐做法：将这些值先存起来，比如说放在一个容器里，待循环结束
后，将这些值取出来放进一个IN条件中，实现批量删除。类似的，查询，更新
语句也可以做此优化。
2：关于事务超时的问题
总原则：必要时，自己控制事务
很多公司的框架在事务是个问题上，留给开发者两个选择，框架控制事务或者程序自
己控制事务，前者对事务有一个超时的限制，比如说多少秒就算超时了。如果超时
了，前边做的一些操作可能就会rollback，所以这个时候就需要自己控制事务，及
时的提交一些数据库操作，特别是多系统之间的交互，受网络的影响较大时，都应该
考虑事务的问题。
3：关于事务的还原点
总原则：仔细检查commit的时刻，确保在rollback（savepoint）时，这个
savepoint还有效
这次项目中需要用到还原点，我们试着建立一个还原点并在异常时回滚至此，但是老
说这个还原点没有建立过，经过排查，我们发现在建立还原点之后，我们调用了一个
存储过程，这个存储过程执行了commit，所以我们建立的那个还原点无效了，注释掉
这个commit即可
4：关于数据库连接的定义
总原则：不要定义成全局变量
这次项目中，由于这个连接是作为参数传入的，为了代码简洁，我将这个参数赋给另
外一个全局变量，我在其他函数中可以直接访问，不用传递参数。但是项目经理告诉
我，这样可能会出问题，具体什么问题，我也不是很清楚，但是他的话让我想起了以
前某位大神的话，不要将request对象传来传去，会不会有异曲同工之妙呢？呵呵，
有待发掘。
5：查询不到数据时的处理
总原则：不要盲目抛出异常
如我们需要给某个中心的主任发送一条消息，那么我们需要先查询出这个主任的代
码，如果查询结果为空，那么我们直接抛出异常，如果业务需求说，这这种情况也可
以发给副主任，那我们就不应该抛出异常。主要是告诫大家：即使在清楚业务逻辑的
情况下，也可能由于思维惯势犯错
6：系统交互时参数传递问题
总原则：尽量少，避免中文
开始的时候我将B系统需要显示的东西全部在A中组织好，然后B收到后直接显示，某
天由于这个串太长，数据库保存出错，然后改成传递时只是传递一个参数，然后在B中
取出查询相关信息即可。另外就是中文问题：我在参数中传递了一些中文，在测试环
境上没有问题，但是在真实环境中就是乱码，百思不得其解，后来PM告诉我，测试环
境是windows，真实环境是linux，所以...哎，顿悟，字符集问题
7：关于异常处理
总原则：给前台一个消息
很多人在捕获到异常时都是直接e.printStackTrace()，那么前台的操作人员根本
不知道发生了什么，还以为成功了呢。所以我们需要将这个信息想办法传给前台，有
的时候我们还需要对一些特殊的异常做处理，这个时候可能需要我们自定义异常，我
们要单独捕获这个异常，不能catch (Exception e)一概捕获，将这个语句要放在
最后，java基础就讲过啊，可真正有几个人遵守啊！
8：关于程序的校验
总原则：分工合作，达到平衡
我们收到一批数据时，我们应该先进行一些简单的校验，如数据格式的校验，然后将
其做数据库操作，这个时候可能也会抛异常，如这条数据插入时违反了主键约束，那
么我们再进行异常处理，两端的校验好比给程序上了双保险，这样子更加平衡，或者
说叫和谐，不应该将所有的任务推给哪一方，不然迟早有一天它会崩溃
9：关于打印调试信息
总原则：少使用System.out.println，多使用log
很简单，多使用日志信息，功能更加的全面，也可以正好学习哈log4j的一些东西