重构.改善既有代码的设计14总结&读后感

Posted aoyihuashao

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了重构.改善既有代码的设计14总结&读后感相关的知识,希望对你有一定的参考价值。

14、总结

首先,这是一本太老的书,很多观点已经被固化或者过时了。但核心观点没有问题,虽然大多数观点已经被认为是理所当然的事情了。

 

重构的定义

重构分几种: 
1、狭义的代码重构 
  就是本书讲的,在不改变软件可观察行为的前提下,改变其内部结构。这就是完全不改变程序的功能,只是改变代码的组织方式,也就是只是整理代码而已,目的是优化代码架构,而不是优化行为、算法、逻辑或流程。

2、普通意义的重构 
事实上,我们一般很少会去做纯粹的重构,所以,了解了软件行为,从行为、算法、逻辑或流程上进行优化,,往往会更加能够选择更好的方法重构了,而且更加奏效。

3、重写 
有些时候,当代码已经比较腐烂时,重写是更好的重构方法,特别是功能单一的模块。 
比如我们18年刚刚借着优化的名字,把一个6万行代码的模块给重写了,效果杠杠的。

重构与设计的关系

简单设计与预先设计的关系:尽可能简单的预先设计。 
如果已经预测到软件会遇到某方面的变化,就必须在开始设计的时候考虑到这个变化会对代码造成的风险,使在变化发生的时候,能够方便的改动。 
也就是说,你可以不去实现那些变化,但是要保证以后可以方便的实现那些变化。

 

重构的目的

重构就想锻炼身体,让代码保持健康。

重构的目的是优化设计,设计优化后带来的好处: 
1、提高理解性 
程序主要是给人看的,而不是给机器看的。 
2、降低修改成本 
程序的维护时间比开发时间要长的多。 
所有逻辑都只在唯一的地点出现。 
3、提高编程速度 
--良好的设计是快速开发的基础。

 

重构的时机

1、小的重构 
随时可以开始,当现有代码让你难受时,就重构它。除非已经到了交付的末期。

2、大规模重构 
要项目统筹安排。

 

如何说服经理做重构工作

1、如果经理懂技术。那么说服他应该不难。 
2、如果经理不懂技术,但对质量感兴趣。先让他接受review的价值,然后把重构的意见放入review中。 
3、如果经理只关注进度(假装也关注质量,其实已经向进度妥协)。不告诉他,自己重构。

 

重构前的准备工作

小型重构 
1、构建自动测试系统,保证重构安全

大型重构 
1、把它分成多个模块,分块重构。 
2、整个团队都必须意识到:有一个大型重构正在进行,不能让其他人把你的重构成果破坏了。

 

重构开始前需要明确的原则

1、重构不能损失功能,要有测试用例保证。 
2、重构要与增量开发隔离,以保证随时可以回退。 
3、要小步快跑,完成一块重构,就立刻跑过测试用例,然后闭环此部分重构。 
4、如果某次重构后,用例不通过了,只花一小点时间定位,解决不了,立刻回退。

 

重构的安全保障

安全应该有两层含义:1、代码安全;2、你自己的安全。

所谓「安全重构」(safe refactoring)就是不会对程序造成破坏的重构。由于重构的意图就是在不改变程序行为的前提下修改程序结构,所以重构后的程序行为应该与重构前完全相同。

如何进行安全重构呢?你有以下数种选择: 
· 相信你自己的编码功力。 
· 相信你的编译器能捕捉你遗漏的错误。 
· 相信你的测试套件(test suite )能捕捉你和编译器都遗漏的错误。 
· 相信代码复审(code review)能捕捉你、编译器和测试套件(test suite )都遗漏的错误。

Martin 在他的重构原则中比较关注前三个选项。大中型公司则常常以代码复审作为前三个步骤的补充。

但,百密一疏,重构是人为的动作,人不可能万无一失。所以,如果你无法承担错误的后果,就不要重构了。

 

重构的方法

现在已经经过层层思考,决定要重构了。

1、发现代码的坏味道 
  简单的,可以通过工具发现 
  复杂的,则要靠自己发现了

2、不停地重构一块块坏的代码 
重构的各种方法,文中已经列出了,但看过不等于会用,只有日积月累的勤学苦练,才能有信心面对各种复杂的情况————学会所有的招式,才能无招胜有招。 
张三丰较张无忌学太极拳,也是先学会所有的招式,然后忘掉,做到的无招胜有招。 
有些人那些学了思想,就声称掌握了这门技术,往往是眼高手低罢了。

设计模式为重构提供了目标。

文中方法的缺点:不适用于并发式、分布式环境。

 

重构,复用与现实

为什么开发者不愿意重构他们的程序? 
重构的好处是显而易见的,但这只是开发者的梦想,那么让梦想进入现实: 
为什么还不肯重构你的程序呢?有几个可能的原因: 
1. 你不知道如何重构。 
2. 如果这些利益是长远(才展现)的,何必现在付出这些努力呢?长远看来,说不定当项目收获这些利益时,你已经不在职位上了。 
3. 代码重构是一项额外工作,老板付钱给你,主要是让你编写新功能。 
4. 重构可能破坏现有程序。 
5. 如果你不是代码的唯一owner,怎么办? 
6. 如果代码有多个分支,怎么办?

1、4可以技术解决,但2、3就到了人性层面了,尤其是当领导不支持的时候,坚持重构可能会让自己伤痕累累。

 

重构的难题

1、数据库 
难点在于数据层与业务层耦合、数据迁移。 
解决办法:加分隔层、

2、修改对外接口 
这不是狭义重构允许做的,但有时你会修改接口。 
解决办法: 
接口共存,旧接口调新接口,直到确认旧接口没有再被调用了。 
不要过早的发布接口。

 

重构与性能

保证软件性能的方法: 
1、时间预算法。从开始就监控时间,分解每个组件允许耗费的时间,永远不允许其超过这个时间限制。这个是在对系统实时性要求非常高的软件中使用。 
2、持续关切法。要求程序员任何时刻持续不断的关切新开发的代码,已保证性能。这个很难做到全面。 
3、重点关切法。一般用的就是这个。类似二八原则,但这个更甚,估计要超过一九原则。90%的优化工作都是徒劳的,只有10%的优化工作是真正解决90%以上问题的。所以,把优化的重点放在这10%工作上。首要的问题,就是如何发现性能拼接在哪里?必须使用检测工具,而不是臆测,臆测的一般是错误的,会让你投入大量的时间到徒劳的工作部分。

 

 

以上是关于重构.改善既有代码的设计14总结&读后感的主要内容,如果未能解决你的问题,请参考以下文章

读《重构 改善既有代码的设计》背景

重构·改善既有代码的设计.04之重构手法(下)完结

重构改善既有代码设计--重构手法14:Hide Delegate (隐藏委托关系)

重构·改善既有代码的设计.01

重构改善既有代码设计--重构手法 之重新组织你的函数总结

重构改善既有代码设计--重构手法05:Introduce Explaining Variable (引入解释性变量)