重构复杂度与代码复杂度非线性相关：失控的工程，重写往往比重构更划算

重构复杂代码在技术上要完成三件事：理解旧代码、分解旧代码、构建新代码——而这三件事的难度会随着待重构代码本身难以理解、模块间过度耦合导致牵一发动全身、以及旧代码难以测试导致无法保证新代码正确性这几个因素而急剧放大。一个关键但容易被低估的现象是：重构所需要的复杂度和代码本身的规模不是线性关系——如果1000行烂代码重构大约需要1小时，5000行同类烂代码的重构可能不是简单的5倍关系（5小时），而是需要2到3天，因为随着代码规模增长，模块间耦合关系的复杂度往往是超线性增长的（更多的模块意味着更多可能的相互依赖组合）。这个非线性关系带来一个重要的实践启示：对一个已经失去控制（严重耦合、极难理解、几乎无法测试）的工程做重构，很多时候实际效率反而不如直接重写来得高——因为重构必须先花大量精力”理解”这份已经混乱不堪的旧代码，这个理解成本本身就可能超过了从头设计一份新方案所需要的成本，而重写不需要背负”必须先搞懂旧代码在干什么”这个前置负担，可以直接从清晰的设计出发。这个案例给出了一条评估”该重构还是该重写”的实用判断标准：不能简单按代码行数或者项目规模去线性推算重构的工作量和风险，而要具体审视这份代码的耦合程度和可理解性——耦合度越高、越难理解，重构所需付出的隐性成本（理解成本、影响范围排查成本、正确性验证成本）就越是呈超线性增长，一旦这些隐性成本已经膨胀到失控的地步，直接重写反而可能是更高效、更可控的选择。