《重构（第二版）》阅读笔记（二）

重构原则

何谓重构

好代码的检验标准就是人们是否能轻而易举地修改它。

重构、性能优化、添加新功能三者是不同的存在

重构不会改变原代码的执行逻辑，主要目的是为了让代码看上去更美观，且易于修改，它对于性能的影响是未知的，没有绝对。对于代码量来说，还可能产生更多

并不能通过代码行数的多少来表示执行的效率，当然最佳追求必然是既少又快，还能看

性能优化则只有一个目的，为了让整体的运行质量提高，并不关注其他，也就是高性能表示低阅读

这需要在两者当中寻找一个平衡点，而且两者并非是相互排斥的存在

而添加新功能也得遵循开闭原则，很单纯的新增，而不去改动老代码，如果真的是需要修改才那做到新增，则出现了需要重构的信号

如果有人说他们的代码在重构过程中有一两天时间不可用，基本上可以确定，他们在做的事不是重构。

重构是不会导致程序无法运行的，遵循信条，小步前进，可暂停

两顶帽子🧢

哪两顶，开发新功能与重构
开发时，千万不能两者反复交替穿戴，这样玩的就是心跳。非常忌讳，在新增时修改原代码，在重构时去添加了原先不存在的新代码

为何重构

使代码更好理解

想想吧，某天有人要理解你的代码，然后进行修改操作，然而在研读了一周之后，才达成了这个目的，更可怕的是，那个人可能就是你自己👀

帮助找到 Bug🐛

在重构完成之后，层级分明的情况下，想找不到都难，哦耶

提高编程速度

哼哼哼，有很多的场景，面对一些老掉牙的代码，在此基础之上进行新增，其实都很难接受，更多时候或许更愿意推推倒重来，那也比在这个现成的上面苟延残喘强

当然，这里的速度也不是说，让代码到达一种让人可以接受的情况，而是做好地基工作，不要出现两顶帽子反复横跳，如前所言，刚开始你可能速度会很快，慢慢的，地基的不稳当出现问题，最终会导致豆腐渣工程，急速走向灭亡

这条并不是绝对的存在

为何会导致这种情况的发生，因为前期的放纵，未对总体做好调整，后期想要添加新功能越来越难，一种糟糕的粘合性在其中而无法改动

通过投入精力改善内部设计，我们增加了软件的耐久性，从而可以更长时间地保持开发的快速 – “设计耐久性假说”

何时重构

一条准则：

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

正如老话说的：事不过三，三则重构。

重构的最佳时机则是在添加新功能前，保证当前的代码足够健康，可以接受新来的家伙，可别让新来的小伙子把老朋友们打的七上八下

在外行的眼中，重构在做的事情就是弥补过去犯下的错误，程序能跑就是最大的道理，对此，千万不要去和他们理论什么，很可能挨打

何时不该重构

对于不会再进行修改的代码，整理的价值并非那么大，只有想理解它的原理时，这次重构才有价值

若是重写比重构要简单，那为何不重写呢

重构的挑战

延缓新功能开发

重构的唯一目的就是让我们开发更快，用更少的工作量创造更大的价值。

如前所说，对于新功能的开发就在眼前，或许不会特批时间让其去重构，甚至没有道理可讲

之所以重构，因为它能让我们更快——添加功能更快，修复 bug 更快

需要取舍，若是可以接受添加完新功能之后，再执行重构，这也未尝不可，当然，对于那种已经烂到家的，那对不起，我可能要动手来争夺这次重构的机会😎

代码所有权

若是每个人只负责一片代码，那自然，每个人管好自己那份就成

若是存在互相调用 API，或许需要开放修改权限，让其他人可以进行主动的干涉，这并非说是一种不负责任的做法，出问题算谁的，那无非是想强调，谁来背锅

太绝对了，让别人瞎动自己的这一片的逻辑也并非是一件好事，也不看看谁是管这片的老大

对于涉及多个团队的大系统开发，在“强代码所有制”和“混乱修改”两个极端之间，这种类似开源的模式常常是一个合适的折中

分支

这事实上涉及的是 Git 分散式开发，当一条分支离开主支太久，回来的成本会越来越大

当然，重点不在于 Git，而是面对重构时的操作，将一个函数改名、分成多个函数是常有的事，若是处于分支当中的人浑然不知，后续还需要做出对应的调整

😜我去，居然瞎扯成功了，这不就是说，重构与开发不要同时进行，会出大事的

测试

重构若是导致程序运行与原先的效果不一致，这便是失败的

对此我们每次做出修改之后，需要得到测试的反馈，是非对错到底如何。当然，很多情况下不需要测试也能预料到结果如何，为了洛克萨斯，请你保证🙏

对于一些可以快速拿到结果的测试，那自然没有问题，有一个良好的测试环境可以显著降低了重构的成本，这可不是可有可无的存在

遗留代码

对于遗产，那当然越多越好，对于代码，我们通常是相反的

最头疼的事情莫过于观看别人的代码，水平低的，一片坑坑洼洼，水平高的，看不懂写的是什么，自己的代码，这是自己写的吗？更多的反应还得是，我宁可推倒重来，也不愿意再看它们一眼

更多时候，时间是不允许，这只能想办法，将自己代入开发者模式，插入至其中，这是最快的方式，毕竟谁也逃不过这一套法则，让自己慢慢来

有一条修改的法则，若是需要进行替换的时候，可以先插入一条新的字段，找到老字段将其切换至新的字段，一条条进行修改，然后进行拔牙，当问题没有出现，则可以将老字段进行移除

重构与性能

在此之前的言论好像都很悲观，那就是重构与性能是有冲突的，这实则不然，好比空间与时间复杂度一般，总需要找到一个平衡点，甚至说双优化

这里其实对性能优化提出了几道建议，若是有一个良好的测试工具，根据测试结果，定点打击，然后再次测试，查看优化是否出现了一个良好的反馈