代码重构的时机与要点

代码重构的结果至关重要

对于程序员来说，重构的意义似乎不需多说，大家公认的干净的代码是更好的。

在非程序员主导的项目中，做重构则需要对结果有更多的负责，一旦重构带来更多的bug以及进度的delay，重构本身就会被怀疑，牛逼和逗比只在一线之间。

重构的时机

最好的时机就是task收尾阶段：子task结束就清理子task的代码，大task结束就清理大task的代码。

有这么几个原因：

- 测试资源：一部分代码一旦经过QA测试之后，本身的成本就上升了（程序员+QA的投入），如果重构发生在QA测试之后，那么QA的测试的资源就被浪费了，游戏上线之后做，就有更多的浪费

- 对于代码的熟悉度：刚刚结束的时候，是记忆最好的时候，重构会格外的高效，当然过一段时间可能有不同的想法，但这和基于熟悉的部分是两码事情

- 在清理过代码之后，对于所实现的东西，会有最好的清晰度，心里也会感觉比较踏实清爽

一般来讲，在task任务结尾处做清理，是非常合理的，而如果后面单独拉出来作为一个任务来做，它就要和其他的任务来对比优先级，这个时候如果代码运行没出问题，那重构优先级对比常常处于下风，即便程序员自己此时恐怕也会做出不重构的选择的。

重构的意义

对于项目自不必说了，长期观察下来不重构伤害最大的是程序员本身。

重构本身好像是一个修炼的过程，静下心来把写过的东西重新整理一番，如果反思一样。

逐渐的会养成好的代码习惯，看见自己的不足进而学习长进，进而会习惯于第一版写出好的代码。

而不重构，则丧失了很宝贵的反思学习的机会，习惯于写乱的代码这个会很危险，后面想改过来，恐怕要很长的时间了。

而写出简洁代码的能力，是做大型项目的非常重要的一个能力，大型项目头号挑战便是复杂度。