重构原则

2.1 何谓重构

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

区别:性能优化。性能优化往往使代码较难理解,但是为了达成所需的性能需求而不得不这么做。

2.2 为何重构

2.2.1 重构改进软件设计

重构本质是整理代码,一个重要的作用就是可以消除重复代码,从而确保所有事物和行为在代码中只表述一次(优秀设计的根本)。

2.2.2 重构使软件更容易理解

当你只是想让程序尽快运行交付的时候,并不会想到将来的维护者所面临的工作。而重构则可以让我们更容易读懂代码,让代码更好的表达自己。这种编程模式的核心就是准确说出我要的

随着代码的日趋整洁,你会发现自己以前看不到的设计层面的东西,重构把我带到了更高的理解层次上。

2.2.3 重构帮助找到bug

如果对代码进行重构,可以深入理解代码的行为,从而获得新的理解,更好的弄懂程序结构,也更清楚了自己所做的一些假设,这个时候就更容易揪出bug了。

2.2.4 重构提高编程速度

良好的设计是快速开发的根本,它能组织系统腐败变质。如果没有良好的设计,某段时间内你的进展可能会迅速,但恶劣的设计很快就会让你速度慢下来。

2.3 何时重构

2.3.1 三次法则

事不过三,三则重构。

2.3.2 添加功能更时重构

在给软件添加新特性时进行重构,把代码结构理清,可以从中理解更多,从而可以更轻松的帮助我添加我所需要的特性。在特定的场景中,引入某种模式重构后,添加特性会变得更加简单。

一旦完成重构,新特性的添加就会更快速、更流畅。

2.3.3 修补错误时重构

如果收到一个错误报告,这就是需要重构的信号,因为显然代码不够清晰–没有清晰到让你能一眼看出bug。

2.3.4 复审代码时重构

针对比较大的设计复审工作,复审代码时,可以通过UML示意图展现设计,并以CRC卡展示软件情节。而和单个复审者进行代码复审。

重构达成的目标:① 容易理解;② 所有逻辑都只在唯一地点指定;③ 新的改动不会危及现有行为;④ 尽可能简单表达条件逻辑。

2.4 怎么对经理说

面对进度驱动的经理,建议重构这个事儿不要跟经理说,依据自己的判断来决定是否需要重构。假设你认为重构是理解软件的最快方式,然后才可以进行错误修复或者新功能开发,那么就进行重构工作。

间接层和重构

– Kent Beck

计算机科学是这样一门科学:它相信所有问题都可以通过增加一个间接层来解决。 – Dennis DeBruler

重构往往把大型对象拆分成多个小型对象,把大型函数拆分成多个小型函数。

而间接层是一把双刃剑。每次把一个东西分成两份,需要多维护一个东西。以下是间接层的价值:

  • 允许逻辑共享:子函数通过模板调用,或者超类函数被所有子类共享。
  • 分开解释意图和实现
  • 隔离变化:通过子类来实现
  • 封装条件逻辑:通过多态消息表达条件逻辑。

在保持系统现有行为的前提下,如何才能提高系统的质量或降低其成本,从而使它更有价值?

可以找出一个缺乏间接层利益之处,在不修改现有行为的前提下,为它加入一个间接层。相反的,也可以找出不值得的间接层,将它拿掉。

通过重构,程序自始至终都能保持一致的行为,而你又有计划为程序添加更多价值不菲的质量。而“小心翼翼地事前设计”试图在代码诞生之前就让系统拥有所有优秀质量,然后架构骨架上门添加代码,但这样太容易猜错。

2.5 重构的难题

2.5.1 数据库

数据库结构的改变导致的数据迁移,是一件漫长而繁琐的过程,特别是业务比较复杂的时候。

通过持久层走位数据库分隔层,隔离对象模型和数据模型之间各自的变化。

相关内容:《数据库重构》

2.5.2 修改接口

如果重构手法改变了已发布接口,请让旧接口调用新接口

不要过早发布接口。请修改你的代码所有权政策,使重构更顺畅。

针对异常,可以为整个包定义一个异常基类,所有接口都抛出该异常,避免抛出各种异常污染了接口。

2.5.3 难以通过重构手法完成的设计改动

我们很难讲不考虑安全性需求时构造起来的系统重构为具备良好安全性系统。

如果预先看不到简单的重构办法,就在设计上投入更多的利器。但是后者很难预料到后续真正需要的设计目标。

相关案例:
给不支持多卡支付的系统添加多卡支付的功能更,整个数据库相关表都需要修改
原本只是给一个业务线使用的系统,需要介入其他业务线的需求,需要支持appid分发,这种重构也是非常大的工作。

2.5.4 何时不该重构

重构之前代码必须起码能够在大部分情况下正常工作。如果不能,请考虑重写。一个折中办法是对”大块头软件“重构为封装良好的小型组件。

如果项目已接近最后期限,应该避免重构。如果没有足够的时间重构,通常表示你早该进行重构。

2.6 重构与设计

重构与设计是互补的。设计就像画工程图,而编码就像施工。

尽管有了重构,你还是需要做预先设计,找到一个可悲接收的解决方案,然后才开始编码,然后才能重构。有了重构,即使预先设计不能找出正确的解决方案也不成问题,重构让日后的修改成本不再高昂。

2.7 重构与性能

虽然重构可能使软件运行更慢,但是它也是软件的性能优化更容易。

除了对性能有严格要求的试试系统个,编写高性能软件的秘密就是:首先写出方便维护的软件,然后调整它以求获得足够速度。

短期看来,重构的确可能使软件变慢,但它使优化阶段的软件性能调整更容易,最终还是会的得到好的结果。

2.8 重构起源何处

arthinking wechat
欢迎关注itzhai公众号
  • 本文作者: arthinking
  • 本文链接: refactoring-principle.html
  • 版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!