读《重构 - 改善既有代码的设计》总结笔记随便说说重构的定义正文节选总结补充一个常规的重构流程

193 阅读 0 评论 128 点赞

我是靠谱客的博主妩媚牛排，这篇文章主要介绍读《重构 - 改善既有代码的设计》总结笔记随便说说重构的定义正文节选总结补充一个常规的重构流程，现在分享给大家，希望可以做个参考。

[美] 马丁·福勒(Martin Fowler) 著

随便说说

图书馆看到这本书竟然有精包装版本，好奇心驱使闲人老师拿起了本书。看过之后发现干货满满，简直赚到了。
看过本书后，闲人老师准备去找作者推荐的《解析极限编程》和《修改代码的艺术》来看，同时还要找一点有关前端测试的书籍，提升自己写测试的能力。

重构的定义

用做名词：在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本的手法。
用做动词：使用一系列重构(名词)，在不改变软件可观察行为的前提下，调整软件结构。

正文节选总结

傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码的，才是优秀的程序员。
只有充分理解需求，才能够做好设计。但观察者效应的存在使它总是不能够达到。
好代码的检验标准：是否能轻而易举地修改它。
设计总是在时间流逝中逐渐腐坏，但重构可以改变这一观点。
设计耐久性假说：通过投入精力改善内部设计，我们增加了软件的耐久性，从而可以更长时间地保持开发速度。
持续集成（CI）需要拆分功能的能力，需要项目支持特性开关。
不要隔离团队内成员的代码，应该让成员可以监控到各自的代码责任区的变化。
不要过度设计，未来的变化可以交给重构，当下只需要写需求中的功能。
再次强调：代码的自测试很重要。
命名是编程中最难的两件事之一。另一件是缓存失效（一致性问题）。
想不出好名字，往往是设计还不够到位。
可以做点什么重构

做一些预备性重构使添加新功能更容易
在结构混乱时重构使功能更容易被理解
观察代码时发现某些功能可以更加简洁
有计划的重新审核代码发现可能重构点
在解决旧的设计问题时进行长期的重构
如果你要给程序添加一个特性，但发现代码因缺乏良好的结构而不易于进行更改，那就先重构那个程序。
勇敢地把做了过多事情的循环拆分成多个循环函数。
将总是一起变化的东西放在一块儿。
每当你感觉需要注释来说明的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途命名。
应该重构的内容：原文有24种，此处提炼成8种

隐藏：信息过多或过少都会无法控制。原文：神秘命名、过长的消息链和内部交易
重复：重复的信息浪费脑细胞。原文：重复代码、重复switch和异曲同工的类
堆积：冗长的内容总是难以被理解。原文：过长函数、过长参数列表、数据泥团、临时变量和过大的类
共享：多个实体控制同一份数据。原文：全局数据、可变数据和纯数据类
关联：一个修改必须同时进行其他几个修改。原文：发散式变化、霰弹式修改和依恋情结
无效：没有调用，过度封装，历史代码注释。原文：冗赘的元素、夸夸其谈通用性、中间人和注释
偏执：常用的数据类型就直接定义出结构来，将循环做的事情进行拆分而更清晰。原文：基本类型偏执和循环
错误：子类只实现父类的部分功能等。原文：被拒绝的馈赠
应该重构的内容达到什么程度再进行重构？这需要经验。
每次进行一小步。每一步测试成功的修改，都做一次本地提交。
作者整理了一整套可能的重构手法，此处不做记录，就像需要的话，可以查看原书。注：我认为，每个人的编程习惯是不同的，这是作者的手法，可以看一下参考，但不会成为我的手法。
重构过程不需要特别在意性能，因为重构只为了代码可读性、可维护性。
需求的变化使重构变得必要。如果一段代码能正常运行，需求不再变化，那它不需要重构。
因为需要把控成本，所以无需一次做到极致，但应该遵循营地法则：保证你离开时的代码库一定比来时更健康。
不要告诉经理你正在进行重构，自行将其安排到你的每一项工作中去。
重构后运行过慢？先重构出容易调优的代码，再对它进行调优。
调优一般有：时间预算法（预先定义每个组件的时间占用和空间占用）、持续关注法（随时保持系统的高性能，通常效果不好）。
调优必须在数据的支持下，否则将“劳而无获“。
作者写道：测试的目标是希望找出现在或未来可能出现的bug，所以不会去测试只读取一个字段的函数。注：我不认同这个观点，往往这些函数会因为拼写错误而出错。测试就是应该根据需求的拆解，在需求中的必须测,不在需求中的也可以测。
不要在测试之间共享数据。
断言之前产生的测试错误，可以尝试在代码中引入预先的错误断言来阻断。
每当有一个BUG被发现，就应该先写一个测试来暴露这个BUG。