你可曾体会过，在你修Bug的时候，还有Bug在等你修；
你可曾体会过，每天至少有四五个Bug等你修；
你可曾体会过，早上刚到座位拿出电脑看到的第一条消息就是有人在给你说Bug；
......
前言
相信看过 重构之十六字心法 的人即使不记得文中的具体内容，但至少也记得下面这十六个字：
这十六个字，看似简单，但真正重构的时候又有多少人能够做到呢？同时，又有多少人能够做到重构的同时又不产生新Bug呢？
至少我是没有做到，因为这次重构，总有Bug在等我。
起始
这场Bug在等我的风暴始于一个在原有功能上扩展新功能的需求，同时原有的数据结构又不支持新功能的情况下。
按照以往的惯例，针对上面的情况，我们有两种方案：一先重构使原有功能支持新的数据结构，再进行新功能的开发；二按照原有数据结构开发新功能，新功能开发完成后进行重构，使得新旧功能都支持新的数据结构。
那么问题来了，当你按照原有的结构进行前端新功能的开发；而后端相应的接口已经进行修改，符合新的数据结构，同时你在做前端新功能的时候遇到一个问题Block了你的开发。这时候，你请教了周围有经验的人，他告诉你，前端Redux中的数据结构也需要改成新的结构。
此时，针对前端你是继续按照原有的数据结构开发新功能呢？还是直接进行重构呢？
有人建议，先按照原有数据结构开发完新功能再进行重构。是的，我们确定应该这样做。然而，后端接口已经改成了新结构，前端如果按照原有结构继续做下去，这和我们后面要进行的重构是背道而驰的。
过程
在强哥的建议下，前端我们先把新功能按照新结构写，再重构原有的功能；后端为了不block其他人的开发进度，暂时先将原有的字段加入返回值中，待前端重构进行完成再删除。
于是，就这样和强哥pair开始了我们这次的重构。
在和强哥pair重构的过程中，我每天都会写出不同的Bug，然后强哥带我分析、定位、解决Bug。
印象最深的还是，连续被一个循环调用坑了两次，在通过强哥两次直觉解决问题之后，第三次终于凭自己的直觉帮其他人解决了她写的由于循环调用而引起的Bug。
同时，在一次BA提出基于我们所做的增加新需求的时候，能够和强哥针对新需求给出基本一致的解决方案。
重构过程中，由于我们对于原有功能的业务都不清楚，只能边写边读，读不懂的就问不同的人，虽然产生的Bug很多，等我们的Bug也很多......
结尾
重构和新功能的开发虽然基本已经完成了，但是Bug还测完。预计还有一波Bug在等我。
有人问我，这次重构有什么想法？
我只能说，以前写的Mobile，都不是Mobile，这次写的才是真正Mobile。
代码写的多了，Bug也就多了，等你的Bug也就多了。
