记一次返工

记一次返工

作者：Grey

时间：2018-05-12

原文地址： http://www.cnblogs.com/greyzeng/p/9029530.html

说明

本周我经历了参加工作以来，最大的一次返工，这一周都是茶饭不思的感觉，特此记录一下，防止后续犯同样的错误。

需求

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

思路

刚拿到这个“粗粒度”需求的时候，我没有进行足够的需求分析，就开始“信心满满”梳理了一下自己的思路：

第一步：

X系统已有获取待办列表的接口，所以，获取待办列表这件事，我只需要调用X系统接口并转换成Y系统需要的数据结构即可。

第二步：

我当时的方案是通过X系统提供的一个后门URL（这个URL可以直接打开某条待办的详情）然后用爬虫抓取待办详情，详情的抓取最初考虑的是用js找一堆页面元素的值，因为详情内容比较多，且分布在多个iframe和tab页面中，所以要模拟浏览器跳转到相应的iframe或者tab中抓取相应的详情，这也为后续埋下了一个坑（因为要模拟浏览器操作，切换页面等操作会导致抓取详情时间会偏长，而Y系统获取请求的时间只有10s，超过10s的就会显示数据加载失败了）。

第三步：
待办详情中有附件信息，我们无法通过抓取得到详细的附件URL，所以需要在详情页面中，获取相应的附件的ID，然后在X的服务器中部署一个我写的小程序，这个小程序可以通过附件ID查询X系统数据库获取附件的物理位置，然后拿到附件信息，并发请求到我们的文档转换系统中，可以将附件转换成图片，转换成图片最大地好处是可以在移动端很快速的预览。

第四步：

第二步中的后门URL包含了审批信息输入框和审批按钮， 我只需要找到审批意见输入框，用js脚本填入审批意见，找到审批按钮，模拟浏览器点击审批按钮行为进行审批操作。稍微复杂一点地是要判断点击审批按钮以后，是否需要选择下一步地审批人，这一步也好解决，通过抓取详情页面中下拉选人框中的内容，就可以把下一步需要选的审批人也抓取出来并告知Y系统下一步需要支持选人的操作。

梳理完以后自己的思路以后，当时我是这样的感觉，

然后就“信心满满”进行开发了。。。

第一次尝试：JS抓取页面信息

待办详情的抓取时间很不稳定，大概十次有6次会超时（超过10s），我们有一个抓取的小程序，采用的是Phantom JS，我就用这个小程序进行详情的抓取，逻辑大概是：

1. 打开待办URL，这个URL是后门URL，包含了用户登录的操作，所以是必须打开的一个页面。
2. 等待页面完全打开,我是通过判断页面中某个元素是否存在来判断这个页面是否完全打开了，即如果元素存在，证明页面已经完全渲染完毕，如果不存在则一直等待页面渲染。
3. 然后开始抓取详情，这里需要切换一个iframe和打开两个tab页面，分别从里面获取需要的数据。但是这个过程太长了，因为1和2已经耗费了大约3s多的时间，后面的切换iframe和切换tab，都要等页面完全渲染完毕才能抓取信息，导致时间经常会超过10s，如果增加超时时间，体验又会明显变差，这显然是不能接受的。

第二次尝试：发Ajax请求获取数据

面对超时问题，想到了另外一个解决方案，通过发ajax请求，直接获取详情数据，Chrome控制台下看了一下待办详情页面请求，大部分入参都可以通过正则查找当前页面来获得，这便减少了两次切换页面的操作，但是有几个参数没办法在当前页面获取，还是需要至少切换一个tab来获取。

所以，解决办法就变成了：

1. 同上
2. 同上
3. 然后开始抓取详情，先在当前页面获取到能获取到的所有需要发请求的入参值，然后用Js逐一发送请求获取详情。因为是逐一发ajax请求，要等待返回值操作再发下一个请求，虽然比第一次尝试速度有所提升，但是速度还是不稳定，还是会出现超时现象。

第三次尝试：Promise.all并发请求

第二次尝试的瓶颈在于，串行发请求，速度还是有很大的限制，Js能否实现并发请求呢？说来惭愧，之前一直是做后端，用Java开发，连Js并发操作这件事，都不是特别清楚，所以就查了相关的资料，发现了Promise.all

将Ajax请求一个个封装起来，诸如：

runAsync1()

runAsync2()

runAsync3()

等若干个这样的方法，
然后通过Promise.all来并发执行这些请求：

Promise
.all([runAsync1(), runAsync2(), runAsync3()])
.then(function(results){
    console.log(results);
});

用Promise.all重构完以后，我的心情是这样的：

当我“战战兢兢”再一次尝试获取详情的时候，速度是快了，但是，还是不稳定，还是会出现超时的现象（10次大概有5次，这个频率也是无法被接受的）。

第四次尝试：WebMagic并发请求

我坚信用JavaScript做这件事还有其他优化的方向，限于技术能力，我当时能想到的用JavaScript来处理的方式就这么多，而且截至时间马上要到了，我没有时间再去探索了，所以我用了自己相对熟悉的WebMagic很快地重构了一版，并发抓取详情，发现，速度快了，而且也稳定很多了，10次可能最多2次超时，后来仔细分析了一下超时的原因，ajax请求发送过去以后，对方有一两个请求返回非常慢（30s以上），这件事我反馈给自己的领导，当时是没有解决方案，对方系统目前不可能做优化。

好吧，就到这里吧，可以开始流程测试了！

测试

我并没有马上提交测试人员进行测试，我想自己尽可能先走几个流程，自己先测试整个流程是不是有问题，因为自己没有用过X系统，所以找了相关的一位同事帮助我建了一些测试的流程，我走了几个测试流程，发现，还蛮顺利的，流程性的bug基本没有，详情的抓取内容也正常，我当时就恨不得马上就可以上线：

正当我“信心满满”地准备交付的时候，心里还是不自觉地警惕了一下，要不再测一个流程？这一测，心都拔凉了,发现了一个大bug，
原来待办详情没有那么简单，待办详情里面有一个列表，我一直觉得这个列表是作为详情显示的，没有什么特别的地方，
可是后来我发现，这个列表里面的每一项，都可以单独进行审批！这就意味着，原先的思路就是错的！

原先的思路是：

点击待办->查看详情->审批

而正确的思路是：

点击待办->查看这个待办中的条目信息->点击条目信息->查看条目信息->审批

此刻，我的心情是这样的：

可是又有什么办法呢，硬着头皮也要改！

第五次尝试：从数据库取数

上述bug带来的问题不仅是架构的问题，还有性能，相当于每个条目都要切换一次页面重新发送请求获取详情，
所以在待办列表点击进入条目的时候，要准备好每个条目需要的ajax请求参数，这会增加条目获取的时间，用户打开条目目录这件事，就要花去相当于之前看待办详情的时间，然后点击条目再看详情这件事，也要花去同样的时间，用户体验会极差，很大可能又会是超时。

最后，各方沟通，我们决定直接访问X系统数据库拿数据，因为是遗留系统，开发商已经不在了，运维人员也只有代码并做一些简单的维护，我们决定直接看X系统的源码来找到相应的逻辑，并用sql来查询并获取X系统的数据。

幸好，我们找到了大部分SQL语句，SQL的参数，之前在查找Ajax请求的时候，已经找到大部分了，所以我在附件抓取程序中将待办和条目详情获取的逻辑转换成直接从数据库查询数据。在此，感谢MyBatis-Spring-Boot-Starter，@Annotation的方式简直比之前的XML方式提升了太多的开发效率，我几乎可以原封不动拷贝原系统的SQL来进行查询，用法如下：

@Mapper
public interface MyMapper {

    @Select("select x as y from xxx where xx=#{p}")
    List<Map<String,Object>> findByState(@Param("p") String p);

}

这里的

select x as y from xxx where xx=#{p}

就相当于是X系统原封不动的拿来的SQL语句，数据结构也来不及设计了，就用List<Map<String,Object>>把！

改成从数据库拿数据以后，没有了超时的问题了，重新测试了几个流程，都正常了，终于可以舒一口气了，但是心情却很是复杂。

感悟

充分理解需求，应该在开发之前充分地理解需求，细化需求，由于需求理解不到位而返工开发的代价是巨大的。

在第三次尝试中，有一个插曲，当时我面临两个方向的技术选择，一个是使用自己相对不熟悉的JavaScript来做并发, 另一个是当时自己相对熟悉的Java中的爬虫抓取工具WebMagic，也可以很好地实现并发操作。如果用WebMagic，或许并发和使用这块，我会更加熟悉，之所以当时先选择了JavaScript来做，是因为当时脑海中冒出了这样的的想法：

自己的Js技术相对Java要弱一点，就要多锻炼一下，所以就一直再探索用JavaScript可以有哪些优化的地方。毕竟自己的目标是希望可以做一个全栈工程师。

我似乎忘记了这是一个工作任务，完全把这个当成了自己学习和锻炼的途径，忽视了工作任务是有截至时间的。

这几年，自己的学习方式大多是蜻蜓点水类型的，喜欢学习新技术，但是都不太深，后来，和一位老员工沟通了这件事，他告诉我一个很朴素的道理：

技术层出不穷，人的精力却是有限的，语言只是一种工具，重要的是编程思想。