Martin Fowler
用一个词来形容作者 Martin Fowler,那就是牛逼!他是作家,演说家,企业应用架构专家,敏捷宣言发起人之一。专注于OO、UML、领域建模和敏捷软件开发。他写的 《重构》出版于1999年, 《企业应用架构模式》出版于2002年,都可以算是程序员必读的书。
Refactoring
对《重构》心仪已久,某天见到同事带了一本到公司,还是英文版的,就马上抢了过来读。这是除了大学教材之外,我第一次完整地读完一本英文技术实体书。读完之后我才发现,网上有个 在线版,内容基本与实体书一致。
全书可以划分为三大部分:第一部分讲解了重构的基础,包括一个例子、一些原则、code smell讲解和如何构建测试;第二部分是重点,讲解了各种重构方法;第三部分是关于重构的其它一些话题,例如大型重构、重构工具等。
整本书读下来,我觉得收益最大的,就是知道了各种各样的 code smell 和相应的重构解决方法。以后在写新代码时,在一些细节设计上可以规避已知的这些 code smell 问题,提高代码质量。在维护旧代码时,也能记起,哦,这个问题可以用XX方法来重构解决~
要说缺点的话,我觉得作者对每个重构方法都详尽地列出了操作步骤,似乎有些冗长。我不知道是否有人真的完全按照作者的步骤去做重构,反正我一般都没有做得那么细,可能工具的支持比较好吧,Eclipse 的重构功能真的很好用。
本文就不列出那些 code smell 和重构方法了,只记一些重构相关的原则。
什么是重构
重构就是为了让软件更易于理解和维护,对软件的内部结构进行的、不影响外部行为的修改。
这个定义有两个重点:目标是“让软件更易于理解和维护”,所作的修改必须“不影响外部行为”。
为何做重构
用一个词来形容作者 Martin Fowler,那就是牛逼!他是作家,演说家,企业应用架构专家,敏捷宣言发起人之一。专注于OO、UML、领域建模和敏捷软件开发。他写的 《重构》出版于1999年, 《企业应用架构模式》出版于2002年,都可以算是程序员必读的书。
Refactoring
对《重构》心仪已久,某天见到同事带了一本到公司,还是英文版的,就马上抢了过来读。这是除了大学教材之外,我第一次完整地读完一本英文技术实体书。读完之后我才发现,网上有个 在线版,内容基本与实体书一致。
全书可以划分为三大部分:第一部分讲解了重构的基础,包括一个例子、一些原则、code smell讲解和如何构建测试;第二部分是重点,讲解了各种重构方法;第三部分是关于重构的其它一些话题,例如大型重构、重构工具等。
整本书读下来,我觉得收益最大的,就是知道了各种各样的 code smell 和相应的重构解决方法。以后在写新代码时,在一些细节设计上可以规避已知的这些 code smell 问题,提高代码质量。在维护旧代码时,也能记起,哦,这个问题可以用XX方法来重构解决~
要说缺点的话,我觉得作者对每个重构方法都详尽地列出了操作步骤,似乎有些冗长。我不知道是否有人真的完全按照作者的步骤去做重构,反正我一般都没有做得那么细,可能工具的支持比较好吧,Eclipse 的重构功能真的很好用。
本文就不列出那些 code smell 和重构方法了,只记一些重构相关的原则。
什么是重构
重构就是为了让软件更易于理解和维护,对软件的内部结构进行的、不影响外部行为的修改。
这个定义有两个重点:目标是“让软件更易于理解和维护”,所作的修改必须“不影响外部行为”。
为何做重构
- 重构能改进软件设计。随着代码被修改,软件的设计会慢慢退化,会过时。重构能让代码保持其原来的结构。
- 重构让软件更易于理解。我们写代码时总是不考虑代码的后续维护者,致使代码难于理解。
- 重构能帮你找bug。因为重构让代码变得更清晰,清晰的代码更便于发现问题。
- 重构能提高编程效率。重构可能会降低你目前的开发效率,但它能提高你以后的开发效率,物有所值。
- “三振出局”原则:第一次写一段代码,就直接写。第二次又写这段代码,你要皱一下眉头,但还是可以照常写。第三次还是写这段代码,那你就得重构了。
- 当增加功能时,重构。
- 当修 bug 时,重构。
- 做代码审查时,重构。
- 何时不应重构?问题太多的代码,最好直接重写。因为重构的代价很可能比重写还大。
- 重构的第一步永远都相同:为被重构代码编写一组可靠的自动化测试。人始终会犯错,而测试是避免错误的好方法。注意,必须是“自动化”的测试。
- 重构时应该小步前进,频繁地运行测试,这样当出现问题时就能快速定位。
- 进行重构时,不要增加新功能,反之亦然。
- 用“易于重构”的设计代替“十分灵活”的设计,能让设计简化,降低成本。
- 一般来说,重构都会让程序变慢(例如有更多的方法层级、更多的循环)。但经过重构,代码会更清晰,也就更易于优化性能。