转自:http://www.cnblogs.com/Kevin-moon/archive/2010/05/10/1731358.html
先从接触过的几个老项目经历来谈谈,对于老项目来说,大家在初步接触的过程中,大多总是抱着抵触的情绪,甚至有些是蔑视。总喜欢对以前的代码挑出一大堆的问题,接着就开始抱怨代码、抱怨以前的开发人员,经过一段时间郁闷的抱怨阶段后,处于职业的责任心,就很想去改变这一切,希望把自己认为好的方式给带进来,于是接下来的工作就是重构代码了。
这也许大多数开发人员都经历过,这种经历是辛酸的(因为重构工作虽然重要,但是得不到过多的认可,目前国内关注的是可用性,对于代码质量并没有得到应有的重视),也是甜蜜的(风雨之后总会有彩虹)。对于年轻的开发人员来说,见到彩虹的过程是痛苦、漫长地。他们都是在失败中成长,这些失败除了经验外,主要是由于太急功尽力了,盲目的重构!
盲目主要体现在:
1、在还没有对系统整体架构有个清晰认识的时候,就想用自认为新的技术或架构来替换。
2、根本不分析现有系统架构或程序存在的弊端,只是一味地谈设计模式,以设计模式中固有的一套来重构(在重构中,它只作为一个参考,而不是一个依据。)
3、重构比较随性,每个版本的开发都跳出架构之外随意带入新的设计思想
这种盲目重构后给系统会带来更多问题:
你会发现当你重构完后你的系统运行效率变低了,
系统中同时存在多种思想,新加入人员更难接手,
由于你没有完全了解系统,反而在你的重构当中带来了很多重复代码,
最悲剧的是你重构后的代码也被其他人当成垃圾,而进行重构。
那么我们怎么消除盲目呢!?
首先,了解目前项目是否存在问题,存在什么问题,这些问题是否能通过重构来解决,如果能,才进行重构,你的重构时间是需要公司给的,老板不会因为你说依赖性强偶合性低就同意的,你必须要通过问题来让他认识,关键的是只有通过问题才能得到重构时间和资源,并且你的工作才能得到认可,这是一个很现实的情况。
接下来,你要确定重构的对象,是针对架构还是局部代码,并且去设定一个理想的目标(为什么是理想的?因为我们不可能一步到位,理想和现实是有差距的,但是我们要做的是尽力去往理想上靠拢)。
如果是针对架构进行重构,那么这可不是一件轻松的事情,再真正开始之前需要做到以下几点:
1、全面的了解系统的过去,包括以前的架构/技术背景、业务需求
2、分析以前架构的问题,例如:可维护性低、在哪个方面已经不满足现有需求等等
3、查看至少80%的核心代码,最好有一定时间的真实在以前代码基础上编码的经历
做到上面几点就是为了保证你能有一个清晰的认识,做到知己知彼。接下来可以进入实质阶段了吗?不行,还少了一个很重要的东西,重构计划!
这种大范围的重构,在真实情况下,一般老板给予的时间和重构真正所需用的时间相差很大,所以重构的工作是需要往后延迟的,那么就会出现又要重构又要进行新需求的开发;还有这项工作不是一个人的事情,是一个团对,既然涉及到多人合作,除了共同的目标外,还需要有一定的评审机制,这是为了保证重构的方向一致,等等,在这些因素下要做好重构,就是需要重构计划的理由。
针对局部代码进行重构来说,也许会简单的许多,不过需要注意的地方是,你一定要符合现有架构的思想,在它的范围之内去思考。
其实这种方式的重构大多就是提取方法,或者是以真实业务流程的思路去重构现有的代码执行流程,以便易于理解,或者是降低程序之间的依赖性。要做到这些有个很重要的思维方式:
1、善于从某个事物中分析出什么是事物的本质和什么是事物的外部环境。
2、从很多不同事物中去发现共同点,并对这些共同点进行抽象化(举个简单的例子:对于宝马和奥迪,你应该把他们抽象化为汽车)。
为什么这样说,因为这些能带来重构代码所需要的:
1、在写代码过程中降低了依赖性,
2、抽象化的事物复用性更强
做好上述的所有就表示重构完成了吗!不可能,这只是一个好的开始而已,我们要做到持续重构,就像敏捷中提到的。
也许有的人认为不现实,因为项目经理不会在每个版本周期内给出这个时间,其实,我就纳闷了,为什么不给?!不给的原因一定在你,如果你期望是一周或者更久,那么谁都不会同意,一周的时间都基本都能做完一个版本的设计了,重构还需要这么久,如果真的需要就说明你前期的设计很差!我所希望的时间是两天左右,因为这只局限于很小范围内的变动。
如果你们很好的做这些,那么你的项目可维护性一定很好,并且加入你的项目会是一件愉快的事情,这并不是什么理想的事情,只要你持之以恒地去做,实现起来其实很简单。
以上这些就是个人关于重构的一些想法,也许光从文字看上去比较空洞,后面,将分享一些真实的重构案例,供大家参考和交流。
架构重构:
1、重构计划
代码重构:
2、提取获取交集的算法
相关推荐
正则化理论由 Tikhonov和 Miller提出,为采用正则化方法解决不适定性问题提供了一个基本的解决思路,其中基于稳定函数(stabilizing functional)方法是最基本的方法。根据此方法,一个不适定性问题可以转化稳定函数的...
9. **重构的时机**:最佳的重构时机通常是当代码的复杂度增加、bug频繁出现或需求变化时,这时重构可以帮助我们理清思路,使代码适应新的需求。 10. **团队协作**:重构不仅是个人的任务,而是整个团队的共同责任。...
书中详细阐述了重构代码的必要性、重构的时机以及如何安全地重构代码。重构指的是在不改变软件外部行为的前提下,改进其内部结构的过程。这是一种在软件开发中不断优化代码质量、提高软件可维护性的技术。 重构技术...
首先,书中讲解了重构的动机,指出当代码变得难以理解和修改时,重构可以帮助我们理清思路,使代码更易于理解,减少错误,提高开发效率。通过实例,Fowler展示了如何识别需要重构的代码特征,如冗余代码、复杂的条件...
前两篇(思路和方法、重构计划)从大的方面上谈了关于重构的话题,这次从小的代码上来看。我们来看下一个的代码如何从简单到复杂,然后重构这些代码。单个对象复制在初步的需求中有个很简单的业务,就是定义销售合同...
- **清洁代码**:通过重构,可以清理代码中的“尘埃”(即不必要的冗余和混乱),使其更加简洁、易于理解。 - **提升可维护性**:重构有助于提高代码的可读性、可测试性和可扩展性,从而确保软件项目的可持续发展...
通过对代码规范相关的三本书《重构,改善代码的既有设计》、《代码整洁之道》、《阿里巴巴Java开发手册》,抽取了重要成分,对代码优化重构思路的一次总结
【Android代码-使用Rxjava重构煎蛋高仿】 在Android开发中,RxJava是一个非常流行的库,它将函数式编程的概念引入到事件...此外,对于熟悉煎蛋网的用户界面,还可以了解到如何复现实现类似功能的代码结构和设计思路。
- **信息可视化**:将抽象的编程概念转化为图形,更直观地理解代码结构和设计思路。 - **沟通工具**:团队成员可以共享思维导图,加速理解和共识,提高协作效率。 综上所述,简明代码和重构是提升代码质量的关键...
当团队成员共同对代码进行重构时,他们可以更好地理解彼此的设计思路,使代码更加一致和易于理解。这样的实践有助于提高整个团队的开发效率,降低沟通成本,并为项目带来更加稳定的发展。 总之,《重构:改善既有...
微信在微信Android模块化架构重构实践分享中提及的模块 api 化是非常棒的思路,模块公共代码的维护还是在所属模块内,大大提升开发体验。这个 demo 由此而来。 Demo plugin-xxx 的 module 均为业务 module, plugin...
BooheeRuler 这是仿写薄荷健康里面体重选择尺的控件,因为最新的0.1.x版本经历重大更新(重构...(这里重构的思想和我之前YMenuView2.0的重构思路有点相似)具体的重构思路我后面可能会写一篇文章介绍(又挖坑,目前
该书讨论如何在现有代码的基础上重构,并加入新代码的各种具体的思路和方法
通过查看和分析源代码,开发者可以理解程序的设计思路,学习编程技巧,也可以根据需求对代码进行定制化修改。 3. **ASP 技术**:ASP 提供了一个服务器端的脚本环境,使得开发者能够在服务器上生成 HTML 页面,动态...
在软件开发过程中,重构是一个至关重要的步骤,它涉及到对现有代码的改进,以提高代码的可读性、可维护性和整体结构,而不改变其外在行为。本文将深入探讨重构的几个核心方面,包括重构的要求、工作流程、识别代码...
于是我对源代码进行了一些重构,将爆炸流程和粒子运动分离。 对于源码,大家可以参考以下链接 链接1 链接2 上面两套代码,其实结构都是一样的,但是实现的效果不同(其实就是粒子运动的算法不同)。 本篇文章,将给...