什么是重构，什么不是重构
这篇讲的是重构这一常见却容易被误解的软件工程实践。作者从一个核心问题出发：在日常开发中，我们常把各种代码改动都笼统地称为“重构”，但这其中混杂了真正有意义的结构优化和许多名不副实的修改。 文章清晰区分了重构的本质特征。真正的重构，其前提是**不改变软件的外部可观察行为**，它像一次“心脏搭桥手术”——在皮肤之下精细调整内部结构，以提升代码的可理解性、可维护性或为后续扩展铺路，但用户和外部系统对此毫无感知。典型的例子包括提取重复代码为函数、用多态替代复杂的条件判断、或重新组织类的职责。 与此相对，文中列举了几类常被误认为是重构的改动。比如，在修改bug或增加新功能时顺带调整代码结构，这本质上是功能修改，可能引入意外风险；或者为了“代码整洁”而进行的大规模、纯风格的格式统一，却未触及设计层面，其收益往往有限。这些操作如果脱离了“行为不变”的约束，就不再是纯粹的重构。 作者强调，明确区分二者至关重要，因为重构是一种需要纪律、小步快跑、并辅以频繁测试保障的专项活动。混淆概念容易导致项目失控，在不具备足够测试覆盖的代码库中尤其危险。理解重构的边界，才能让它真正成为提升代码质量的可靠工具，而非随意改动的借口。