《重构_改善既有代码设计》读书笔记 —— 颠覆你对重构的认知

书籍简介

《重构_改善既有代码设计》是软件工程领域的超级经典巨著，与另一巨著《设计模式》并称"软工双雄"
作者Martin Fowler是国际著名的面向对象分析设计、UML、模式等方面的专家，敏捷开发方法的创始人之一
本书生动阐述了重构的原理和具体做法

懒惰是程序员的美德之一，绝不要因为这本书让你变得勤快。

章节简介

• 第1章用一个实例展示出一些常见的设计缺陷并把它重构成为一个更合格的面向对象程序
• 第2章告诉我什么是重构、为什么要重构、什么时候重构
• 第3章告诉我如何找出代码的“坏味道”
• 第4章告诉我测试用例的重要性，测试驱动开发
• 第5-12章明确的重构手法
• 第13-15章是作者邀请其他大师分享重构的一些技术和应用经验

什么是重构

曾经我眼里的“重构”

转眼工作也有四年多了，曾经我对重构的认知是：组织一拨人，花费一两个月甚至更长的时间，将之前的设计不好的系统或是大量业务代码剥离，解耦合。重构是一群程序猿在特定情况下有组织的专职的行为。

现在我眼里的“重构”

首先推翻曾经的认知！曾经的重构那不叫重构，那叫重写。重构应该是在日常工作中的、频繁的、不需要专门安排时间周期的、不需要专职人员的一项工作。重构是每次看到不够优美、不够严谨、不够健壮的代码时将其修改的阅读性更高、扩展性更好、安全性更强、耦合度更低、重复数更少…的一项日常工作。

官方眼里的“重构”

• 重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
• 重构（动词）：使用一系列重构手法，是在不改变代码外在行为的前提下，对代码做出修改，以改进程序内部的结构。

为什么要重构

• 杂乱无章
• 消除重复
• 容易理解
• 找到BUG
• 提高速度

什么时候重构

第一次做某件事的时候你只管去做；第二次做类似的事会产生反感，但无论无何还是可以去做；第三次再做类似的事，你就应该考虑重构了；

• 添加功能时重构；
  当前代码的设计无法让我轻松的添加我所需要的特性
• 修补错误时重构；
  当代码没有清晰到能够让你轻松的定位到BUG的时候
• 复审代码时重构；
  当复审代码时发现有更好设计方案的时候

什么时候不该重构

• 当项目临近最后交付期限时
• 当项目生命周期即将完结时

什么地方重构

测试驱动开发

• 确保所有的测试都完全自动化，让它们检查自己的测试结果；
  写测试代码会花费时间，可是它能让你节约更多的时间，除非你的测试代码写的不够好
• 当收到bug报告时，应当补充一个测试用例来暴露这个bug；
  添加更多的测试：观察类该做的所有事情，然后针对任何一项功能的任何一项可能失败的情况进行测试
• 测试的目的是找出未来或者现在可能出现的BUG；
• 考虑可能出错的边界条件，把测试火力集中在那
• 不要因为测试无法捕捉所有的BUG就不写测试，因为测试的确可以可以捕捉到大多数bug
  花合理的时间抓大多数BUG，好过穷极一生抓所有的BUG

这里只是介绍了前4章至于后面的章节我认为不是简单的一篇博客就能描述的，希望埋下一个引子，如果有想法那么你值得拥有。

我认为这是一本值得像整个团队推广的书，好比敏捷不是一个人去执行就能成功的，而是整个团队乃至整个公司都认可的、去执行的敏捷才能展示出它真正的威力。

附上团队内部分享的PPT下载地址：
CSDN：https://download.csdn.net/download/zhibo_lv/10872055