《重构-改善既有代码的设计》解读系列 · 目录
本系列共 23 篇文章，点击任意一篇开始阅读。
共 23 篇 · 6 个部分，点击卡片开始阅读。
先读系列导读 →第一部分
重构到底是什么
01★☆☆☆☆
重构究竟是什么？——一个被严重误解的词
为什么「重构」这个词，被程序员用得如此频繁，却又如此混乱？
开始阅读 →
02★★☆☆☆
为什么「不改变行为」是重构的铁律？
如果重构不改变任何功能，那我们到底在改什么？这条铁律为什么不能破？
开始阅读 →
03★★★☆☆
为什么没有测试，就谈不上重构？
测试看起来是在「浪费时间」，为什么福勒把它当成重构的前提？
开始阅读 →
04★★★☆☆
重构不是重写：为什么「大爆炸式重建」几乎总是失败？
既然旧代码这么烂，为什么不干脆全部推倒重写？
开始阅读 →
第二部分
重构的经济学
05★★★☆☆
重构是在还「技术债」吗？
「技术债」这个说法，到底准确描述了什么问题？
开始阅读 →
06★★★☆☆
重构会拖慢开发速度吗？——被忽略的复利效应
花时间整理「能跑的代码」，难道不是浪费开发进度？
开始阅读 →
07★★★★☆
什么时候该重构？什么时候绝对不该？
重构有没有「时机」？还是想改就改？
开始阅读 →
第三部分
识别问题——代码坏味道
08★★☆☆☆
什么是「代码坏味道」？为什么它是信号而不是罪名？
坏味道是「代码写错了」吗？它和 bug 有什么区别？
开始阅读 →
09★★★☆☆
重复代码为什么是头号敌人？
复制粘贴一下明明最省事，为什么福勒把重复代码列为最该消灭的坏味道？
开始阅读 →
10★★★☆☆
为什么函数应该短？——过长函数的真正代价
函数长一点不是能一次看完所有逻辑吗？为什么福勒坚持函数要短？
开始阅读 →
11★★★☆☆
上帝类与过长参数列表：复杂度是怎么堆成山的？
为什么类会越来越臃肿，函数的参数会越来越多？
开始阅读 →
12★★★★☆
发散式变化与霰弹式修改：为什么改一处就崩一片？
为什么有的代码改动总是「一发动全身」？
开始阅读 →
13★★★★☆
基本类型偏执与重复的 switch：什么时候该引入对象？
用一个字符串表示状态、到处写 switch，不是最直接吗？为什么是坏味道？
开始阅读 →
14★★★★☆
依恋情结、数据泥团与消息链：代码的「社交病」
为什么福勒用「依恋」「泥团」「链条」这些奇怪的词来描述代码？
开始阅读 →
15★★★☆☆
「注释是坏味道」这句话，到底什么意思？
注释不是好事吗？为什么福勒把「注释」也列进坏味道？
开始阅读 →
第四部分
重构的方法论
16★★★☆☆
「两顶帽子」：为什么不能一边加功能一边重构？
重构和加功能不都是改代码吗，为什么非要分开？
开始阅读 →
17★★★☆☆
小步前进：为什么重构必须一次只走一小步？
既然要改，为什么不一次改到位，而要拆成许多小步？
开始阅读 →
18★★★★☆
重构与性能：先让它跑对，还是先让它跑快？
重构会不会让代码变慢？应该先优化性能，还是先重构？
开始阅读 →
第五部分
重构的工具箱
19★★★★☆
重构手法全景：提炼、内联、搬移、封装、重组条件
原书列了几十种重构手法，它们背后有没有统一的地图？
开始阅读 →
20★★★☆☆
最常用的三个动作：提炼函数、内联、改名字
如果只练三个重构手法，应该选哪三个？
开始阅读 →
第六部分