记一次返工之后记

记一次返工后记

作者：Grey

原文地址：

博客园：记一次返工之后记

CSDN：记一次返工之后记

本文搬运自自己的博客园博客，发布于 2018-11-26

说明

之前做的功能, 又有新的需求了，原先的需求是支持某个类型的待办审批，现在是要支持系统所有类型待办的审批，虽然之前的代码写的很匆忙，比较“丑陋”，但是好在未出什么bug，新需求来了以后，我本想乘此机会重构一下自己之前写的比较丑陋的代码，但是因为陆陆续续有插入进来的优先级更高的任务，所以这个新需求一直被hold住，最后有一周的时间来做这个需求，由于要测试的流程比较多，而且创建流程的过程比较费时，为了给测试预留多一些时间，我放弃了重构的念头，先快速实现需求，在保证原有功能和新增需求没有问题的情况下，再一点点重构自己的代码。

原需求

有一个Web系统X，用户可以通过这个系统查看自己的待办信息，并且可以用于待办的审批，还有一个我们做的手机应用Y，Y系统需要支持查看X系统的待办信息并完成审批操作。

新需求

原需求里面说的待办信息只是某两个类型的待办，实际上这个X系统有很多待办类型，而且每个类型的处理逻辑，显示元素都是不一样的，我们现在要实现再Y上支持X系统的所有待办类型的审批。

资源

1. X系统的源码。
2. X系统虽然不是我们公司做的，但是我司运维人员对于X系统的业务相对熟悉。

开发前的准备

为了避免上一次返工的问题之一：需求没有梳理清楚。在写代码之前，开发和测试都需要非常了解业务逻辑，所以，在开发之前，我特意申请了一次培训，让运维人员给我们（我作为开发，还有一位测试人应）讲解一下整个系统的流程，也不需要特别正式的会议室，就几个人在电脑旁边，运维人员从头到尾给我们整个走一遍流程，有任何疑问都当下提出，当下解决， 解决不了的记录下来，运维人员后去请教实际用户这些问题。补充一点：最了解X系统业务的人当然是使用这个系统的用户，可是这个系统比较特殊的一点是，大部分用户都是领导，我们几乎不太可能让领导来花时间来给我们讲整个业务逻辑，只能是当我们遇到一些实际的业务问题，再去和他们请教。而运维人员，算是除了用户以外，相对比较了解X系统的人了，什么？你说X系统的开发人员？这个系统的开发商已经“跑路”了:)

在培训完业务流程后，我还没有急着做开发，而是先让测试人员在X系统上走一遍流程，并把走流程中的一些关键信息（如待办详情，操作按钮，下一步操作选择）截图，一来测试需要了解整个业务流程才知道如何设计测试用例，二来截图也可以给我开发做一些参考，比如需要显示待办详情里面的哪些信息，操作按钮要如何显示，下一步操作要如何处理等。

测试人员在X系统上走完流程以后，我自己也参考测试人员写的操作步骤和截图，走了一遍流程，算是心里有个底了。

遇到的问题

X系统有个测试环境，我们都是在X系统的测试环境中开发和测试的，但是这个环境很不稳定，因为运维人员经常为了排查X系统的问题，会经常把X系统正式环境的数据导入到测试环境，这样我们在X系统做的数据就会被重置，这就尴尬了，我们的开发周期是一周，想在这一周保证测试数据稳定是不可能的了，所以，我又做了一件事，找了一个新的服务器，在这个服务器上重新搭建一个X系统的测试环境（包括应用服务器，数据库），总算是解决了这个问题。

遇到的另外一个问题是，每次X系统中的待办建走到特定节点比较费时，而每个特定节点需要定制开发，比如我们的手机应用Y要支持X系统某个待办的第五个环节，那我需要在X系统上建一个待办，然后一步一步走到第五个环节，然后找这个环节需要显示的信息，需要做的操作，非常麻烦，而且一旦我在手机上操作了这个环节（比如审批了），这个环节就跳到了第六个环节了，如果我第五个环节的东西还没有完全开发完，我又要建一个流程并走到第五个环节，比较麻烦。所以我想了一个办法，就是在走到某个环节的时候，先备份一下数据库，走完这个环节如果想再回去看下的话，直接恢复备份数据库就可以了。

开发和测试

放弃重构想法以后，我开发相对比较谨慎，基本没有改动之前的代码，新的需求都是重新写的代码，并为考虑复用太多之前的代码，虽然几次很想重构，但是还是忍住了，求稳。

业务逻辑理清了，接下来就是要看懂X系统的源码了，X源码注释也比较少，充斥着类似以下这样的代码：

if(StringUtils.equalsIgnoreCase(subTypeId, "501")){
    // do something
    ...
}else if(StringUtils.equalsIgnoreCase(subTypeId, "502")){
    // do something
    ...
}else if(StringUtils.equalsIgnoreCase(subTypeId, "601")){
 // do something
    ...
}else if(StringUtils.equalsIgnoreCase(subTypeId, "602")){
 // do something
    ...
} else if(StringUtils.equalsIgnoreCase(subTypeId, "604")){
 // do something
    ...
}  

我必须一个一个节点走才知道这里的诸如："501"，"604"是什么意思，然后把这里面对应的SQL拿出来分析，看下需要哪些参数，这些参数是如何获取的，而且有些SQL的查询还很复杂，参数很多，我本想直接用正则匹配页面中的这些参数值，后来想想，还是不能依赖X系统的页面信息，我都是直接查数据库获取需要的参数，分析SQL和获取查询参数，耗费了巨大的时间，不过事实证明，这样做是对的，我这相当于重做了一遍X系统了。

接下来是设计X系统集成到我们手机APP系统Y中以后的展示和操作，由于数据都拿到了，我就需要把这些数据转换成我们手机APP中展示的元素，比如：Table，KeyValue，List，这些东西实际上没有一个统一的标准，我们就把详情中比较关键的一些信息显示出来，至于是显示成Table还是KeyValue，这个没有严格的标准，用户似乎不太关注内容的排版，只要是显示了必要信息，简单明了，就足够了，所以这部分”设计“，就按照我自己的想法来做了。

接下来是审批操作，审批操作比较麻烦的一点是，你必须完全了解，点击这个待办的操作按钮背后的所有逻辑，因为我们是要集成待办的操作，所以我们实现的逻辑要和X系统一模一样，最简单粗暴的方案当然是模拟X系统的操作，比如用一些爬虫工具模拟点击操作的按钮，这样我们就完全不需要了解X系统的操作流程了，但是这并不保险，还是因为上一次返工给我带来的教训：万一操作的元素变动了一下，我们的操作就完全失效了。所以这次我还是选择直接理解操作背后的逻辑，说白了就是把操作对应的Ajax请求一个一个看懂并找到对应的参数值，然后发一个一模一样的Ajax操作，当然X系统点击操作还不是简单的拿一些现有的参数发请求，有一些是页面中的js拼装的一些数据，这部分也要完全理解并完全移植过来，一旦有一些操作没有移植过来，如果待办审批出了问题，是非常严重的，因为这些待办涉及比较重要的招投标流程，流程涉及的金额也是很大的。

我回忆了一下，真正写代码的时间实际上不多，花时间最多的是看X系统的源码，和熟悉X系统的业务流程。

最后是测试，因为要在手机APP上测试流程，但是我们自己的工号下面都没有对应的待办信息，需要登录相应的领导的账户才可以拿到待办信息，虽然是测试环境，但是我们手机APP是不会用用户的信息去登录测试的，因为登录后，用户的所有信息我们都可以看到了，解决办法就是，在获取用户待办的时候，我们只拿用户的X系统的待办，其他信息不获取，所以获取X系统的待办逻辑的代码，加了这么一小段逻辑，大概意思就是如下：

this.工号 = 获取登录人的工号(); // 登录人是自己人
Map<String,String> changedInfo = newHashMap();
changedInfo.put("自己人的工号1","有待办的人的工号1");
changedInfo.put("自己人的工号2","有待办的人的工号2");
changedInfo.put("自己人的工号3","有待办的人的工号3");
this.工号 = changedInfo.get(this.工号);

List todoList = 通过工号获取某人X系统的待办信息(this.工号);

感悟

这个需求开发并上线已经两周了，我监控了一段时间运行日志，暂时未发现问题，本次整个开发过程，吸取了上一次返工的教训，为我以后的开发工作也积累了一些新的经验，谨以这两篇博客（本篇博客, 上一篇博客）作为一个记录，也希望可以分享给有需要的人。