编程界有句很流行的话经常被程序员引用来怼产品，老板等人：不能确保软件中没有bug，世界一流的公司微软，谷歌等开发出来的软件也会有bug。但是一个小功能能不能做到没有bug呢?本文为大家讲述一个功能从产生到上线的爱恨情仇。这是我到新公司之后做的第一个需求，组长问我这个给你一周能不能做完?我认真看了一下PRD和UI文档，拍了拍胸脯保证说一天就够了。

大致描述下需求：我们项目中集成了携程的订机票服务，对于经常出差的人，可能会经常往返两个或多个地方，比如公司在北京，但是会经常去上海和杭州出差再回来。如果在我们集成的定机票页面定机票的话，需要每次都输入出发地和目的地，然后查询。为了优化这一体验，我们为用户提供创建和保存行程的功能，之后用户只需要点击之前创建的行程(比如北京到上海)，我们就自动为填充出发地和目的地然后查询。主要涉及两个页面，草图如下：

说明：

1，行程管理页面(后面统一简称页面一)用于管理常用行程，可以添加和删除，直接点击行程就打开行程添加和修改页面，可对行程重新编辑;

2，行程添加和修改页面(后面统一简称页面二)顾名思义用于创建或者修改行程。如果是点击“添加新的行程”跳转过来的，则行程名称，出发地，目的地都是空的，需要你自己创建;如果是点击某个行程跳转过来的，则会自动填充该行程的行程名称，出发地和目的地，用户可以直接修改保存。

3，将此行程添加到桌面快捷方式后面有一个开关，如果用户打开这个开关，在点击保存的时候就将该行程在桌面上创建一个快捷方式。

之前这两个页面上的功能都已经完成了，除了将此行程添加到桌面快捷方式，而我要做的就是将此行程添加到桌面快捷方式的功能。

我心想这是我紧新公司做的第一个任务，一定要把他做完善。

第一个半天做了技术调研，即如何代码创建，删除和查询快捷方式。很快在GITHUB上找到了一个完善的开源项目 ShortcutHelper，代码在这里我就不帖了，如果对这个技术感兴趣可以去github围观，顺便给作者一个star。

第二个半天对这个功能进行了认真的思考，希望能考虑到所有的情况：

●如果用户是创建新的行程，点击保存的时候判断 将此行程添加到桌面快捷方式的开关(后面统一简称开关)的状态，如果状态为开，则发送广播让launcher帮忙创建快捷方式;

●如果用户是从页面一点击某个行程进入到页面二，则此时需要从桌面查询该行程在桌面是否已经有了快捷方式，根据查询结果重置开关的状态;

●如果用户是从页面一点击某个行程进入到页面二，并在页面二对行程进行了修改，而且该行程在桌面已经创建了快捷方式，在点击保存的时候我们需要对快捷方式的intent进行修改;

如果用户是从页面一点击某个行程进入到页面二，而且该行程在桌面已经创建了快捷方式，如果点击保存的时候开关是关闭状态，我们需要从桌面上删除该快捷方式;

●在页面一，每个行程的后面有一个删除按钮，点击删除按钮需要删除该行程，同时，如果该行程创建了快捷方式，我们同样需要删除对应的快捷方式。

到这里我觉得自己的思维太严谨了，对自己佩服的五体投地。为了避免打脸(之前保证一天就能完成)，我加班完成了代码的编写。

晚上下班回家的路上我还在对这个功能进行思考，看看还有没有遗漏的情形。还真想到了一种情况：

如果用户是从页面一点击某个行程进入到页面二，而且该行程在桌面已经创建了快捷方式，这时开关的状态应该是开，而此时如果用户按home键回到桌面，长按并删除了该行程的快捷方式，之后在打开页面二(由于是按home键，页面二并没有被销毁)，开关的状态是不是应该重置为关?

第二天一早到公司我就加上了相关的代码——之前是在onCreate方法中判断快捷方式状态，把相关代码移到了onResume中。测试了一下，完美运行，于是愉快的提交了代码。

心想我已经考虑的这么周全了，应该不会有bug了吧。

但是很快被打脸了，测试提了个bug：

如果用户已经退出登陆了APP，这时用户点击桌面上行程的快捷方式，是不能直接把出发地和目的地自动填充的，因为这会有泄露用户隐私的嫌疑。正确做法应该是点击快捷方式的时候需要对用户的登录状态进行判断，如果已经登录则直接打开对应页面并填充出发地和目的地，而如果没有登录，则先让用户登录，登录之后再打开对应页面。

改完这个bug之后过了一天，测试又提了一个bug：

如果用户正在页面二创建行程，并且打开了开关，还没来得及点保存，突然来了个电话，接完电话再回到这个页面，由于我在onResume中判断了快捷方式状态并重置开关状态，所以用户本来打开了开关结果接完电话回来开关被我关了。

我认真思考了一些，想到了一种解决方案：在内存当中设置一个变量(后面统一称为switchState)记录该开关的状态，switchState有三个值，一是默认，二是打开，三是关闭。如果用户不主动对开关进行操作，switchState就是默认，如果用户操作了开关，我就根据用户操作后开关的状态给switchState赋值成打开或者关闭。然后在onResume中优先判断switchState，如果switchState是默认，我们就去桌面查询然后重置，否则我们就根据switchState是打开还是关闭重置开关状态。

嗯，测试了一下，完美运行，于是愉快的提交了代码。过了一天，测试又提了一个bug：

如果用户正在页面二创建行程，并且打开了开关，此时用户在通知栏点系统设置，进入系统设置中修改了系统语言，再回到该页面;这时页面会被销毁重建，根据之前代码的逻辑，我们先判断switchState的值，由于Activity重走了生命周期，所以switchState值是默认，这时我们就去向launcher查询该行程快捷方式是否已经创建，根据查询结果我们重置该开关为关闭状态。

解决这个bug思路也很简单，只需要在onSaveInstanceState中保存switchState的值，然后在onRestoreInstanceState中取出来使用即可。

改完这个bug测试再没有提出关于这个功能的新bug，当然这也并不意味着就没有bug了，可能还有测试也没有想到的情况，那就只能留着让用户去反馈了。

后来这个功能上线了，运行了一个月发现并没有用户反馈bug。产品看了一下统计数据，发现这个功能并没有人使用。于是决定在下一个版本删除掉……删掉……掉……