我是靠谱客的博主 平淡宝马,最近开发中收集的这篇文章主要介绍《重构.改善既有代码的设计》读书笔记1、重构,第一个示例2、重构的原则,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

最近开始阅读技术书籍,不知道从什么书开始读,就从这本改善既有代码开始!

先记录,读完再整理一下。。。。

目录

1、重构,第一个示例

2、重构的原则

2.1、何为重构

2.2、两顶帽子

2.3、为何重构

2.4、何时重构

2.5、重构的挑战

2.5.1、延缓新功能开发

2.5.2、代码所有权

2.5.3、分支

2.5.4、测试

2.5.5、遗留代码

2.5.6、数据库


 

1、重构,第一个示例

无论改动多小都需要运行一遍测试集,测试成功后将零碎的修改进行一次提交commit

好的代码检验标准:其他人需要修改代码时可以轻而易举的找到修改点,快速做出更改

重构手法:提炼函数,内联变量,搬移函数,以多态取代条件表达式。。。等

1、好的命名可以使得代码简单易懂,可以根据函数名及参数就了解其实际用途(提炼函数)

2、返回值可以统一result(提炼函数,看个人习惯)

3、移除局部变量(内联变量)

4、如果重构引入了性能损耗,先完成重构,再做性能优化(比如:内联变量导致的重复的循环)

2、重构的原则

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

2.1、何为重构

不改变代码软件可观察行为的前提下,提高代码的可理解性,降低修改成本

2.2、两顶帽子

并不一定要将重构跟添加新功能在版本控制的提交中分开。只有当你觉得这样做有益时,才值得这样做。

原则上使用重构技术开发软件时,分为添加新功能和重构,添加新功能时不考虑重构,重构时不加新功能

2.3、为何重构

提高开发速度,开发时花一点时间,消除重复代码,改善结构设计,提高可读性,帮别人理解你的代码想干什么(万一那个人就是你自己,这个时候就有助于提高开发速度)

2.4、何时重构

每次要进行修改时,首先令修改很容易,然后再进行这次容易的修改。

不论开发或者修复BUG,我们都需要理解代码的用途,这时候如果遇到糟糕的命名、逻辑、结构。就可以进行简单重构,即使是修改一两个变量名,使它更接近它用途,或者记下来,有空的时花点时间一点点修改。将你的理解转移到代码中,因为你不能保证下次是不是还会修改它,是不是还记得它的意义。避免下次再花很长时间理解代码。

合并几段几乎重复的代码,抽象成一个参数方法,以后再开发类似的功能时就不必再复制一样的一段代码。

拆分不同逻辑不同功能的代码,避免逻辑纠缠。

不做无价值的重构,比如你发现糟糕的代码结构,但是与你当前的修改无关,那么可以容忍他继续存在,等需要理解它时再去进行重构。

2.5、重构的挑战

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

2.5.1、延缓新功能开发

做很必要的重构时,如果马上要添加新功能,而这个功能有非常小。可以考虑暂缓新功能开发,先进行重构,使新功能更容易添加;做这个决定需要权衡取舍

2.5.2、代码所有权

两个团队各自负责的项目,可以进行类似开源的模型;B团队成员在某个分支上修改A团队的代码,然后提交给A团队去审核;这样既可以避免混乱的修改,也可以避免完全依赖或被依赖于其他团队而导致不敢进行一些很小又很必要的修改。

2.5.3、分支

目前,大部分团队中,每个团队成员在各自的分支上进行修改,等到完全开发完成后才集成到主干上去,这个过程越长,合并到主干的困难越大;

为了减轻合并的痛苦,我们经常会频繁的从主干下拉合并代码,或者变基(重新拉分支,然后将本次开发的代码合并到新分支)。但这并不能真正解决问题,比如多人在多个分支上开发,这种操作仅仅是单向的,分支间的合并还是会有合并的困难问题;

实际上,我们应该使分支的存活时间尽量的短;

持续集成(CI):团队成员每天至少向主干合并一次代码,避免分支间的差异越来越大,从而降低了合并的难度;

但是持续集成也需要付出代价,就是你要保证主干一直处于健康状态,所以就需要学会将大功能拆分成小块,善用特性开关,将尚未完成的功能隐藏掉。

2.5.4、测试

绝大多数情况下,想要重构,我们得先有可以自测的代码;并且这个测试套件运行速度要快,否则都不会想去频繁的运行它。

有测试集的情况下,我们重构或者开发新功能都能很快的定位bug,因为每次进行改动之后都会运行测试集以保证本次修改不会引进新的问题,即使有问题,最坏也只需要回滚到上一次commit。

少数情况下,开发环境如果很好的支持自动化重构,那么我们可以信任这些重构,不必运行测试。

2.5.5、遗留代码

遗留代码大部分情况下命名很难理解,逻辑可能也很糟糕,多半还没测试集;这种情况下,很难安全的重构系统,这是一个无法避免的问题,那么对于这个问题,只能是‘没测试就加测试’;虽然这样工作量必然非常大。

可以每次进行一小部分,对于频繁使用的代码,这样改善其可理解性必然会得到很好的回报。

2.5.6、数据库

数据库重构的关键是每次进行小步修改,并保证每次修改的完整性。

比如要改一个字段名,那么第一次先新增新字段,但是不使用它;然后修改数据写入的逻辑,使其同时写入新旧字段;随后修改读取数据的地方,逐个改为新字段;最后保留旧字段一段时间,确保没问题了,再删除已经没人用的旧字段。

 

 

 

 

 

 

 

最后

以上就是平淡宝马为你收集整理的《重构.改善既有代码的设计》读书笔记1、重构,第一个示例2、重构的原则的全部内容,希望文章能够帮你解决《重构.改善既有代码的设计》读书笔记1、重构,第一个示例2、重构的原则所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(60)

评论列表共有 0 条评论

立即
投稿
返回
顶部