技术之余的碎碎念

昨晚和一个朋友聊天，她说：“你可以写写博客呀，讲你的工作心得”。于是我提笔了，但一时没个草稿。

朋友是保研的，现在在找工作。我认真想了下，似乎分享工作中的一些准备步骤、取舍更有把握。其实自己真正回到 Java Web 开发，也是今年3月份的事。接手了某商业银行一个正儿八经的 MVC 项目，开始做 Struts1 和 Hibernate 的二次开发。除了每天纠结这个数据传不过来、那个存储过程报了什么错误，倒也没什么特别有价值的东西。每每业务有新的需求，总有楼房僭建一样的感觉。但是作为一种“我就看你什么时候换系统”的心态，这个五年的老系统其实就是一条道走到黑。

扯背景太远了，回到正题。面对这样的系统，干了两年信息，心里还是没底的。第一点，是先把系统开发中，各种参考而来的可行方案都试一遍；最初找到的肯定能“堵住”业务需求的洞，随着业务数据急剧增加（比如自增长的 id 突破了 21 亿之巨）肯定要一个个优化。优化方法有三，一是字段长度增加、二是改存储过程的参数类型（把代码片从上到下逐个排查，报错的部分再从上到下，注释后再运行排查）、三是改善业务逻辑的编写：比如接口设计，单个数据的处理直接放在事务控制的方法就好；但批量传入的数据，除了 SQL 优化、使用 Hibernate 批量处理，还要在单句 SQL 执行时注意回滚的影响。

第三点展开来讲。批量数据处理为了性能起见，如果设计成一旦失败就全部回滚，性能其实还不错，就是要记得返回操作失败的数据。如果精细一点，先把批量的 SQL 组装成一个数组，再来循环遍历。此时，循环体外面必须捕获 Exception 或者业务系统的全局异常，从而避免一个失败导致后面的都不继续执行。当然返回的失败数据可以参照前一种来做，建议批量收集后才返回。

还有一个（也许）广泛存在的坑：前端组件承担的“隐性”数据计算和绑定功能。用 JSP、JSF 的产品框架尤甚。什么数据不显示、查询控件不起作用，基本是反射字段或者对象名没有配好。在前人的页面代码找不到用例（眼见为实、看到对的就抄），找找 tld 文件，自求多福吧。

还有一些拉杂的事，数据库死锁了怎么解开、业务规则不清晰的时候怎么和甲方技术人员沟（搁）通（置）、怎么样用最少的代码量堵住（或者说服削减）业务需求等等。其实拉杂的东西才是工作的常态，比较累、比较乏味、比较浪费生命、比较扼杀你进步的常态。如果你觉得这篇东西屁话连篇没有营养，恭喜你又上一个台阶了（去大型甲方、不干了、去当公务员都是嘛哈哈哈）

还有，这篇东西...什么分类？人生除了“好”的人生、被人认为“成功”的人生，其他的也不需要分类吧。