【读书活动感悟分享】愚公-《重构：改善既有代码的设计》读后感

在此之前之前改代码靠直觉，看完后才明白重构有套路。
第一次重构的狼狈
接手一个老项目，函数几百行，各种 if-else 嵌套。我花了一周重写，上线后出 bug，又花两周修复。看完书才知道问题在哪：改得太大、步子太急。应该小步走，改一点测一点，保证每一步都不坏。
测试的重要性
书里强调测试是重构的前提。一开始不习惯，写测试比改代码还慢。但跑过几次后，测试救了我很多次：改了某处后测试报错，立刻知道哪步走歪了。现在改代码前先补测试，至少有核心路径的覆盖。
那些“坏味道”真的有用
第一次读到“代码坏味道”就眼前一亮。比如“重复代码”，以前不觉得重复是问题，但维护时改四五处才能同步，容易漏。现在遇到重复会先提取，哪怕只是两三行。
“过长函数”也常见。一个函数写 200 行，以为逻辑清晰，过几个月再看就懵了。现在超过 50 行会拆，每个函数职责单一，看起来啰嗦，但维护轻松。
重构手法的实用性
书里的手法很实用，比如“提取函数”和“内联变量”。之前见到长表达式会拆成多个变量，以为可读性好，后来意识到有些中间变量没价值。现在会先问：这变量有意义吗？没有就内联回去。
“搬移函数”也常用。之前代码结构乱了，函数在 A 类但逻辑依赖 B 类，耦合重。慢慢搬移后，依赖更清晰，测试也更容易。
重构时机的纠结
什么时候重构？书里说“三次法则”，实际执行有难度。有时候写新功能时发现旧代码别扭，是停下来重构还是先上线？我的做法是：如果影响新功能且改动不大，立刻重构；如果影响大，标记技术债，排期处理。
重构不是万能的
书里没说但实际会遇到：有些代码不值得重构，甚至重写更快。比如技术栈过旧、逻辑混乱、无人维护的模块。这种时候，花时间重构不如重写或替换。
团队协作的难点
个人重构容易，团队协作就难了。你重构了，别人不理解，后续改动又打回原形。要有共识和规范。现在我们会在 Code Review 里讨论，重构要有理由，不能为了重构而重构。
持续改进
重构不是一次性的活，是持续改进。每天改一点，代码质量会慢慢变好。别指望一次性把代码改到完美，一步一个脚印更实际。
总结
这本书最有用的是把重构从“感觉”变成了“方法”。有章法、有步骤、有测试保障，重构就不再是冒险。虽然有些手法用起来还不熟练，但思路已经在日常改代码时用起来了。
如果你也在做代码维护，建议看看。不一定全照做，至少知道哪些能做、该怎么做，而不是全凭直觉。