qscqesze
Published on 2017-09-02 11:31 in 暂未分类 with qscqesze

《重构:改善既有代码的设计》 读书笔记 第二章

第二章 重构的原则

2.1 何谓重构

重构分为了动词和名词两种意义。

重构(名词):对软件内部结构的一种调整,目的是不改变软件可观察行为的前提下,提高其可理解性,降低修改成本。

(问题来了,重构真的降低了可理解性吗)

重构(动词):使用一系列重构首发,在不改变软件可观察行为的前提下,调整其结构。

重构和代码清理的区别是:重构的关键在于用大量且微小,保证软件行为的步骤,一步一步达到大规模的修改。每个单独的重构要么很小,要么由若干小步骤组合而成。

(问题来了,我换一个代码架构重写,这个过程算重构吗?从作者的定义来看,这并不算重构,叫做“结构调整”)

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

重构并不等同于性能优化,重构理论上不会带来任何的性能优化,可能会变快,也可能会变慢。性能优化的目标只是使得代码运行的更快,但可能会使得代码变得更难理解。

2.2 两顶帽子

这里作者指的两顶帽子,分别是重构,和添加新功能。

重构:不再添加新功能,且不加任何的测试。

添加功能:添加功能,添加测试。

在编写程序的过程中,你可能会随时的切换这两种状态,但是你要知道,你什么时候戴的是什么帽子。

2.3 为何重构

重构可以改变软件的设计

如果没有重构,程序的内部设计会逐渐腐败变质。因为当人们只为了短期目的而修改代码的时候,他们经常会没有完全理解架构的整体设计,于是代码就逐渐失去了自己的结构。设计就会腐败。

设计欠佳的程序修改起来,成本会很大。

(我个人觉得,目前国内的编码环境,很少有人能够愿意抽出时间来交给大家来进行重构,大家都只会提出一些短期目标,自然而然代码就越来越shi了。代码好不好看,只能取决于写代码的这个人的个人节操了。)

重构使软件更容易理解

计算机根本不在乎你代码的可读性,但是几个月后来维护这个代码的程序员在乎。

重构可以帮助找到bug

因为你重构,你就会去读代码,然后你就会发现bug。

(有时候重构也会引入bug,但我觉得bug这个东西应该由测试来保证,这个不算是重构的有点)

重构提高编程速度

内部质量良好的软件可以让我们很容易就知道怎么去修改,在哪儿修改。

2.4 何时重构

三次法则:第一次做这件事情,那就只管去做;第二次做类似的失去,你还是可以去做;第三次遇到这件事情,你就应该去重构它。

预备性重构

重构的最佳时机就是在添加新功能之前。

帮助理解的重构:使代码更易懂

如果你觉得这个代码看不懂,就应该重构它。

捡垃圾式重构

如果我发现了垃圾代码,我就应该重构它;但是重构的优先级并没有新增功能的优先级高。

有计划的重构和见机行事的重构

重构并不是一件与编程割裂的行为,你不需要专门安排时间来进行重构。重构是在做某些事情的过程中自然而然的发生的。

但是有计划的重构并不是没有意义的,但大部分重构应该是不起眼且见机行事的。

肮脏的代码必须重构,但漂亮的代码也需要重构。

(这个我不太苟同,我不知道漂亮的定义是什么,我觉得一个代码可读性好,且容易修改,那么他就是一个漂亮的代码)

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

长期重构

大部分的重构几分钟,几个小时就能搞定。但是部分重构需要几个星期,但是不推荐让一支团队专门负责做重构。建议让大家逐步的迁移过去,这样做的好处是重构不会破坏代码,每次进行小的改动后,整个系统仍然照常工作。例如,如果想替换掉一个正在使用的库,可以先引入一层新的抽象,使其兼容新旧两个库的接口。一旦调用方已经完全改为使用这层抽象,替换下面的库就会容易得多。

这个策略叫做 “Branch By Abstraction[mf-bba]”

(强烈赞同!!!!!重写整个架构,然后打算无损替换过去,这种行为是真的傻逼。先立个flag,我这辈子不会干第二次这种事情了。)

code review 的时候重构

如果说,在进行cr的时候,写代码的人能够和审核代码的人在一起,效果会非常好。

这个叫做结对编程。

怎么对经理说

如果经理不懂技术,你就别和经理说。

如果懂技术,直说就行。

(建议默认经理不懂技术比较好,反正经理不care你究竟是怎么写的代码,他们只在乎结果而已。)

何时不应该重构

只有在我需要理解其工作原理的时候,我才需要去重构它,否则对于我而言是没有价值的。

另外一种情况是,重写比重构更简单。

重构的挑战

重构是有挑战的。

延缓新功能的开发

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

重构需要花费时间,如果添加功能非常小,你可以先把功能加上,再进行重构,这个需要程序员的专业判断。

(你就是hxd?)

从较多的情况而言,重构不足的情况远大于重构过度的情况,所以绝大多数人应该尝试多做重构。代码库的健康与否,到底会对生产率造成多大的影响,很多人可能说不出来,因为他们没有太多在健康的代码库上工作的经历————轻松地把现有代码组合配置,快速构造出复杂的新功能,这种强大的开发方式他们没有体验过。

如果你是leader,你应该向团队表示,你是重视重构的,对于缺乏重构经验的年轻人要有意的知道,才能帮助他们加速经验的积累。

重构并不需要使得代码变得很好快,而是使得代码能够添加功能更快,修复bug更快。重构提高的是经济利益。

代码的所有权

推荐团队所有制,让大家拥有更多的权限。

分支

特性分支存在的时间越短越好,应该频繁的从master同步代码。

测试

你应该使得你的代码是自测试的,这样就会使得能够快速发现错误。

有人会觉得满足自测试的代码,这个对团队的要求会很高。但是从作者的角度而言,团队投入时间和精力在测试上的收益绝对是划算的。

(国内就别想了,上线前能肉眼看一下log是否符合预期就算不错了。。。更别说自测试了)

遗留代码

遗留代码的特征是,无测试,复杂,且代码是别人的。

建议再买一本《修改代码的艺术》书来读。

数据库的修改

假设你要改一个字段的名,正确的做法是新建一列,然后双写,直到测试完成后,再删掉之前的那列。

2.6 重构、架构和YAGNI

在很久之前,有人会说,在开始写代码的时候,你就应该设计好。

但实际上,做好这个的前提是,你在写软件前就已经充分理解了未来可能的需求,但实际上这个假设是不切实际的。

以前的做法是应该增加灵活性机制,给这个函数增加很多个参数,使得函数更加通用。

但有了重构技术,与其猜测未来需要什么技术,更应该只在乎当前的需求构造软件。随着用户需求的增加,我再进行重构。

这种东西叫做YAGNI,you aren't going to need it. 你不会需要他的~

2.7 重构与软件开发过程

极限编程的三个要点:自测试代码,持续继承,重构。

在这三大核心实践的基础上,才谈得上敏捷开发。这样才可以做到一天多次的发布,且每次发布都是高质量可用的。

2.8 重构与性能

重构并不会优化时间,但是会使得代码可以调优。你的做法是先写出调优的软件,然后再调优它以求获取更加足够的速度。

性能的优化请不要靠想像,应该由数据,图表来证明。

作者的做法是,做好监控,在实现功能期间并不在乎性能,在真正在乎性能的时候,再专门的去优化性能。

2.9 重构的起源

这句话全是废话

2.10 自动化重构

JB系列套件很牛逼。

posted @ 2020-01-14 18:19  qscqesze  阅读(142)  评论(0编辑  收藏