重构的时机

最近又开始读重构这本书了，这次换成了原版。
同时最近也开始当小兵，在project里完成一些功能。 面对着基于遗留系统的设计，重构又要祭出来了。
这里边回顾，边总结，边学习，边理解下重构的时机哈。
进入项目的时候需求PK什么的并没有参加，只是一无所知的直接去参加需求确认会了。
然后就进入项目了。根据PM的分配，接手了一些系统交互的功能设计和数据处理，另外由于需求的变化重构一期的功能设计。
        从数据库表格的重构开始，涉及了数据迁移，功能的变更，几乎是完整的重新实现了原有功能，这里可以看到设计的缺陷，一二期相差并不是很久远，却要完整的重构，对资源的浪费太那啥了。所以，重构并不仅仅是代码要重构，过度设计不好，但必须斟酌设计方案，留有必要的扩展和重用空间。设计要斟酌，设计方案完成后是一个重构时机哈（未必要重构）。
      完成了UC文档和设计文档之后，经过确认开始了编码工作。期间，大致构思了精确到函数的代码套路。但在设计实现的时候还是出现了一些重复的功能，重复的数据，实现功能之后，review一次代码。整理了一下代码实现，这里完成了第一次代码的重构。这样的话，代码质量更可读性都能提高不少。这个点很重要。
      和同事交互系统时，出现了一些公共暴露服务过于琐碎的情况，这个当时设计的时候没有考虑到，属于经验欠缺型，由于项目进度的关系，不能进行重构了。我也没有办法，小兵只能建议不能强制实施，如果我是PM，这个点上需要重构的，一则减少一些重复代码，二可以统一编程风格，有利于后来人接手项目能够更容易的完成一些改动。但这个点比较遗憾没有做。
      三的话就是测试中发现bug可能涉及到代码的小部分改动，这是进行局部函数和变量的重构。这里不鼓励大改动，这样会增加BUG出现的风险，给测试人员带来不必要的工作量增加。
     基本上在新项目上重构的时机就是这些吧，可能代码之外的重构时机不太完整，受限于经验，暂时能想这么些吧。