绪论
月底公司就要放假了所以这几天无心工作，毕竟领导也不会安排什么紧急的开发任务。所以就找了一件自己最喜欢做的事情：优化代码。由于OA项目是自己在做，所以只要逻辑正确，即使修改一些代码也不会给整个系统带来麻烦，而且还可以使代码逻辑清晰，复用率更高一些。在修改过程中，引起了自己的一些思考，所以记录一下，分享给大家。
思考
1、表结构设计上的一些思考
在最初开始开发的时候，并没有做更多的思考，一个审批流程只有两张表，一张保存申请单信息（包括当前审批状态），另一张存储审批过程中每级审批结果。但是当我写第三个审批流程的时候，发现每张申请单中会存在一些相似的信息，比如：是否提交、是否通过、审批是否结束、退回次数、下一审批人等等。每次新建申请单对应的表时都要加上这些字段，感觉麻烦的要死，所以就把这些字段单独处理成为一张表（状态表）。在代码中专门写一个方法，当页面第一次提交申请单时，后台会在状态表中新增一条数据并返回主键保存到申请单对应的表中，瞬间感觉减少了我很多的工作量。
以前看到过一片文章，说是当我们查询数据时，字段越少，效率越高。更新时，修改的字段越少，效率越高。尽量把动态数据和静态数据进行分离。这里静态数据就是申请表，当提交申请后，这里数据就不允许进行修改，最多在退回的情况可以再次修改。动态数据当然就是状态表了，在整个审批过程中这里的数据会经常变化，所以单独处理会非常好。
2、程序设计上的一些思考
这几年在开发过程中基本使用的都是MVC这种方式。整个流程下来是：
视图界面 → 控制层 → service层 → dao层 → 数据库。
当年在东软曾用过下面这种：
视图界面 → 控制层 → service1层 → service2层 → dao层 → 数据库。
有一段时间真的不太明白为何要这样写，后来逐渐就明白了。
举个例子说明一下：在做采购审批过程中包括项目采购和固定资产采购（都存在一张表中，用一个字段区分，两个审批流程不同），当领导审批时候可能在PC端也可能在移动端，所以控制层这里其实是有两个，所以我在service1层里面新写方法，用于判断申请单的类型，可以调用service2层中不同的审批流程。在前期设计中，service2层中对于不同来源（PC、APP）的审批是分开处理的，只是返回内容不同，这就造成了大量代码的重复，还有就是当审批流程调整时，我改了对应PC端的方法，对应APP的忘了，或者修改不一致，都会出现一些问题，所以后期又进行了整合，无论来源，都会走相同的方法，只在返回值上做出特殊处理，减少了很大一部分代码。
所以在service上分层，可以处理更复杂的业务，可能当时东软也是在这个基础上进行设计的吧。
刚开始使用IDEA这款开发工具时候有些不太适应，尤其喜欢重复代码提示这个功能，可以让自己思考这部分代码是否能提炼优化。
作为一枚程序员，我们就是在不断的挖坑和填坑的过程中铺平前进的道路。
以上思考都是仁者见仁智者见智，也许过个几个月，我学到一些新东西，感觉这些优化也不是太好，所以仅供参考，不必当真。
（若有什么错误，请留言指正，3Q）