代码重构

来源:互联网 发布:中国学术论文数据库 编辑:程序博客网 时间:2024/06/18 15:37

开发人员可能听到过"bad smell"这个词,这个词用在软件编码中是什么意思呢? 代码还有smell吗?当然没有,正如计算机病毒,bug等词一样,这只是个形象的说法。这个词在这里的意思是代码实现了需求,但是代码却不精炼,冗余,结构混乱,难读懂,难维护,难扩展等等。与之相对应的一个词是"refactor",即代码重构。我们在看些外国人写的程序时可以发现,他们的代码里一般会定义大量的类、接口、方法,类与类,类与接口之间很多是继承和实现的关系,方法的代码行数很少,超过20行代码的方法不多,看他们的代码感觉最多的就是方法之间的调来调去,不像我们的代码,一个方法下来几十上百甚至两三百行都是最基本的语句构成,很少调用自己的方法。两相比较,可以看出,前者在结构上更清晰,通过类视图就可看出设计意图,并且总的代码量不会高于后者,而后者代码量庞大,代码冗余现象严重,结构不清晰,很难维护,如要修改某个错误,可能涉及到要修改的代码点很多,这样后来的维护者就很头疼了。造成这种状况的原因有这样一些:

1.经验不足,分析设计不到位

2.敏捷开发,虽然经验很多,但为了快速开发,没有经过分析设计

3.缺乏意识,只为实现功能而写代码,不管代码质量

对于这样的代码,我们怎样将其变得更为精炼和易于维护呢?这就是代码重构。重构不是针对功能,纯粹是对代码本身。重构后的代码不会影响到系统的运行。

我们来看看可以在哪些方面对代码进行重构:

1.重命名:对类,接口,方法,属性等重命名,以使得更易理解

2.抽取代码:将方法内的一段代码抽取为另一个方法,以使得该段代码可以被其他方法调用,这是重构中很重要很常用的,此举可以极大的精炼代码,减少方法的代码行数

3.封装字段:将类的某个字段转换成属性,可以更加合理的控制字段的访问

4.抽取接口:将类的某些属性,方法抽取组成个接口,该类自动实现该接口

5.提升方法内的局部变量为方法的参数:这主要是在写代码的过程中会使用到

6.删除参数:将方法的一个或多个参数删掉

7.重排参数:将方法的参数顺序重新排列

实际应用中,用的最多的是1、2、3,我们可以在写代码的时候有意识的运用代码重构,这样当我们完成编码时代码的质量也能得到保证



The 7 stages of refactoring

You have wanted to fix that module for ages. Just one look at it and you cringe. The documentation, the weird naming of functions, classes that are just plain weird. The module hobbeles along, but it is just plain dirty. The real programmer in you cringe, and when there finally is some time to refactor the module, you jump at it.

Step 1 - Desperation 
So you start to have a real good look at what you need to. Fix a class here, rename a few functions there, tear out a few functions here. Simple, right? Well, what at first glance seemed like a simple fix, a few tweaks, now envisions itself as a  monster of badly written code, ambigous comments and weird datastructures. You find members that are (seemingly) never used, functions that do the exact opposite of what they are named, etc. You cannot envision how anyone would be able to finish this is in 5 days (the time you have allocated).

Step 2 - Fixing it one line at a time
You acknowledge that this beast cannot be tackled in a single go, so you start with a part of the module and start with the small things - renaming functions, moving code blocks, create constants. You know that if nothing else you will at least not make the code worse.

Step 3 - Desperation (again)
But then, you hit a brick wall. You see the flaw in trying to reach a local minima, and see what you should do is a total rewrite. You do not have time for that, however, so you make a partial rewrite, by trying to reuse as much as you can from the old code. It will not be perfect, but you will at least try.

Step 4 - Optimism
You pound at the problem for a few days, slowly making progress and improving your code. You see how the code should be, the way the classes are bolted together. Yes, you are a few days overtime on your allotted time, but it is worth it.

Step 5 - Scram
You have used way too much time on this by now, and you feel more and more embarrassed for every standup. What should have been a simple refactoring turned into a total rewrite. And just because you wanted the code to be perfect. So you do some shortcuts, skimp on some documentation here, write it fast and dirty there. It will not be perfect, but it will do. You run the tests, and of course they all fail, but you do some quickfixes, and in the end it works fairly well. You pat yourself on the chest and do the commit.

Step 6 - Fixin time
Your rewrite was not perfect. Although it did pass its tests, they were too narrow and did not cover all the edge cases. So during a few weeks after the rewrite you apply more and more quickfixes, making the design more inelegant for each fix. It is no longer as perfect as you wanted it, but at least it is better.

Step 7 - Enlightenment
6 months passes, and you get another bugfix on the module. It has somehow gotten less pretty by the month. You see the inconsistencies and problems with the design that did not show up when you first had a look at it. And you see that what it replaced might not have been that bad in the first place, it did cover some cases that your code had not thought about. Someone on your team pushes for this to be rewritten, and you step back and let him - hoping that he too will in a few months will be enlightened.

0 0
原创粉丝点击