关于重构的思考

你在重构什么，你为什么重构，你在为了重构而重构？

目前组内项目的代码数量已经到了1.7w行了，架构或者说设计已经逐渐显示出了疲态，有些功能我们已经超出了我们之前的设计范围。我们当前的困境，我们在添加部分新功能的时候已经开始强行兼容，用一些很变扭的操作实现。同时也已经埋下了很多坑。我们应该进行重构的操作，把当前看到的问题整理调并整我们的设计。这周我进行了部分重构的，==目的在与解决相同的计算逻辑重复出现的，以及结果输出和计算过程揉杂的问题。==在重构的过程中我发现我遇到了的问题主要是：

1. 如何平衡需求时间跟重构时间。
2. 重构能力不足，野心大能力小。
3. 重构的目标性不够明确。
4. 缺乏完整的测试重构意味这有风险。
5. 控制重构范围，分阶段，控制风险。

为了重构而重构

这周在完成上线之后我就雄心勃勃的想要重构重构，感觉上自己已经了解了问题可以进行一次完美的重构，但是实际上重构的过程中发现自己在很对问题的理解上还是存在这模凌两可的状态，导致我无法在设计上做抉择。整体对cdn的业务理解不够深刻故我停止了大范围的重构操作，转而思考我到底要解决什么问题，我重构的目的到底是什么，回想到在旧项目上的经验，自己很多的重构的目的性都不强，可以描绘成是一种为了重构而重构的冲动。

从问题出发

只有在明确自己要解决的问题才会胸有成竹，因此我放弃了大而全的重构冲动，转为解决具体的，目的明确的问题的重构方向。带着明确问题重构的过程和结果都能按照预期进行输出。

我们对重构的态度

在我看来我们对重构的态度分为：

1. 从没想过重构。
2. 有想法但是没有行动。
3. 眼高手低，没有着眼于解决问题，想要大而全的解决所有问题。

不得不承认重构是需要很强的综合能力，在能力还不够强的时候我们应该小步快进。必须要明确当前要解决的具体问题后，小范围重构。随着业务地了解跟技术进步慢慢就有了经验跟信心。

最后我有几个小tips关于重构。

1. 不要把所有问题都留给重构的时候解决，写代码的时候就应该避免低级的错误。
2. 勤用注释@todo 在自己犹豫不决的时候暂且把问题搁置，后面及时优化
3. 重构不是银弹，业务决定架构，对业务理解更深，重构的范围才能扩大。
4. 多写测试重构的时候你就知道到底有多有用了。