《重构——改善既有代码的设计 第二版》读书笔记2

重构 改善既有代码的设计

一、什么时候重构

引用书中一段话:

第一次做某件事时只管去做,第二次做类似的事会产生反感,但无论如何还是可以去做;第三次再做类似的事,你就应该重构。

也就是说当我们做相同的事情第三遍的时候,你就应该去重构了。

1. 预备性重构:让添加新功能更容易

如书中所说,在当我需要添加新功能时,我们应该先去看看现有的代码库,可能你现在添加的功能在现有的函数里已有实现了大部分,只需要改动很小的部分就可以,那么这个时候,你就可以先戴上重构的帽子,将代码进行重构,然后再当完成新的功能就变得很简单。

作者在书中用一个小故事来说明这个道理:
就好比你需要往东去100公里,我不会往东直接开,而是先往北开20公里上高速,在往东开100公里。

2.帮助理解的重构:使代码更易懂

当我们看代码时,脑海里会形成一些理解,我们把这些理解转移到代码本身,这会让这份知识或理解保存的更久远,例如看到一个糟糕的逻辑,一个糟糕的命名,当你理解这些代码时,快速的将其重构,这样后面当你或者其他同事再来看这段代码将变得简单。

3. 有计划的重构和见机行事的重构

“肮脏的代码需要重构,但漂亮的代码也需要很多重构”

重构的时候,并不一定需要专门安排一段时间来重构,而是在添加功能或者修复bug的同时顺便重构;有计划的重构应该很少,大部分重构应该是不起眼的、见机行事的。

4. 复审代码时重构

复审代码也就是我们常说的code review,这种活动可以改善开发状况,还有助于在开发团队中传播知识,也有助于把知识传递给经验欠缺的人员。在这个过程中我们还可以看到代码中的不足,进而通过重构的手段来快速的解决这个问题,并且重构能够帮助复审代码工作得到具体的结果,不仅能当场获得建议,而且许多建议能够立刻实现。

二、重构的挑战

1. 延缓新功能的开发

尽管重构的目的是为了加快开发速度,但是仍然有很多人认为,花在重构的时间是在拖慢新功能的开发进度;
重构的意义不在于把代码库打磨的闪闪发光,重构的意义纯粹是经济角度出发的考量,之所以重构,因为能让我们添加功能更快、修复bug更快。

2. 代码所有权

很多重构不但会影响模块内部,还会影响该模块与系统其他部分的关系,例如:在一些团队中,调用方代码可能是另一只团队拥有,而我们没有权利写入他们的代码库,这个时候可能即便是一个简单的修改函数声明和调用者,都变得困难。

3. 测试

在我们重构代码的时候,如何保证我们的代码没有对现有的功能造成破坏,那么这就需要一套完备的测试套件,并且运行速度要快,否则我不会愿意经常去运行它。所以大多数情况,你想要重构,就得现有自测试的代码。