Hosted By
 |
 |
|
| |
|
 |
| |
|
| Apr 17, 2007 - 2:49 pm |
|
Introduction
I work for a very successful Fortune 500 Company. We have numerous applications that we develop and maintain. In particular I work on a product that brings in about 25 million a year. On a fairly regular basis I perform maintenance on the application. This mostly involves finding and fixing defects within the software. It always amazes me that given the state of the code the product makes the revenue it does. It?s been neglected for so long that many areas in the application require superhuman efforts just to maintain it.
I?ve spent a fair amount of time reflecting on why the code is in such a terrible state. Did the original developers not care or did they not know any better? I?d like to think the source of the problem is the latter. Had they known better, I suspect they would have properly cared for the application. Yet, the past is what it is and the code is in the state that it is.
As a developer who does know better I find myself with a rather large predicament. I?m often tempted to jump in, make my fix, and jump back out without performing any sort of maintenance. I call this bungee maintenance. However, that won?t help the product, my team members, or the customers who use the product.
To solve the problems and to properly care for my application I need to be continuously refactoring. There are many articles and books that have been written on the subject. The goal of this paper is to discuss the most common type of problems I see in the code. I suspect they are the most common because they are the easiest to create and come naturally to new developers.
Unless you?ve been living in a cave you?ve heard the term, refactoring. In case you haven?t I?ll quickly define it. Refactoring is the process of rewriting code in order to improve its structure without changing its behavior.
Many of you may be refactoring today without realizing this is what you are doing. Have you ever looked at a method or class and thought, ?This could be written better,? and then actually changed the design of the code? If so, then you?ve refactored.
Code Smells
Before we go any further, it would be a good idea for another concept to be introduced. This concept is the ?code smell?. I think everyone has heard at least one time or another that a certain piece of code ?stinks?. Code smells now give us a means to describe why the code stinks.
Duplicate Code
The first smell we want to discuss is the duplicate code smell. This is probably the most common smell you will find in an application. You can probably guess what this smell is all about from the name. Any time there are duplicate sections of code in an application there is the potential of duplicate code smell.
Duplicate code is often the result of someone identifying a piece of functionality the software has in one location that the software now needs in another location. The quickest way to implement the change is to copy the code from location A to location B. The end result may be what the developer wanted, but now a problem has been introduced into the application.
Let?s assume the functionality that was copied contained a bug. It?s sometime later before the Quality & Analysis (QA) department finds and logs the bug. A developer is then assigned to fix the bug. The area in question is quickly found by following the steps laid out by the QA engineer and the developer fixes the bug. However, because there is another copy of the code, the bug was not fixed there. It will have to wait until that particular issue is identified once again.
On the other hand, maybe the code was perfect but now its functionality needs to be expanded. Once again, if the developer does not locate all sections of the duplicate code then a problem is introduced into the software. It won?t be long before someone points out the inconsistent behavior.
Fortunately for the developer, this smell normally has a simple solution. The toughest part normally is identifying the duplicate sections of code to begin with. While some sections may be exact copies, others may perform the same logic but go about it differently.
Once the duplicate sections have been identified the fix is usually just a matter of creating a method that does the same functionality as the copies of code. When that?s been accomplished the developer can then remove the duplicate sections and replace them with a call to the new method.
Example:
procedure CalculateTotalPrice;
begin
price := price * quantity;
totalPrice := formatFloat('$###.##', price/100);
end;
procedure CalculateTotalCost;
begin
cost := cost * quantity;
totalCost := formatFloat('$###.##', cost/100);
end;
We have two methods: CalculateTotalPrice and CalulateTotalCost. Both take an integer value, convert it to a float, and then format it as a string with a currency symbol.
While this particular example is small it works well to illustrate the point. Suppose the product is being introduced to Europe and rather than using the dollar sign you now have to use the symbol for the pound. Or perhaps the particular product is being expanded to support gas stations and the price and cost now needs to show 3 decimals instead of the two currently being shown.
We could solve the first problem by making the currency symbol a constant. However, we?ll ignore that solution and leave it the way it is.
First we need to create a new method that contains the duplicate code. I?ve called it CurrtoString
function CurrToString(value:integer): string;
begin
result := formatFloat('?###.###', value/1000);
end;
Notice that both changes have been implemented in the new method. I?ve replaced the dollar sign with the pound and changed the formula to include three decimal points.
Next we need to replace the original sections of code with a call to the new method, CurrToString.
procedure CalculatePrice;
begin
price := price * quantity;
sPrice := CurrToString(price);
end;
procedure CalculateCost;
begin
cost := cost * quantity;
sCost := CurrToString(cost);
end;
There is now just one method that controls the converting of a currency field into its string representation. In the future, should something have to change, the developer only has to worry about the one method rather than possible copies that might be lurking about.
Long Method
The long method smell is also a common smell that exists in many software applications. This smell is often introduced when new functionality needs to be added to the software.
It goes something like this: There is a method that performs some sort of functionality. The project manager decides the application would better meet the needs of the customer if the functionality were extended. The assigned developer finds the method that performs the existing functionality and proceeds to add the new functionality. While in some cases this is appropriate, in many the developer is creating a long method.
This becomes a smell for several reasons. The first is that long methods are harder to debug. They often contain different levels of abstraction, which makes reading the code harder. They also tend to scroll off the screen which can become a problem if you can?t see the closing symbol for a particular block of code. Lastly, the method name becomes less descriptive of the process the method performs. Before the method name was DoSomething, It now needs to be changed to DoSomethingAndSomethingElse.
To fix this the developer needs to look at the method and decide the proper course of action. This might be as simple as just extracting pieces of the long method and making a new method, or it might entail the creation of a new class or classes!
In our example DoSomethingAndSomethingElse, you can see that there is a conditional block that was added to the bottom of the method.
(In real life this method would be longer and probably more complex)
procedure DoSomeThingAndSomethingElse;
begin
...
...
...
...
...
...
...
...
...
...
...
if someCondition then
begin
...
...
...
...
...
...
...
...
end;
end;
In this particular example the fix is rather straightforward. At a minimum the code inside the added conditional block needs to be extracted into it?s own method. Then a call to that new method needs to be made from the DoSomeThingAndSomethingElse method.
As an alternative solution you may have put everything before the conditional block into its own method and the conditional block itself into a separate method. In this scenario our method DoSomeThingAndSomeThingElse now has two method calls.
procedure DoSomeThingAndSomeThingElse;
begin
DoSomeThing;
DoSomeThingElse;
end;
The goal here is to reduce the length of the method and maintain a consistent level of abstraction. Often times each instance of this smell will require a unique solution.
By keeping your methods short, free of conditional complexity, and containing the same level of abstraction you can ensure that your method will be easy to maintain and understand.
Summary
These two code smells are most common smells that I run across and they are the source of many defects. You may be asking how a long method, duplicate code, or any other smell is the source of a defect. The code itself may be perfect and runs just fine, so how can it cause problems? The problem is that it increases the complexity of the code. It makes it harder to figure out what?s going on and therefore it creates an environment in which it?s easy to introduce defects.
We only covered two particular smells. There are many, many more. You should train yourself to identify them all. You should also know how to solve each one. Only then will the software you write maintain the elegance and style that it was created with.
Resources:
If you?re looking for more smells you can find some lists here:
http://c2.com/cgi/wiki?CodeSmell
http://en.wikipedia.org/wiki/Code_smell
http://www.codinghorror.com/blog/archives/000589.html
There are also some great books out there that discuss in depth some of the complex smells and the solutions needed to fix them.
?Refactoring To Patterns? by Joshua Kerievsky
?Refactoring? by Martin Fowler
|
|
|
|
| |
|
| Apr 1, 2007 - 6:02 pm |
|
The torpedo left the bay and streaked towards a giant interstellar gas cloud. As it reached the center of the could a wildly bright light flashed from the torpedo as it exploded. In an instant the light was gone as the energy released increased out of the visible spectrum. What was visible was the effect on the gas cloud. Slowly, the center of the cloud began to condense and collect. Zbop was witnessing a marvel of mankind?s technological achievement. No matter how many times she saw it, the process of creating a planet always amazed her. Humans definitely were admirable, she thought, even if they were a scourge she was going to destroy.
Zbop scanned the initial reports coming. The orbit was steady and planet appeared to holding together. Elemental composites were as expected. This was good. ?Send the terraformers? she ordered. ?Send the terraformers? the operations officer repeated.
Moments later several enormously large ships separated from the fleet and headed towards the freshly created planet. Their work would take many months to complete, but at the end it would be a beautiful planet supporting life.
Zbop watched with pride as the terraformers entered orbit around the new planet. She had been at this for many decades now. In the back of her mind she wondered if they would come again. No, she decided, we?re well hidden and well protected. It will never happen again!
***
Generations had passed since the last encounter in which The Hive had almost been annihilated in a great and tremendous war. For seven years Admiral Ak5intoe and his fleet continuously battled the superior numbers and forces of The Hive. The human solution was to be final and nothing was spared. One by one as they fell, the planets of The Hive burned and were destroyed.
Eventually, the Admiral surrounded Zbop?s, or the Queen as her subjects call her, home planet. The ensuing battle was a meat grinder. Planetary defenses were strong. For days the fleet and the planet traded fire causing heavy losses with the fleet sustaining the most. At a pivotal moment in the battle, the Admiral entered low orbit and blasted the beams from his capital ship at point blank range against the planetary shields. Separated from the fleet and unprotected this was a dangerous moment. The beams collided with the shields surrounding the planet. At first nothing happened, but then a shimmer appeared in the shields and pulsated in unison with the beams. Fortunately, for the Admiral, this dangerous move paid off. The shields failed and the beams hit the surface destroying the generators and dropping planetary defenses. At that moment a small craft left the surface of the planet and entered a low orbit. The fleet moved to engage but before the fighters and missiles could intercept the ship it engaged it?s light drives and entered sub space. Planetary reconnaissance later confirmed what the Admiral and all of humanity feared. Zbop had escaped.
****
Current Day
Lieutenant MacGregor sat at his assigned station dutifully performing his work. As a science officer one wouldn?t describe his occupation as exciting or interesting. However, one would describe it as vitally important. He and the other science officers were searching for the location of their sworn enemy.
?Hmm? he thought. ?Is this accurate??
?Sir, one of our probes is reporting a growing gravitational disturbance on the outer edges of space. I?ve checked it against archived scans in the area and there?s something defiantly happening out there. Computer analysis shows an increased gravitational density of at least 50 planetary masses.?
Admiral Guts smiled. ?Good work Lieutenant. I think you?ve just found The Hive. It was only a matter of time before their imperialist expansionism gave them away.?
?Mr. Gata, order the fleet to prepare for an immediate jump? the Admiral stated. At that command the bridge began to buzz with activity. Even the queen would have been impressed at the disciplined response that was now readying the fleet for combat. Within moment?s, ships within the fleet were reporting that they were ready to jump.
?Leiutenant McGregor, give the helm coordinates for the jump?.
?Coordinates received? the helm responded.
Admiral Guts smiled as he ordered ?Prepare to jump?.Jump?.
At that moment the largest armada ever assembled by man left. Each ship tore a small hole in subspace entered. As the hole collapsed it released a bright light signaling that the ship had passed. What awaited them on the other side was unknown.
Entry Edited 1 time - Edited on Apr 6, 2007 - 12:06 am
|
|
|
|
| |
|
| Aug 4, 2005 - 1:23 am |
|
Ok this one was much tougher and took over an hour. One of those pieces of paper was tough to fine. Plus it took me a while to realize the value of a cold beer 
Langel.. post more.
|
|
|
|
| |
|
|
|
|
| |
|
| Jun 6, 2005 - 2:09 pm |
|
I told everyone I?d post my thoughts regarding the team tourney so here they are.
To begin with I think some teams were luckier than others during the draft. My strategy was to get a couple of good attackers and a couple of good builders. As such my goal was to get Big, SLIM, YOYO and Nambia. Three out of four wasn?t bad. Nambia is an excellent builder and I wish we would have gotten him, but I felt comfortable with what I had. I also wanted people whom I?d seen spend a lot of time online.
The team that probably fared the worst was Ares?s. I really can?t fault him though, he was drafting players he knew very little about. As a result he got a big grab bag.
Once the tourney got going we were off to a rocky start. We had started a snowball and it was going nicely until it was completely lost. Myself, Barrow Warden, and Langel and YOYO did what we could to get it going again. By then Barrow Warden and I had completely spent our turns. About this time Big made his first appearance and was off to a great start thanks to the snowball. Likewise SLIM was doing very well despite his planets having been sucked dry of cash.
It was only a day or so before we were able to start naving nests and performing sequential rs searches. From then on, we started smashing the opposing teams, Slim just went nuts. At 10k sectors there wasn?t really any place for the other players to hide, and the body count was steadily rising (I always got a good laugh at doing a long range scan to sector 1 and seeing the ship / pod count) . This gave our builders and newbies a chance to build in relative peace. YOYO is a building machine, he had nests all over the place.
Before the tourney started I envisioned us carrying out assigned tasks and working really hard together as a team. Our lead was so large though that I pretty much just let people go and do what they wanted.
I want to congratulate those on the opposing teams that stuck it out especially Nambia. It?s not easy to start over every other day. Oakman?s team also did very well considering it was only him and maybe two others that were playing. Same with Wraith?s.
|
|
|
|
|
|
