书籍介绍
这本书最打动人的，不是它给出的重构名录，而是它反复强调的一件事：重构必须有一组可靠的测试作为安全网。Fowler近乎执拗地要求「小步修改，每改一步就运行测试」，把犯错的风险压到最小。这种对「脆弱」的警觉，恰恰戳中了真实开发中最难的部分——我们往往不知道问题出在哪里，而书里的方法默认你已经找到了它。因此它更适合有一定经验、正在重新审视既有代码的开发者，而非零基础入门者。它不教你「如何判断该不该改」，而是教你如何在改动时保持代码行为不变。读完你会获得一种近乎匠人的工作习惯：让代码常拭常新，而非任其在重复与拖沓中腐化。
AI导读
核心看点
- 系统阐述重构原理与最佳实践，改善既有代码设计
- 提供完整重构名录，详解动机与技术，如提取方法
- 强调小步修改与频繁测试，确保重构过程安全可控
读者共识
- 建立重构意识，认识到写出人类易读代码的重要性
- 部分读者认为步骤描述过于琐碎，实操依赖工具辅助
- 经典之作，虽知易行难，但对审视现有代码极有帮助
精彩摘录
- "养成重构后即运行测试的习惯非常重要。犯错误是很容易的——至少我知道我是很容易犯错的。做完一次修改就运行测试，这样在我真的犯了错时，只需要考虑一个很小的改动范围，这使得查错与修复问题易如反掌。这就是重构过程的精髓所在：小步修改，每次修改后就运行测试。如果我改动了太多东西，犯错时就可能陷入麻烦的调试，并为此耗费大把时间。小步修改，以及它带来的频繁反馈，正是防止混乱的关键。"
- "to make the software easier to understand and modify."
- "refactoring does not change the observable behavior of the software Why Should You Refactor? Refactoring Improves the Design of Software Refactoring Makes Software Easier to Understand Refactoring Helps You Find Bugs Refactoring Helps You Program Faster 即使在开发过程中，当你发现重复或相似的代码时，也应该立刻重构；当变化发生时，如果该变化影响不"
- "复制一遍代码似乎不算太难，但却给未来留下各种隐患：一计费逻辑发生变化，我就得同时修改两个地方，以保证它们逻辑相同。如果你编写的是一个永不需要修改的程序，这样剪剪贴贴就还好。但如果程序要保存很长时间，那么重复的逻辑就会造成潜在的威胁。"
- "每当我要进行重构的时候，第一个步骤永远相同：我得确保即将修改的代码拥有一组可靠的测试。这些测试必不可少，因为尽管遵重构手法可以使我避免绝大多数引入bug的情形，但我毕竟是人，毕竟有可能犯错。程序越大，我的修改不小心破坏其他代码的可能性就越大——在数字时代，软件的名字就是脆弱。"
- "很多时候那个未来的开发者就是我自己。此时重构就显得尤其重要了。我是一个很懒惰的程序员，我的懒惰表现形式之一就是：总是记不住自己写过的代码。事实上，对于任何能够立刻查阅的东西，我都故意不去记它，因为我怕把自己的脑袋塞爆。我总是尽量把该记住的东西写进代码里，这样我就不必去记它了。这么一来，下班后我还可以喝两杯Maudite啤酒，不必太担心它杀光我的脑细胞。"
- "作为程序员，我们的职责就是设计出结构一致、抽象合宜的程序，而程序抽象能力的源泉正是来自函数。与其他抽象机制的设计一样，我们并非总能平衡好抽象的边界。随着系统能力发生演进（通常只要是有用的系统，功能都会演进），原先设定的抽象边界总会悄无声息地发生偏移。对于函数来说，这样的边界偏移意味着曾经视为一个整体、一个单元的行为，如今可能已经分化出两个甚至是多个不同的关注点。"
- "任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。"
目录
Chapter 1 Refactoring, a First Example 1
The Starting Point 1
The First Step in Refactoring 7
Decomposing and Redistributing the Statement Method 8
Replacing the Conditional Logic on Price Code with Polymorphism 34
显示全部
用户评论
2013-07-20断断续续终于看完一遍了，后面就放到桌子上当作参考手册了，需要的时候翻翻//淘宝买的，很久没买书了。纸质的有点臭，在桌子上摊开有段时间了，没气味了。
主要是代码层次的经验，大牛间逐渐形成的一些无形规范，读的很快，有时间可以再翻下，回头对照自己的代码。
求书
收藏