修改代码的艺术读后感

这本书提到了一个我曾近不知道的概念:遗留代码。所谓遗留代码,指的是随着时间流逝,之前的代码纵使再完美无缺,也不可避免的产生腐化,失去原有的便利而显得腐朽发臭或者说没有编写测试的代码,或者说是遗留代码有许多预防措施,但是它的产生不可避免。如何解决它是整本书的核心。

书的第一部分,介绍了代码的修改机理,包括感知、分离和接缝和工具的使用,同时简要介绍了遗留代码以及测试的重要性。可以说,扭转遗留代码离不开测试。

遗留代码修改算法包括以下几步:

(1) 确定改动点;(前提:理解代码)

(2) 找出测试点;(前提:理清代码间的联系)

(3) 解依赖;(解依赖是为类编写单元测试的前提 )

(4) 编写测试; (编写符合代码当前行为的特征测试 )

(5) 修改、重构。 (在存在测试覆盖的前提下,修正bug 、改善设计等 )

合理的测试是必要的,所以解依赖技术是这本书的重中之重。这就是为什么本书用后面的大量章节描述解依赖的原因吧。

之后讲的伪类也可以说是测试的一个环节,为了测试的方便所设计的一部分。

中间的部分讲的并非难以理解,并不会有什么许多复杂的概念。他提出了许多在修改代码时遇到的实际而简单的问题,比如时间不够,修改过程漫长而遥遥无期等。可以作者说在理论的分析之后,开始考虑实际情况可能遇到的问题,并非来自代码处理上的问题。这里提供的更多的是技巧上的帮助,并非理论的帮助。

文章的最后一部分,则是关于解依赖技术的具体化实现问题。比如,接触类内部依赖的解依赖技术:

子类化并重写方法 :将少数无须测试的内部接口重写,通过实例化重写的派生类来测试原有类的接口。这里的重写是指虚函数的重实现,而非覆盖。

提取并重写调用:封装API ,并重写该接口

提取并重写工厂方法:用于实例化伪对象,避免更改接口,本质就是替换实例变量。

提取并重写获取方法:延迟获取实例变量,用于C++ 。因为C++ 在构造函数中虚函数机制被禁止,故无法再构造函数中调用子类重写的工厂方法。

特定情况下的解依赖技术:

分解出方法对象:重构巨型方法

朴素化参数:避免参数依赖

封装全局引用:

以获取方法替换全局引用:利于重写获取方法。

定义补全:C/C++ 的定义和实现是分开的,通过重写实现替换原有行为。

连接替换:利用链接期接缝,替换库,DLL 等,实现行为替换。

暴露静态方法:避免对象的实例化,用于难实例化的对象。

换函数为函数指针:用于C 的行为替换,不推荐。

整体而言,整本书开头着重于理论的建立与解析,之后两章则是进行具体的探讨与理论的运用,向我们解释了遗留代码以及处理方式。

时间: 2025-01-31 08:46:35

修改代码的艺术读后感的相关文章

读书报告之《修改代码的艺术》 (I)

<修改代码的艺术>,英文名<Working Effectively with Legacy Code>,中文翻译的文笔上绝对谈不上"艺术"二字,愧对艺术二字(当然译者不是这个意思).书中第三部分不论是例子还是解说都有点混乱,远不如<重构--改善既有代码设计>一书.此书精华在于第一.二部分. 如何学习这本书,作为一个最底层的码农,作为长期在别人代码上修修补补的苦逼二手货开发人员,我只能给的建议就是:你可以将它看做是如何做定制功能的指导书--从某种意义上

读书报告之《修改代码的艺术》 (II)续2

这里作为(II)的第二个续篇,继续复杂的嵌套if else 的处理. 为了保持篇幅不会太长,以一篇新的文章形式给出. 化简复杂的if else语句,基本的手段 针对头重脚轻的if else,使用return快速返回,从而减少嵌套层数. 合并分支.有些分支的执行内容相同,往往意味着可以合并为一个分支 扁平化. 这里给出最后一个举例,也是从网上随便搜索摘录的 原始代码 List<TWorkFlowwork> wfwList=errorProcessingService.findWorkFlowwo

修改代码的艺术笔记

使用单元测试使修改代码变得简单. 在编程的时候考虑测试:使用类的方法来代替方法,这样可以通过在测试中编写继承类,改变相应方法的行为,达到避免执行某些函数的目的,更好的解依赖. 使用包含预处理的头文件来制造接缝.#ifdef TESTING...  endif 通过修改链接时的包含路径,另外的写专门用于测试的类.(最佳,清晰而且便于维护测试代码) 如果是函数调用的内部函数是多态的,通过基类的对象传参,通过测试对象控制内部函数的行为,而不要封装new来的对象在函数内部. 不用static和私有函数,

读书报告之《修改代码的艺术》 (II)

今天继续从本书的第二章学习, 昨天我们已经总结了下面三个内容 1. 降低修改的风险 2. 需要修改大量相同的代码 3. 时间紧迫,必须修改 今天继续第四点 4. 修改时应当测试哪些方法 作者提出了影响结构图的概念.说穿了,就是CallRelation和ReferenceRelation,就是查看某个方法(变量)被哪些方法引用,以及自身又引用了哪些方法,依次类推.这个复杂的关系网实际就是一颗风险评估树(图).通过这棵树,我们可以知道某个修改会影响到哪些节点.这项参数,既是风险的直接量化指标,同时又

《编写可读代码的艺术》读书笔记

表面内容 1.代码的写法应当是别人理解他所需的时间最小化.一条注释可以让你更快理解代码.尽管减少代码行数是一个好目标,但是八里街代码所需的时间最小化是一个更好的目标. 2.选择专业的词,比如函数名使用getxxx(),这个get没有表达出很多信息,是从缓存中得到?从数据库中得到?或者从网络得到?如果是网络,可以用更专业的fetchxxx()或者downloadxxx() 3.tmp,retval这样泛泛的名字,可以根据情况命名,比如tmpFile,让人知道变量是一个临时的文件.(tmp这个名字只

《编写可读代码的艺术》——简单总结

上个月好像冥冥中自有安排一样,我在图书馆看到这本 <编写可读代码的艺术> ( The Art of Readable Code) 期间因为工作的原因,停停看看,这几天终于看完了,可以大概总结如下: 1. 把信息装进名字里,给变量起个好名字 2. 审美,把代码分成段落,对齐 3. 应当取个好名字,而不是用注释去粉饰它 4. 用注释记录你的思想,比如当时为什么要这样写,记录开发过程中有哪些思考 5. 将自己代码中的不足和瑕疵记录下来,方便今后别人的维护,不要顾忌别人的看法! 6. 注释应该言简意赅

读书报告之《改动代码的艺术》 (I)

<改动代码的艺术>,英文名<Working Effectively with Legacy Code>,中文翻译的文笔上绝对谈不上"艺术"二字.愧对艺术二字(当然译者不是这个意思).书中第三部分不论是样例还是讲解都有点混乱,远不如<重构--改善既有代码设计>一书. 此书精华在于第一.二部分. 怎样学习这本书,作为一个最底层的码农,作为长期在别人代码上修修补补的苦逼二手货开发者,我仅仅能给的建议就是:你能够将它看做是怎样做定制功能的指导书--从某种意义

编写可读代码的艺术笔记

编写可读代码的艺术 表面层次上的改进 命名.注释以及审美--可以用于代码库每一行的小提示. 简化循环和逻辑 在程序中定义循环.逻辑和变量,从而使得代码更容易理解. 重新组织你的代码 在更高层次上组织大的代码块以及在功能层次上解决问题的方法. 精选话题 把"易于理解"的思想应用于测试以及大数据结构代码的例子. 第1章:代码应当易于理解 1.代码应当易于理解. 2.代码的写法应当使别人理解它所需的时间最小化. 第一部分:表面层次的改进 第2章:把信息装到名字里 1.使用专业的单词. 2.避

编写可读性代码的艺术

在做IT的公司里,尤其是软件开发部门,一般不会要求工程师衣着正式.在我工作过的一些环境相对宽松的公司里,很多程序员的衣着连得体都算不上(搞笑的T恤.短裤.拖鞋或者干脆不穿鞋).我想,我本人也在这个行列里面.虽然我现在改行做软件开发方面的咨询工作,但还是改不了这副德性.衣着体面的其中一个积极方面是它体现了对周围人的尊重,以及对所从事工作的尊重.比如,那些研究市场的人要表现出对客户的尊重.而大多数程序员基本上每天主要的工作就是和其他程序员打交道.那么这说明程序员之间就不用互相尊重吗?而且也不用尊重自