如何改善代码的设计---读《重构》读书笔记.docxVIP

一 提词器文档 如何改善代码的设计 - 读《重构》 这本书在五年前读了一次，当时读完觉得自己的水平上了一个台阶，然后开始在生产项目中实践。当时的项目是一堆没人维护的遗留代码，每当要做个新功能时，我都会重构（更准确的说法是重写）下与新功能相关的逻辑，因为没有测试用例的支撑，经常会因为改出问题导致自己加班。当时我从这种修改代码的过程中找到了编程的乐趣，那是一种畅快淋漓的感觉，重构后的代码似乎也成了体现我个人编程水平的象征。随着写的代码越来越多，维护项目中的这些代码耗费了我太多的时间，想写新的功能时发现自己无法抽身出来。我渐渐地感觉到代码成了一种负债，写的越多负债越多，我被自己的写的代码给困住了。近期重读 《重构》这本书，深感以前的我在重构方面至少犯了三个错误。1重构前没写单元测试。这样的重构很容易给自己挖坑，本想改个函数名，结果却捅了个蚂蜂窝。每次重构都觉得不踏实，生怕改错了什么地方2添加新特性和重构同时进行，最后一起测试。这样容易搞混原有功能与新特性。一起测试意味着没有单独对重构的代码进行小范围的测试，让代码集成测试起来复杂3为了重构而重构。很多时候重构成了一种强迫症，还美其名曰说自己有代码洁癖代码不仅仅是写完就好了，还需要维护。维护说白了就是让代容易理解，让代码易于扩展修改成本低。容易理解的代码可以很方便的交接出去给其它同事维护，难理解的代码就只能砸在自己手里。一旦有缺陷或者新功能，修改成本低易扩展的代码可以让你很快就完成需求，收获同事的佩服，早点下班。让代码易于维护就得借助重构来完成。近些年在项目中逐渐被“剥夺”了写代码的权利，看代码和定位问题的时间超过了写代码，从工作中得到的乐趣少了很多。希望重拾重构，从编程中找回那久违的畅快淋漓。摘录关于重构1什么是重构？○不改变软件可观察行为的前提下，提高可理解，降低软件维护成本2为什么重构？○可以改进软件设计。代码被阅读和被修改的次数远远多于它被编写的次数○可以使软件更容易理解。“擦掉窗户上的污垢，使你看得更远”○可以帮助找到 bug○可以提高编程速度3何时重构？○随时随地都可以重构，不要为重构而重构○三次法则○添加功能时先重构○修复缺陷时重构○审查代码时重构○代码中出现坏味道时，进行重构4何时不重构？○代码无法运行时不应重构5重构与其它○重构改变了预先进行代码设计的角色。通过重构你可以找出改变中的平衡点，你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来○短期看，重构可能使软件性能变慢，但它使优化阶段的软件性能调整变得更加容易重构要点1当你为程序添加功能不是很方便时，先重构使功能添加比较容易进行，然后再添加功能。重构与添加新功能不应该同时进行2重构前，先建立待修改代码的单元测试用例3重构就是以微小的步伐修改程序。如果过程中出错，会很容易发现4重构：使用一系列重构方法，对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高可理解性，降低其修改成本5任何一个人都可以写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员6事不过三，三则重构7当你感觉需要给代码写注释时，请先重构，试着让所有注释都变得多余8确保所有测试都自动化，让它们检查自己的测试结果。频繁运行测试9一套测试就是一个强大的 bug 探测器，能够大大缩减查找 bug 所需要的时间10每当你收到 bug 时，请先写一个单元测试来暴露这个 bug11考虑可能出错的边界条件，集中火力测试它们12不要因为测试无法捕捉所有 bug 就不写测试，因为测试确实可以捕捉大部分 bug13闻到代码的坏味道时进行重构14看一遍重构列表，需要时对照着做22 种常见的代码坏味道当代码中出现以下坏味道，你应该对代码进行重构。1重复代码。合并重复代码。2过长函数。程序越长越难理解，而且不好复用。这时要做的是分解函数，怎么分解？当你觉得要写点注释来说明时，可以把这部分代码放到独立函数里，并以它的用途（而非实现手法）命名。3过大的类。过大的类往往有太多的实例变量，容易导致很多重复代码，同时说明这个类责任太大了，需要拆解。4过长参数列。我们往往为了规避使用全局数据而添加了过多的参数，但这会让函数难以理解、不容易使用。可以考虑用对象来包裹参数。5发散式变化。如果某一外界的变化会导致某个类多处需要修改，那么应该考虑把这个类拆分成两个或更多，这样每个类就可以只因为一种变化而需要修改。6霰弹式修改。如果每遇到某种变化，你都必须在许多不同的类内做许多小修改，那么应该考虑把这一系列相关的修改点放进同一个类中。7依恋情结。函数对某个类的（通常是数据）兴趣高过对自己所处类。比如某函数为了