这是我很久以前的一篇笔记。我一直有写笔记的习惯，不过大多数都是写给自己的，最近我开始公开其中一些。
2018 年 11 月 26 日：
有两个非常阻碍我的编程习惯，一个是复杂化倾向，一个是重构倾向。拜读过很多经典后，复杂化倾向已经大幅减缓了，现在更主要的缺点是重构倾向。
为了完成某个任务而打开代码，结果越看越不开心，总想这改一点、那改一下，要不换个框架，甚至换个设计思路。于是一个简单、轻松就能完成的任务，开始变得越来越繁重了。我总是这么走上弯路。
重构的工作量不仅仅是重写代码，还包括对新代码的调试，对原来业务的兼容，以及对新代码
新依赖稳健性的观察，甚至需要重新调配外部资源……每次重构，都在引入新的不确定性。
重构后的代码可能除了“赏心悦目”，在其他方面并没有新的好处。
所以要设置警报。当我开始着手大幅修改原有代码时，应该在心里立即拉响警报——反问自己，我又被重构诱惑了吗？
那么如何避免重构呢？
- 一开始就写出正确的代码，防止未来的自己瞧不上
- 一开始就搭起足够稳健、可拓展的架构，防止未来的技术债
- 正确地对待代码，达到职业水平即可，不要投入“太多的心力”
2023 年 06 月 14 日：
从几年前，重构就再也无法诱惑我了。
绝大多数时候，“要不要重构”就不会是一个问题。因为只有两种情况会让我决定重构：
- 重构后有极大的好处，可以解决项目当前最重要的问题。这种情况往往和性能瓶颈有关。
- 今天不重构有极大的确定性坏处，将导致未来更难被重构。这种情况往往和系统拓展性有关。
重构的代价是引入新的不确定性，要有足够的收益才能支付代价。所以除了上面两种情况，我总是倾向于保持现状。代码风格是否优雅、设计思路是否精妙，都不会影响项目是否成功，但是稳定性和开发成本却能够影响。
我很少重构，而且每次重构都会非常迅速。每次重构前，真正的重构工作可能很早就开始了（以一种渐进的方式），最后只需要将那些有破坏性的工作集中完成。这么做的话，可以让不确定性更加集中，影响的时间也更短，比如容易测试验收。