自己负责的系统在新年凌晨上线了一个新功能，但是就目前的反馈来看，业务方不适应，屡次咨询，产品都忙得焦头烂额，我们更是各种修复bug和维护数据。任务多时间紧不能算是借口，这次开发暴露出系统的诸多问题，还需要好好反思。
反思一：事务执行过长或流程分段执行，缺少校验机制
表现出来就是（可能测试环境多一些），制单很长时间，提示制单失败，看后台日志发现，是事务超时了；
还有一个表现就是，前不久给外部提供的几个接口，可能存在不一致性的问题。
从开发的角度来说，则是制单流程，从流程引擎启动到业务数据变更，中间执行过长过长，而且还有跨库操作（流程引擎在另外一个数据库），当数据库访问慢的时候这种方式的弊端就出现了；另一种则是设计上的缺陷，没有考虑到流程的一致性，或者说是缺少校验机制，目前只是加上了关键信息，后期必须完善。
反思二：数据查询效率低，耗时长，导致事务超时
表现出来就是，系统首页访问的时候，都特别慢，甚至有些详情页面都需要很久才可以正常显示，太影响用户体验。
从开发的角度来说，则是在数据查询方面，有了太多的动态SQL，把排列组合都可以数的过来的情况全部拼在了SQL里面，导致每次查询都去判断各种条件，不仅参数繁多，而且很容易错；而且查询语句中有一些为 select * 或者查询条件中有了类型转换或者出现了函数，导致索引失效，查询效率变低；还有一些关键字查询为 OR LIKE '%...%'，而且并没有合理使用参数化，比如像 deleteFlag 删除标志完全没有必要预编译，直接写到参数里即可。总之，这些因素导致了整个系统看起来慢的不行，可优化之处还有很多，不能只是为了达到目的而牺牲性能。
反思三：代码不严谨，缺乏完整性考虑
表现出来就是，系统的周一上线，基本上每次都是因为之前的某个地方考虑不周全导致的，紧急而不严重的bug。
从开发的角度来说，则是在判断某些特殊情况的时候，没有考虑到全部的情况，自我测试的覆盖面不够，埋下了一些测试都很难发现的隐藏bug，这只说明开发并没有真正站在用户的角度去思考流程，设计逻辑，编写代码，可能是先按照理想情况走通逻辑，然后再加上各种情况判断或者权限校验，这种情况下，如果没有很全面完整的考虑，很容易遗漏一些点，仅凭测试或者产品很难一应俱全，毕竟时间和精力有限。
所以，作为开发，必须先保证流程贯通，异常情况考虑周全，基本测试通过，再交付测试，来回返工的话，浪费的可不只是时间。
反思四：流程设计繁杂，该提醒的地方没有提醒，用户反馈多
表现出来就是，这一级流程结束了，不知道下一级谁来操作；任务数混乱，本来有提醒，点击进去什么有没有。
从开发的角度就是，确实流程化的显示指引，不是单单存到数据库里就可以了，如果页面没有任何提醒，或者不知道流程到底有多长，很多时候用户都是摸着石头过河，以为流程结束了，然后去做了操作，也许这里正好有个隐藏bug，这时候点击恰巧触发了，用户碰到了这种莫名的问题，自然就去提反馈了，每天处理反馈，修复bug，没有从源头解决，用户反馈数永远降不下来。
反思五：界面引导性差，缺少关键提醒，误操作频率高
表现出来就是，该单选的地方允许多选，其实用户根本不需要多选，设计多余，还有一些关键操作，没有任何提示，很容易点错其他报销单，这时候就只能修复数据了。
从开发的角度来说，则是开发很多时候并没有get到产品的点，只是按照自己的思维去开发设计，以为用户都是产品经理级别的水平，不会有任何误操作，就想当然地省去了很多校验或者提醒，加之需求急着上线，抱着先把流程跑通，以后再优化的思维，就上线了。然后用户就各种莫名地点错，然后就开始了修复各种边边角角的bug，甚至有时候一个迭代下来，发现什么也没做，净是改bug和修复数据了。
这一点其实也是看了微信最近的界面体验设计以及最近刚刚发布的小程序功能，很多启发，产品设计好，有很多因素，但是开发要进阶，还是要有产品的思维。
