【杂谈】记近期项目的三次重构

对于程序员的我以及大家来说，代码重构似乎是非常常见的事情，也是大家乐于去做的事情。因为无论是重构自己的设计或代码，还是重构其他人的设计或代码，都能有一种重构后的成就感，会清楚的感觉到重构后代码的干净度以及功能问题的考虑的完善程度。但有时候会出现不得不重构的情况，比如

1. 之前的功能实现错误或者不完整，但却难以接手完善

2. 为迎合一些策划或产品的特殊需求对设计做了一些特殊的处理，虽然功能得以实现，但却可能存在一些新的问题

3. 在前期的开发中，使用了一些第三方的工具作为辅助生成一些自动化代码但却无法进行扩展

诸如以上种种原因，也是我这三次重构代码遇到的三种情况。不得不重构和发现这段代码有更好的实现方式或者发现更妥当的解决方案的感觉是不同的，因为项目的工期是已经定下来的，重构过的代码又得进行详细的测试，再加上不得不重构的时候项目所处的阶段的影响，可能会让人感觉到一些不爽快吧。

第一次重构的出现就是上述说的第一个原因。之前一个试用期的同事在试用期之间实现的功能。因为我是为了项目的进度而中途加入的，所以对之前的项目的具体情况并不是很熟悉。那边的领导跟我说，现在需要在该功能上添加一些小功能。我就问了一下那个领导，该功能做完了吗？他给我的回复是做完了，现在只是加小功能。可等我看了具体的需求和真正的功能结果，我只能说要哭了。因为整个功能不完善，并且结果也是错误的，还加上不容易扩展，我看了之后只能进行重写。

第二次重构是为了迎合一个特殊需求所做的重构。因为该需求实现之后遇到了诸多的Bug，每次解决以后还是可能会出现新的Bug，总是很难以找到Bug出现的原因，解决Bug也计较耗时。这次我是直接推翻之前的需求方案，经过与运营的再次确认，重构了之前的实现。当然可能也是因为自己还需要加油，对于这种问题需要更进一步的学习，掌握如何快速定位这种较难复现但确实存在的Bug。

第三次重构是因为项目前期在搭建的时候使用了第三方工具生成的自动化代码，但这工具又不是那种开源代码的附属工具，而是前同事使用的工具，因为不容易扩展，在项目中需要进行扩展的时候特别麻烦并且容易引发新的问题。这也是大量使用第三方的工具所造成的代码可控性的降低。