收藏
Refactoring - Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

Refactoring

Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

出版社

Addison-Wesley Professional

出版时间

1999-07-08

ISBN

9780201485677

评分

★★★★★

标签

重构refactoringProgramming软件工程

书籍介绍
Refactoring is about improving the design of existing code. It is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure. With refactoring you can even take a bad design and rework it into a good one. This book offers a thorough discussion of the principles of refactoring, including where to spot opportunities for refactoring, and how to set up the required tests. There is also a catalog of more than 40 proven refactorings with details as to when and why to use the refactoring, step by step instructions for implementing it, and an example illustrating how it works The book is written using Java as its principle language, but the ideas are applicable to any OO language.
AI导读
核心看点
  • 重构不改变外部行为，旨在改善代码内部结构。
  • 提供40多种重构手法，含步骤详解与Java示例。
  • 强调小步修改与频繁测试，确保重构过程安全可控。
适合谁读
  • 希望提升代码质量、摆脱遗留代码困扰的开发者。
  • 正在学习软件工程、面向对象编程的计算机学生。
  • 寻求规范编码习惯、提高可维护性的初级程序员。
读前提醒
  • 本书适合查阅具体手法，不必从头到尾通读。
  • 建议结合单元测试实践，理解小步重构精髓。
  • 示例基于Java，但思想适用于所有面向对象语言。
读者共识
  • 软件工程领域的经典之作，程序员案头必备。
  • 内容详实但略显琐碎，部分读者觉得信息冗余。
  • 新手可能难以理解，建议有一定编码经验后阅读。

本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。

精彩摘录
  • "养成重构后即运行测试的习惯非常重要。犯错误是很容易的——至少我知道我是很容易犯错的。做完一次修改就运行测试，这样在我真的犯了错时，只需要考虑一个很小的改动范围，这使得查错与修复问题易如反掌。这就是重构过程的精髓所在：小步修改，每次修改后就运行测试。如果我改动了太多东西，犯错时就可能陷入麻烦的调试，并为此耗费大把时间。小步修改，以及它带来的频繁反馈，正是防止混乱的关键。"
  • "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啤酒，不必太担心它杀光我的脑细胞。"
  • "作为程序员，我们的职责就是设计出结构一致、抽象合宜的程序，而程序抽象能力的源泉正是来自函数。与其他抽象机制的设计一样，我们并非总能平衡好抽象的边界。随着系统能力发生演进（通常只要是有用的系统，功能都会演进），原先设定的抽象边界总会悄无声息地发生偏移。对于函数来说，这样的边界偏移意味着曾经视为一个整体、一个单元的行为，如今可能已经分化出两个甚至是多个不同的关注点。"
  • "任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。"
用户评论
Improving the design with the existing code
可惜不是js，以及kindle看code真是看不进去
能把这些规律提炼出来确实很牛，可惜匆匆一读，所得不多。
工作一年好代码看多了雷也踩了不少，再读这本就感觉没那么醍醐灌顶了，可能上学时读会更惊艳吧。(然而这也只是马后炮，上学时赶due基本不会想着refactor，而且连踩雷的机会也屈指可数 ¯\_(ツ)_/¯
值得一读。这类书都有点太细节，太琐碎。
当大牛在手把手教你认真对待每一行代码的时候 你还能说什么呢
1 Extract function和split phase 我太赞同了。 其实还是本质还是鼓励small function，更清晰。 2 simplifying conditional logic 最喜欢的三个tool 2.1 decompose conditional 还是使用extract function，让复杂条件更清晰明了。 2.2 consolidate conditional logic 相同逻辑使用一个if 2.3 replace nested conditional with guard clause if else的层次不要太深，影响阅读，影响理解。用简洁的几个if搞定。 3 抽象 抽象降低理解的困难度。 最重要的一点，重构的前提是单元测试。
For much of the history of software development, most people believed that we design first, and only when done with design should we code. Over time, the code will be modified, and the integrity of the system—its structure according to that design—gradually fades. The code slowly sinks from engineering to hacking.
内容是okay 的，但中文翻译还是不太行。
补
你可能会关注的书籍

Addison-Wesley Professional的其他书籍查看全部

收藏