01. 重构原则

 

目录

一 重构定义

    1.1 重构当做名词

    1.2 重构当做动词

二 为何重构

    2.1 重构能改进软件设计

    2.2 重构使软件更容易理解

    2.3 重构帮助找到 bug

    2.4 重构提高编程速度

三 何时重构

    3.1 三次法则

    3.2 添加功能时重构

    3.3 修补错误时重构

    3.4 复审代码时重构

四 重构难题

    4.1 数据库

    4.2 修改接口

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

五 何时不该重构

六 设计与重构

     6.1 只有设计

     6.2 只有重构   

     6.3 设计+重构

七 重构与性能


一 重构定义

    视上下文的不同,“重构”这个词有两种不同的定义:

    1.1 重构当做名词

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

    1.2 重构当做动词

        使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构。

二 为何重构

    重构是一个工具,它可以用于以下几个目的:

    2.1 重构能改进软件设计

        重构就像是整理代码,所做的就是让所有东西回到应处的位置上。代码结构的流失是积累性的,越难看出代码的设计意图,

        就越难保护其中设计,于是该设计就腐败的越快。经常性的重构可以帮助代码维持自己该有的形态。改进设计的一个重要

        方向是消除重复代码。

    2.2 重构使软件更容易理解

        重构可以帮助我们让代码更容易被阅读,一开始进行重构时,你的代码可以正常运行,但结构不够理想,在重构上花一点

        点时间,就可以让代码更好表达自己的用途,这种编程模式的核心就是“准确说出我所要的”。重构可以协助理解不熟悉的

        代码,因为当你想对一些代码进行修改时,必须首先理解这个代码的用途。

    2.3 重构帮助找到 bug

    2.4 重构提高编程速度

        良好的设计是快速开发的根本,事实上,拥有良好设计才可能做到快速开发。如果没有良好的设计,或许某一段时间内你

        的进展迅速,但恶劣的设计很快就让你的速度慢下来。你会把时间花在调试上面,无法添加新功能。修改时间越来越长,

        因为你必须花越来越多的时间去理解系统、寻找重复代码。良好设计是维持软件开发速度的根本,重构可以帮助你更快速

        的开发软件,因为它阻止系统腐败变质,它甚至可以提高设计质量。

三 何时重构

        重构本来就不应该是专门花特定时间做的事情,重构应该随时随地进行,不应该为了重构而重构,之所以重构,是因为你

        想做别的事情,而重构可以帮助你把事情做好。

    3.1 三次法则

        第一次做某件事时只管去做;第二次做类似的事会产生反感,但无论如何还是可以去做;第三次做类似的事情,就该重构。

        事不过三,三则重构 。

    3.2 添加功能时重构

         重构的目的是更好的理解功能,可以更好、更快地添加新功能。

    3.3 修补错误时重构

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

    3.4 复审代码时重构

         复审可以得到很多好的建议,获取更高层次的认识,如果不进行重构,很难得到这样的知识。

四 重构难题

    4.1 数据库

         数据库重构的难题有二:1、商用软件的数据库和业务关联;2、数据的迁移;

    4.2 修改接口

         面向对象的封装性使得程序员可以将功能实现和接口独立开来,接口一旦发布,就很难修改。所以如果功能扩展而旧接口

         无法满足需求时,一个不坏的方法就是在旧接口中调用新的接口;其次,务必注意,接口发布之先,一定要修改代码所有

         权政策;

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

         有些项目过大,通过重构完全无法修改程序的设计。

五 何时不该重构

  1. 现有代码过于混乱,重构的成本大于重写
  2. 代码在大部分情况下无法正常运行,稍作改动,就报很多错误,无法稳定运作;
  3. 项目临近交付的时候;

六 设计与重构

     6.1 只有设计

          结合我自身的项目经历来看,由于初始用户需求不是太明确,项目又略显复杂。所以在开发之初总是想着考虑各种情况,

          尽量的让软件设计保持灵活;但是最后却发现,在开发的过程中总是会遇到各种问题,这个时候只能是修改设计,开发

          到最后设计也面目全非了,开发过程中也很累;

     6.2 只有重构   

          只有重构而不考虑开前的设计倒也可以,一个问题是如果不能熟练的掌握重构,要想在开发过程中很好的重构程序几乎

          是不可能的;毕竟设计更着重与系统的流程和架构,受业务影响,重构更关注的是功能模块的实现逻辑和模块之间的关

          系,更偏重技术角度;

     6.3 设计+重构

          这种方式会好很多,一方面可以简化设计,同时简化的设计又可以很好的指导开发,在开发的过程中遇到问题也可以通

          过重构灵活的修改设计;也就是说我们掌握重构后有足够的信心应对需求的变化。

七 重构与性能

  重构不一定提升软件性能,但可以使性能提升更容易;性能提升一般有三种方式:

  1.  时间预算法:预先定义软件各功能模块的时间成本,严格控制,从而提升系统运行时间;对于一般软件来说,无需这种要求;
  2.  持续关注法:程序员在做任何修改时,必须保证程序的高性能;一般很难实现,因为任何一次的修改如果是为了性能提升的话,通常都会使程序难以维护;如果以此换来程序的性能提升倒也值得,但是大部分情况下并非如此;性能改善往往着于一角,局部的性能提升了,但是整体的性能却是无法保证;不过就我开发的经历来说,部分性能的提升在很大程度上会提升系统性能,当然前提是软件编码很糟糕,有很大的优化空间;
  3.  根据二八原则,影响程序80%性能的往往是20%的代码;所以初始编码的时候无需耗费过多精力于重构,待编码完成,就集中精力测试,找到影响性能的20%代码,然后采用持续关注法和时间预算法(我认为两种方式可以交叉使用),集中优化;

猜你喜欢

转载自blog.csdn.net/jack1liu/article/details/105987320
01.