首页 > 软件测试/ 正文
养成重构的习惯有多重要
2012-09-18 10:50:13 ℃身为一个维护人员,我每天的工作就是研究产品的代码,修正各种bug,或者添加各种新功能。Martin Fowler在《重构》一书中使用了一个隐喻,“坏味道(bad smell)”。用这个隐喻来形容我目前的处境,那就是我正在粪坑里挣扎。这里充斥着“Copy/Past/Modify”而来的代码。为了实现一个功能而随心所欲添加的成员变量。长达一两千行的函数。几万行的类。到处都是public的成员变量。丰富多彩的编程风格。
这个程序运行起来很漂亮,用户也很满意(据说)。我想作为用户,是不需要关心代码如何如何的。作为老板也是不需要关心代码如何如何的(虽然他声称他很在乎)。那么正真关心代码的人是谁呢,我想来想去就是我自己,如果想改善生存环境只能靠自己。我先强调一下,这套代码不是我写的,我见到它时它已经是这个样子了,并且当我提出要进行整改时,所有人都是“能跑起来就不错啦,用户又没提,工时怎么算”。我只能作罢。我在这里不是发牢骚,牢骚我已经在项目经理那里发过了。我只是想讨论一下这个“粪坑”是如何形成的,有没有办法避免。
先描述一下我见过的比较普遍的新增功能的过程。我们拿到用户的修改需求后会做一个简单的评估,一般是比较有经验的程序员参加,然后给出一个简单的修改方案,就会由一个程序员(不一定是比较有经验的程序员)根据设计修改代码。等程序员完成修改并且测试以后就会提交到项目经理那里。项目经理还会找人,一般是他自己,再测试几遍。都通过了就会发送给用户。当然,用户还会测试。最后是上线。
Bug修改也是差不多的流程。可以看到整个过程都在控制之中,项目经理和用户完全可以通过充分的测试来控制质量。显然,在这个过程中代码的质量并不是问题的关键。代码糟糕,修改难度增加并不会导致用户给更多的钱和时间,相反他们会说:“这本来就是你们的责任”。对于管理层,他们并不会去修改代码,他们只需要驱使手下的程序员加班加点的“努力工作”。所以真正有切身厉害的是程序员自己,而造成这种局面的恰恰也是程序员自己。现在让我们回到上面描述的流程中,好好看看最简单的(项目经理们的原话)环节,代码修改。
这个程序员会先在代码里确定功能的起点也就是启动功能的地方,一般会从菜单入手。然后他会在代码里寻找相似的功能,看看有没有什么可以借鉴的。如果没找到,就只能从头开始编码,但是一旦找到了(大多数情况下是可以找到的,从这一点就可以看出这套代码的可怕),造粪运动就开始了。他会把那个函数整个拷过来,仔细研究,慢慢修改,边改边运行测试效果。这种方法收效甚伟,熟练工会以飞也似的速度进行修改。再加点班,一般都能在用户要求的期限内完成。皆大欢喜。
稍微复杂的功能就需要有点经验的程序员上了。但是操作过程与上面相仿,其实上面的操作就是这么代代相传的。只不过有经验者速度会更快,成功率会更高。但是我不得不说一句,这种方式让人作呕,毕竟这需要极大的耐心和细致,而且在成千上万行代码里上下移动滚轮很容易迷失,一天下来身心都是很疲倦的。有人搞软件搞到猝死也就不足为奇了。
这种代码基本上不可能自动测试,只能手动测试,测试起来非常繁琐,对于程序员来说是很繁重的工作。很容易让人烦躁,尤其是在加班赶进度的时候。这种代码会引起bug的爆炸,试想一处的bug被到处复制,而且还会引入新的Bug,后果之严重可想而之。这种代码破坏了几乎所有OO开发的原则,无法扩展,只能修改。通过他衍生出来的项目变得更加无法维护。
说了这么多,现在说今天的重点,我认为造成这种局面的原因如下:
1、管理层不重视代码书写,认为是体力劳动;
2、项目经理疲于应付进度,无心且无力;
3、程序员水平参差不齐,缺乏正确的指导。
我不是老板,不能要求老板像我一样看问题,其实想想看老板雇佣我就是让我来给他照顾代码的,所以我不能要求老板来帮我。项目经理的职责应该是控制项目进度,协调各方关系,像代码这种小问题也不应该劳烦他。剩下的就是开发人员了,作为每天都在和代码打交道的人实在没有理由不关心代码,实在不应该给本来就一团乱麻的代码添乱。其实只要不满足于只是完成功能(当然对很多人来说这已经很了不起了),完成功能之后多想一下,尝试寻找违反“DRY”原则的地方,尝试把平时学习的OOP知识印证到代码里,代码也许就能有极大提高,自己的水平也会提高。这种对代码进行反复批判调整的过程就叫“重构”,前面我们提到的那本书就是对这些方法的总结和提升。当然,要想正真掌握它并不容易,需要不断学习,实践和总结。但是我以为,最重要的是把重构变成习惯。只有当你养成了重构的习惯你才算是掌握了这个工具。
养成重构的习惯先要从训练对代码的审美开始。经常看到人们提到“代码之美”,我很赞同这种观点,但是对美的欣赏是一种比较高的层次。并不是每个初学者都能做到的。所以不如先学什么是“代码之丑”。辨别代码的丑俊有一个很简单的办法,寻找重复。代码的重复,数据的重复,配置信息的重复,甚至测试发布步骤的重复反复,都是丑恶的,都要清除。其次是简单。简单不是直接,不是把功能代码写到菜单事件里就叫简单。一开始可以这样写,但是要时刻提醒自己这里的代码其他地方可能会用到,要想办法提炼成功能明确的函数(Extract Method)。从习惯养成这个角度上讲,我认为程序员应该有代码洁癖。
在代码品味提高之后,很自然的就会对“不美的代码”产生“整容”的冲动。但是不能乱来,重构是讲求方法学的。Kent Beck说过:“我不会对无法自动测试的代码进行重构”。但是现实并不理想,我们也不是大师,而且生活所迫,所以有时候我们只能对“无法自动测试的代码”进行重构。建议大家都去读一读Martin Fowler的《重构》这本书。他先从方法学的角度对重构进行阐述,然后总结出许多实用的重构技巧。有了思想上的武装,重构就会有的放矢了。
养成一种习惯并不容易,需要外界的压力,需要自身的毅力,最重要的是足够的渴望。只要你是一个想把程序员作为终身职业的人,都应该尝试养成重构这个习惯。
- 上一篇:软件测试脚本设计心得
- 下一篇:接口测试原则之测试代码中的判断
更多郑州技校排名技校都有什么专业,河南计算机专业大专学校哪家好,河南技校都有哪些专业,郑州计算机中专技术学校有哪些,河南省的初高中生毕业2019年学什么技术,河南北大青鸟翔天信鸽招生网相关文章
- 深度解析Java内存的原型
- 关于自动化软件测试
- 关于如何提高代码可测试性的一些看法
- J.B. Rainsberger:“集成测试是个阴谋”
- 软件测试管理以及与自动化测试的完美结合(上)
- 我是怎样长大的(三)——软件测试这一路
- 浅谈基于watir的前端敏捷测试
- 敏捷测试的组织挑战
- 走在自动化软件测试的道路上(二)------我们应该做什么?
- 同行评审那些事儿(八):常见的问题
- 质量管理十大原则
- IT行业——轻方法与满意质量相比较
- 软件质量保证的误区
- 全功能团队——没有QA的团队
- 过程改进漫漫谈之过程改进的五个原则
- 软件质量保证管理办法
- 项目管理之质量管理(一)
- 质量的三重境界
- 将软件测试阶段按照生命周期的方法去分析
- 如何确定一个软件测试项目的终结点
- 软件质量的“奥秘”
- 基于关键性和安全性的软件质量保证
- PPQA培训小结
- iphone4s卡是怎么装的,Iphone4s装卡教程(图文)
- 注册表编辑器怎么打开,打开注册表命令
- 手机二维码是什么
- 关闭QoS可令网速提升20%是荒谬之说
- Windows XP 传真功能详解
- 为什么软件开发专业这么火爆,软件开发是做什么的?
- 搜索
-
- 热门标签
-
- 河南计算机专科单招学校
- 周口电脑学校哪家好呢
- 郑州北大青鸟java培训学费
- 郑州java培训学校哪家比较好
- 2017年程序员的就业形势怎么样
- 洛阳java培训机构哪家好
- 郑州北大青鸟招生电话是什么
- 郑州北大青鸟java培训学校好不好
- 新乡计算机职高有哪些专业
- 高级Java架构师于你还有多远
- windows网络编程技术
- 电脑培训学校
- 郑州培训java开发学校学完能高薪就业的
- 南阳有哪些电脑学校
- 河南郑州Java培训学校哪家好
- 郑州北大青鸟java培训课程包含哪些内容
- 河南北大青鸟计算机培训招生
- 郑州课工场培训学校哪家比较好
- 郑州2018最新Java培训机构排名
- 郑州程序员培训哪家机构好课程有哪些