重构原则

原创
2015/12/11 09:53
阅读数 76
  • 何谓重构

重构的两种定义,一种名词形式,一种是动词形式:
重构(名词):对软件内部结构的一种调整,目的是在不改变软件之可察行为前提下,提高其可理解性,降低其修改成本。
重构(动词):使用一系列重构准则(手法),在不改变软件之可察行为前提下,调整其结构。

重构不仅仅是整理代码,它提供了一种更高效且受控的代码整理技术。

两顶帽子:‘添加新功能’和‘重构’,在软件开发过程中,你可能会发现自己经常变换帽子,但无论何时你都应该清楚自己戴的是哪一顶帽子。

我的理解:重构是种约束性的软件结构调整行为,它有一系列准则,其约束性是不改变软件之可察行为。

  • 为何重构?

重构改进软件设计;

可以改善腐败变质的程序,你所作的就是让所有东西回到应该的位置上;
消除重复代码,你可以确定代码将所有事物和行为都只表述一次,唯一一次,这正是优秀设计的根本。

重构使软件更易被理解;

编程模式的核心就是“准确说出吾人所欲”。    

重构助你找到臭虫;

搞清楚程序结构的同时,也清楚了所做的一些假设,从这个角度说,不找到臭虫都难矣。

重构助你提高编程速度;

重构可提高软件质量(改善设计、提升可读性、减少错误),良好设计是快速软件开发的根本。

我的理解:这四点重构的原因,均可归结到重构可维持良好设计这一点上,重构是方法准则,良好设计是重构的结果,这四点是良好设计需具备的条件。

  • 何时重构

重构本来就不是一件特别拨出时间做的事情,重构应该随时随地进行。

三次法则:

添加功能时一并重构;
修补错误时一并重构;
复审代码时一并重构;
为什么重构有用?
程序有两面价值:‘今天可以为你做什么’和‘明天可以为你做什么’。
对于今天的工作,我了解的很充分;对于明天的工作,我了解的不够充分。但如果我纯粹只是为今天的工作,明天我将完全无法工作。

程序为什么如此难与的四个原因:

难以阅读的程序,难以修改;
逻辑重复的程序,难以修改;
添加新行为时需要修改既有代码者,难以修改;
带复杂条件逻辑的程序,难以修改;
因此,我们希望程序:

容易阅读;
所有逻辑都只在唯一地点制定;
新的改动不会危及现有行为;
尽可能简单表达条件逻辑。
重构是这样一个过程:它在一个目前运行的程序上进行,企图在不改变程序行为的情况下赋予上述美好性质,是我们能够继续保持告诉开发。

  • 怎么对经理说?

经理的角度:经常嘴巴上说自己是‘质量驱动’,其实更多的是‘进度驱动’。对于这种情况,作者则给了一个较有争议的建议:不要告诉经理。

我的理解:如果满足2.3的三次法则,重构行为随时随地进行,重构习惯融入到程序开发、修改、复审环节中,似乎重构与否的问题没有理由让经理来面对,但是那只是理想状态,我们有时不得不单独拿出时间来进行重构工作,所以这时候就做你认为该做的。

  • 重构的难题

数据库程序难以重构的两个方面:

程序与它们背后的数据表格结构紧密耦合,难以修改;
数据迁移。
解决方法程序与数据表耦合的方案:在对象模型和数据库模型之间插入一个分隔层,这就可以隔离两个模型各自的变化,升级某一个模型时无需同时升级另一模型,只需升级上述的分隔层。这样分隔层会增加系统复杂度,但可以给你很大的灵活度。无需一开始就插入分隔层,可以在发现对象模型变得不稳定时再产生它。

解决数据迁移的方案:

对象数据库提供不同版本的对象之间的自动迁移功能;
无自动功能,在数据尚未被转移钱先运用访问函数造成数据已转移的假象,一旦确定知道数据应该在何处时,就可以一次性地将数据迁移过去,这时唯一需要修改的只有访问函数。
重构了修改了已发布接口的解决方案:

让就接口调用新接口,当你要修改某个函数名称时,请留下就函数,让他调用新函数。千万不要拷贝函数实现码,那会让你陷入重复代码的泥沼中难以自拔;
除非真有必要,不要发布接口,团队内改变代码拥有权观念,让每个人都可以修改别人的代码。
总结:不要过早发布接口。请修改你的代码拥有全政策,使重构更顺畅。

  • 何时不该重构?

既有代码是在太混乱,重构它还不如重新写一个来得简单;
现有代码根本不能正常运作;
如果项目已近最后期限,你也应该避免重构。
文中经典比喻:把重构工作比做成债务,把过于复杂的代码造成的‘维护和扩展的额外开销’比作成要付的利息,你可以承受一定程度的利息,但如果利息太高你就会被压垮,你应该随时通过重构来偿还一部分债务。

  • 重构与设计

重构可以成为预先设计的替代品,极限编程的支持者提倡这种方法,但只运用重构也能收到效果,但不是最有效途径,xp爱好者也会进行预先设计,使用crc卡类似的东西检验想法,然后得到一个可被接受的方案,然后开始编码,然后才能重构。

重构改变了预先设计的角色,不必保证预先设计的准确无误,只需要得到一个足够合理的解决方案就够了。

  • 重构与性能

编写快速软件的秘密就是首先写出可调软件,然后调整它以获得足够速度。

编写快速软件的三种方法:

时间预算法——这通常只用于性能要求极高的实时系统。如果使用这种方法,分解你的设计时就要做好预算,给每个组件预先分配一定资源,包括时间和执行轨迹。每个组件绝对不能超出自己的预算,就算拥有可在不同组件之间调度预配时间的机制也不行;
持续关切法——这种方法要求程序员在任何时间做任何事时,都要设法保持系统的高性能;
90%统计数据——以一种良好的分解方式来建造自己的程序,不对性能投以任何关切,直至进入性能优化阶段,进入该阶段再按照某个特定程序来调整程序性能。
性能优化阶段的优化过程:首先应该以一个量测工具监控程序的运行,由它得知程序大量消耗时间和空间的位置,这样可以找出性能热点(hot spot)所在的一小段代码,对该性能热点,使用持续关切法中的优化手段。应该小幅度进行修改,每走一步都需要编译、测试、再次量测。如果没有调高性能,你应该继续这个“发现热点、去除热点”的过程。

一个被良好分解的程序可从两方面帮助此种优化形式:

它让你有比较充裕的时间进行性能调整;
它让你在进行性能分析时便有较细的粒度。

转自:http://www.cnblogs.com/blueclue/archive/2010/06/01/1749308.html

展开阅读全文
加载中

作者的其它热门文章

打赏
0
1 收藏
分享
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部