电脑故障

位置:IT落伍者 >> 电脑故障 >> 浏览文章

用JBuilder 2005实现重构之认识重构


发布日期:2021/4/5
 

为什么要重构

从Martin Fowler所着的《重构改善既有代码的设计》一书连续两年成为最畅销的计算机图书之一就可以知道重构给程序员所带来的欣喜程度了

那么什么是重构呢?重构就是在不改变软件现有功能的基础上通过调整程序代码改善软件的质量性能使其程序的设计模式和架构更趋合理提高软件的扩展性和维护性

也许有人会问为什么不在项目开始时多花些时间把设计做好而要以后花时间来重构呢?要知道一个完美得可以预见未来任何变化的设计或一个灵活得可以容纳任何扩展的设计是不存在的系统设计人员对即将着手的项目往往只能从大方向予以把控而无法知道每个细枝末节其次永远不变的就是变化提出需求的用户往往要在软件成型后始才开始品头论足系统设计人员毕竟不是先知先觉的神仙功能的变化导致设计的调整再所难免所以测试为先持续重构作为良好开发习惯被越来越多的人所采纳测试和重构像黄河的护堤成为保证软件质量的法宝

通过重构可以达到以下的目标

持续偏纠和改进软件设计

重构和设计是相辅相成的它和设计彼此互补有了重构你仍然必须做预先的设计但是不必是最优的设计只需要一个合理的解决方案就够了如果没有重构程序设计会逐渐腐败变质愈来愈像断线的风筝脱缰的野马无法控制重构其实就是整理代码让所有带着发散倾向的代码回归本位

使代码更易为人所理解

Martin Flower在《重构》中有一句经典的话任何一个傻瓜都能写出计算机可以理解的程序只有写出人类容易理解的程序才是优秀的程序员对此笔者感触很深有些程序员总是能够快速编写出可运行的代码但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手试想一个新兵到来接手这样的代码他会不会想当逃兵呢?

软件的生命周期往往需要多批程序员来维护我们往往忽略了这些后来人为了使代码容易被他人理解需要在实现软件功能时做许多额外的事件如清晰的排版布局简明扼要的注释其中命名也是一个重要的方面一个很好的办法就是采用暗喻命名即以对象实现的功能的依据用形象化或拟人化的手法进行命名一个很好的态度就是将每个代码元素像新生儿一样命名也许笔者有点命名偏执狂的倾向如能荣此雅号将深以此为幸

对于那些让人充满迷茫感甚至误导性的命名需要果决地大刀阔斧地整容永远不要手下留情!

帮助发现隐藏的代码缺陷

孔子说过温故而知新重构代码时逼迫你加深理解原先所写的代码笔者常有写下程序后却发生对自己的程序逻辑不甚理解的情景曾为此惊悚过后来发现这种症状居然是许多程序员常患的感冒当你也发生这样的情形时通过重构代码可以加深对原设计的理解发现其中的问题和隐患构建出更好的代码

从长远来看有助于提高编程效率

当你发现解决一个问题变得异常复杂时往往不是问题本身造成的而是你用错了方法拙劣的设计往往导致臃肿的编码

改善设计提高可读性减少缺陷都是为了稳住阵脚良好的设计是成功的一半停下来通过重构改进设计或许会在当前减缓速度但它带来的后发优势却是不可低估的

何时着手重构

新官上任三把火开始一个全新的项目时程序员往往也会燃起三把火紧锣密鼓脚不停蹄加班加点一支声势浩大的千军万夹裹着程序员激情和扣击键盘的鸣金奋力前行势如破竹攻城掠地直指黄龙府

开发经理是这支浩浩汤汤代码队伍的统帅他负责这支队伍的命运当齐恆公站在山顶上看到管仲训练的队伍整齐划一地前进时他感歎说我有这样一支军队哪里还怕没有胜利呢?但很遗憾你手中的这支队伍原本只是散兵游勇在前进中招兵买马不断壮大所以队伍变形在所难免当开发经理发觉队伍变形时也许就是克制住攻克前方山头的诱惑停下脚步整顿队伍的时候了

Kent Beck提出了代码坏味道的说法和我们所提出的队伍变形是同样的意思队伍变形的信号是什么呢?以下列述的代码症状就是队伍变形的强烈信号

代码中存在重复的代码

中国有 家整车生产企业数量几乎等于美欧所有汽车厂家数之和但是全国的年产量却不及一个外国大汽车公司的产量重复建设只会导致效率的低效和资源的浪费

程序代码更是不能搞重复建设如果同一个类中有相同的代码块请把它提炼成类的一个独立方法如果不同类中具有相同的代码请把它提炼成一个新类永远不要重复代码

过大的类和过长的方法

过大的类往往是类抽象不合理的结果类抽象不合理将降低了代码的复用率方法是类王国中的诸侯国诸侯国太大势必动摇中央集权过长的方法由于包含的逻辑过于复杂错误机率将直线上升而可读性则直线下降类的健壮性很容易被打破当看到一个过长的方法时需要想办法将其划分为多个小方法以便于分而治之

牵一毛而需要动全身的修改

当你发现修改一个小功能或增加一个小功能时就引发一次代码地震也许是你的设计抽象度不够理想功能代码太过分散所引起的

类之间需要过多的通讯

A类需要调用B类的过多方法访问B的内部数据在关系上这两个类显得有点狎昵可能这两个类本应该在一起而不应该分家

过度耦合的信息链

计算机是这样一门科学它相信可以通过添加一个中间层解决任何问题所以往往中间层会被过多地追加到程序中如果你在代码中看到需要获取一个信息需要一个类的方法调用另一个类的方法层层挂接就象输油管一样节节相连这往往是因为衔接层太多造成的需要查看就否有可移除的中间层或是否可以提供更直接的调用方法

各立山头干革命

如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能你会发现往往是因为开发团队成员协调不够造成的笔者曾经写了一个颇好用的字符串处理类但因为没有及时通告团队其他人员后来发现项目中居然有三个字符串处理类革命资源是珍贵的我们不应各立山头干革命

不完美的设计

在笔者刚完成的一个比对报警项目中曾安排阿朱开发报警模块即通过Socket向指定的短信平台语音平台及客户端报警器插件发送报警报文信息阿朱出色地完成了这项任务后来用户又提出了实时比对的需求即要求第三方系统以报文形式向比对报警系统发送请求比对报警系统接收并响应这个请求这又需要用到Socket报文通讯由于原来的设计没有将报文通讯模块独立出来所以无法复用阿朱开发的代码后来我及时调整了这个设计新增了一个报文收发模块使系统所有的对外通讯都复用这个模块系统的整体设计也显得更加合理

每个系统都或多或少存在不完美的设计刚开始可能注意不到到后来才会慢慢凸显出来此时唯有勇于更改才是最好的出路

缺少必要的注释

虽然许多软件工程的书籍常提醒程序员需要防止过多注释但这个担心好象并没有什么必要往往程序员更感兴趣的是功能实现而非代码注释因为前者更能带来成就感所以代码注释往往不是过多而是过少过于简单人的记忆曲线下降的坡度是陡得吓人的当过了一段时间后再回头补注释时很容易发生提笔忘字愈言且止的情形

曾在网上看到过微软的代码注释其详尽程度让人歎为观止也从中体悟到了微软成功的一个经验

上一篇:JVM优化配置

下一篇:lucene中对不同的域使用不同的分析器