最近这大半个月主要参与的是大数据平台的审批子系统开发。老实说系统开发本身并不困难，主要的问题在于负责人对需求的不明确，和同事的合作以及时间太短方面。这里记录一下工作内容，遇到的问题以及解决方案吧。
场景：这个审批系统呢大概就是说在客户进行相应的查询之前（因为查询内容敏感），需要先发起一个查询申请，然后会由相关单位对这个发起的申请进行审批，待到审批通过之后，查询才会真正实施。
说明：其实光想这个系统其实也不简单，毕竟主要的难点在于审批流程要根据具体的业务场景去变化，所以要是可配置的。其次，审批流程的每个节点结束后都需要有相应的消息通知机制来通知下一个环节的处理人。好在是这两个比较复杂模块公司的第三方产品有提供支持。所以不需要在这两块进行太多开发，只需要完成相应的系统配置和实现相应的消息通知接口即可。
个人负责内容：还是因为经验不足的缘故，所以分配给我的任务还是比较简单的。申请表单页面开发，提交表单以及后台处理代码。之后还帮同事写了消息接口那块的更新逻辑以及完成了流程的配置。
问题一：申请内容和审批信息的保存。
这里主要是DB表设计的问题，因为我考虑到所有的查询申请与审批信息是一一对应的关系（第三方产品会存一个完整的流程信息，并与申请关联。本地为了查询效率，只会存申请的最新状态信息）。所以我把申请信息和审批状态（完成状态，上一步处理人，下一步处理人...）放在了一张表里。后来经理说，申请信息和审批信息要分离，因为后者是业务信息，分离后表设计会更加清晰。当时我并不赞同，因为在当时所明确的要存的审批字段也就两三个，而且一个与审批申请一一对应。后来需求逐步清晰，业务字段增加到了十几个，所以觉得还是分表会更合适一点。大概当时又被经理喷了一波没经验，其实如果一开始就知到有多少业务字段要存，我也是会考虑分离的，但是在当时只说要存两三个字段的情况下，我认为把这些状态做为申请的属性也没什么不妥。反正还是吃了需求不明确的亏。
问题二：配置审批角色。
因为是用公司的另一个产品来实现流程的配置，除开配置流程本身，还需要配置相应权限的用户来做对应环节的审批。这里有意思的是，我自己新增的角色或者部门配置好后，并没有如期的出现在下一环节的处理人列表中。这里估计是我配置还有遗漏，但是因为这个产品对我来说也是全新的，去找出遗漏的步骤也不是那么容易，而且当时项目赶，也比较着急。这里提升效率的方案是：在产品原有的配置上去进行修改（这也是经理的经验）。因为我发现同样的部门机构以及角色，如果是通过原来已有的内容修改而来的（配置已经完善），就能够正确显示。当然，如果产品里面没有旧的配置信息，那也只能一步步自己排查哪里配置有问题了。
问题三：需求不明确
经过两周的加班赶工，还是做了一个初步的能跑通的小产品。除开部分界面UI的优化问题，其它问题全部来自于需求。这里真想吐槽一下经理和客户，现在做东西大概就是客户口头说给经理，经理口头说给我们，然后开工，所有的具体实现都由我们开发人员基于自己的理解去完成，有不明确的可以找经理确认。是的，对于一个软工背景的人来说，这种开发方式简直让我头皮发麻。原型没有人做，经理不明确，客户也不明确的地方，不是他们去做需求确认进一步明确，而是让我们先做，然后再改。我是真的服，老实说你要这么弄，你把项目周期拉长很多我也没话说啊，任务一布置下来天天在那里催几号要做完，很赶之类的。效率为什么这么低自己没有数吗？拿这次来说，开发完的成品，三个核心问题都是来自于需求不明确。一是流程理解有误，二是要支持一次申请查询多个目标（经理给的需求是只支持一次申请查询一个）。 再来就是问题二说的数据库，本来就是想当时就把设计改了，代码也改了。然而，经理也是当时说项目赶，让我先按原设计做出产品。就这三个问题造成的返工，基本上又可以改一个星期啦。然后，这边有说再过两周要全面做好。经理就说：要加班哦。 以前我不理解那句“996类似的产物都是无能或者底下的管理所照成的这句话”，现在体会很深了。我们经理虽说是踏实肯干，但是感觉管理效率真的有待提高。我最不理解的就是那种宁可返工也不愿意先做个原型把需求确认清楚的这种意识，那怕画出来给客户看都好啊。还老想着，来帮我们分担一点技术或者配置活（然而事实证明他也搞不服帖。。。）所以有这时间，还是多去确认细化下需求吧。
问题四：改数据库表结构
就像之前说的，现在需要把数据表从之前的一张表分离成业务表和申请信息表，加上一些需求的修改，现在要弄成四张表。那么问题来了，原先我以为只要改改DAO层的sql这么简单，后来发发现想多了。因为表数量增加意味着实体类的数量也得增加。然后之前Model也得抽离成多个，以便于对应和维护。比如之前的model层就一个类叫做flow, 包含着所有申请和业务字段，现在要抽离成app, queryobject和auditInfo所以服务层依赖于flow的代码都会受到影响。这里一个降影响的方案是把app,queryObject和auditInfo组合进flow类里面，然后将一些对应的getter setter经行封装，这样就可以做到不影响之前的service层的代码。
还有一个不算问题，应该算职场教训吧。就是不要因为体谅队友就去私下帮忙承担别人的工作。我的队友因为是一个高级研发，所以经理对他的push就比较多，给的任务也比较难比较重。所以我在做完经理给我分配的任务之后，主动去问了他有没有需要帮着做的内容。他也不客气的丢了一堆工作给我。我也觉得还好，毕竟我心里想着的是经理让我俩做这个系统，还是尽早完成比较好，多出来的工作总归是要人来做的。问题是在一个周五，他给了我一个本该由他来做才合适的任务，因为我做的话得花很多时间去阅读文档信息（他已经看过），然后还得逐个跟他核对才能确认哪些字段是需要存储的。然后他直接把这个活给我，我也试着去做了，但就在那个下午，经理来问他进度的时候，他就说我这边做好了才行，能不能做完都取决与我。。。我一脸黑人问号，但是觉得自己答应帮他做事了，也就做吧。后来发现，我是真的不知道他需要的字段，一个个去问，他也烦。后来周六加班，他还吐槽我效率低，说这一周给我的事情实在简单什么的。我心里想着的是，你还真把自己当领导了，这些事情本就都该你做的，经理也是认为你有能力做好，我只是来帮你的好吧，经理那边我本就还有别的任务，而且也就最后这个不合理的分工也是你自己嫌麻烦强行甩给我，并单方面觉得我能做。我就问他质问他”你把这个事情给我你让我怎么做？我怎么知道你在每个阶段需要哪些字段？“ 然后他就开始打哈哈，说什么你要这样说那今天这工作也没法开展咯， 最后还是这厮把字段自己筛出来让我写的处理逻辑。所以周五晚上强行让我背锅，以及周六的这个自以为自己是领导了一样让我很是不爽。你体谅他，他会觉得你是在帮他吗？不会的，他会觉得一切都是应该的，而且还会变本加厉的把自己事都扔给你。
差不多就这样吧，现在处于该数据库以及之前的访问逻辑阶段。