《重构》

背景

近期收到了被大佬们推荐的《重构》一书内心十分雀跃，打算仔细品品，学习如何去除代码中的坏味道。

示例中提到了许多优化代码的方式，如：提炼函数 => 修改变量名 => 内联变量 => 改变函数声明等等，更让我有所感悟的是这些💡：

保证离开时的代码库一定比来时更健康。

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

小的步子可以更快的前进，保持代码永远处于可工作状态，小步修改积累起来也能大大改善系统的设计

后续章节介绍了重构的原则、代码的坏味道、构建测试体系及如何实现重构，以下内容从what why how三个方面聊聊重构。

重构是一种改善软件设计的手段，通过对软件内部结构的调整，使其更加易于理解和修改，同时不改变软件的可观察行为。感觉重构的定义就不需要多说些什么了。即对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

重构的目的是让代码更加易于理解和修改，而不只是为了让代码更加简洁，因为简洁的代码不一定具备良好的可维护性。众所周知代码是程序员之间交流的语言，如果写的代码复杂且冗余，阅读起来令人费解，维护性低则会影响团队的协作效率，维护时自然是少不了各种情绪。所以避免代码的坏味道，重构还是很有必要的。

近期阅读完本书后，想写个总结说说如何去重构，但发现貌似没有什么可以拿出来说的，毕竟很多内容都需要在实战中一一体会，所以后续可以把本书当成字典，想要重构代码时，再去查查有没有什么最佳实践方案即可。

近期的一些实践：

重构代码时，先写测试用例，保证重构后的代码不会出现问题。
重构变量名，尽量做到见名知意个人觉得起名真的是个很费劲的活，简单一点还好，但想要表述的准确不太容易，并且还容易出现重名的情况。所以可以理解在一开始没有想到好的名字时，先起个临时名称，等到后续理顺逻辑后再去用更好的变量名替代。
抽离函数，函数的单一职责原则一个函数只做一件事，这样的函数更容易理解，也更容易维护。如果写下一个函数，还需要写一大段注释去描述该函数所做的事情，那么建议再抽离一下该函数。
简化条件逻辑 if else的判断条件是必不可少的，但是过多的嵌套会让代码变得难以理解，所以可以尝试把条件逻辑简化。

写在最后，光看看书📚是没啥用的，理论总得是需要配合实践的。毕竟实践是检验真理的唯一标准。hhh