This post originated from an RSS feed registered with Java Buzz
by Jiri Lundak.
Original Post: Beware of ... Logic Scattering
Feed Title: Jiri on Java and Jini
Feed URL: http://www.kstaken.com
Feed Description: Jiri Lundak's thoughts on Java, Jini, Distributed Systems and Software Craftsmanship
Scattering Logic ..... This is maybe the oldest sin in software development.
And although nearly all application and framework developers know it, it is notalways easy to accomplish.
You know how it happens: You remain stuck in the 'make it run' phase of your implementation (you swear to yourself you will come back to the code later, but the appplication had to be shipped yesterday) and have no time to '... make it good and fast', how Kent Beck stated.
Making an application run is often the pre-dominant goal of any developerliving in this time constraint world. But anybody of us that strives for quality workwill try to counter the smell of code rot, by mercilessly refactoring what he hasdone in the past and this as soon as possible. An notion of this attitude is expressedin the sentence (found here at Ward Cunningham's Wiki):
"I've found that CopyAndPaste works well in conjunction with RefactorMercilessly. First I copy and paste a bit of code. Then I get it working in its new environment. Finally I RefactorMercilessly to remove the duplicate code. At that point I know the exact requirements of the refactoring, so I can be sure to DoTheSimplestThingThatCouldPossiblyWork."
But what do you do, if merciless refactoring is made much more difficult, than it has to be?
What are factors that hinder good refactoring practices?
You have not enough timeAs you are continually hunting impossible deadlines, you never go back topreviously written code to change it, thinking that only copying andpasting it to a new place and working on that is faster.
You work with too many different code artefactsA part of your code is in HTML or some JSP TagLib, some in JavaScript on theclient- or server-side and other pieces are in Java-code running on the server(I have yet to find a tool, that facilitates cross-language/-paradigma refactoring!)
You are forced into a world of StringsEvery parameter in your code is a String (this happens predominantly in web applications).As you are constraint to parse and interpret the semantics of these Strings (something currently no tool can do for you), you have to be very careful, as you have to findall the places your String is interpreted or parsed. As you depend on your personaldiscipline in doing that accurately, this is no easy endeavour.
Large duplicated code basesIf, because of the structure of the web framework you are constrained to use or thearchitecture of your application you have chosen, you duplicate for each project youbegin, the whole tree of code-artefacts (this happens especially in template-orientedapproaches to web development), then you are in trouble, if it occurs, that you wantto make a change where the scope of it spans multiple or all of your code bases.
No use of change management toolsIf you have no change management procedure in place or do not at least use a codeversioning system, then chaos is at your door. Ok, I know this is common sense, butI have seen already some projects, where multiple developers worked on code fragmentsand steadily refused to use CVS (this especially for HTML, JSP-like pages). The problemwith this is, that you have no way to guarantee a stable tested code base.
Use of a closed source framework or librarySometimes you have no choice than to use some proprietary technology (be it a libraryor a framework). Were these third-party parts start your refactorings stop. The problemgets bigger with white-box frameworks, where you have to use and understand theframework and your code gets littered with methods that you find awful - but you cando nothing about that.
You have no good unit tests in placeMissing or incomplete unit tests will inevitable slow down your effort to refactor, becauseyou will never be quite sure you did not change anything that breaks your system.
Your business objects are defined in a database or some XML descriptorWhen in comes to change your business objects (whatever they may be) and they aredefined entirely in a database, then it is inherently more difficult to change their definition,as a synchronized change to the source code AND the datastore has to be made. XML descriptor are somewhat less difficult to handle, but still bear a semantic breakto your common source code (be it Java or something else). Some integrated tool suitestry to address these difficulties.
I do not say, that these hinderances can not be addressed, but usually the more of them you encounter in your development effort, the more you will be reluctant to refactor and the moreyou will have a problem in the long run.
What can be done to encourage good refactoring habits?
Take yourself time to refactor (you will accelerate your development even in the shortrun)
Try to stick to as few code artefacts and technologies as possible (this is actually oftenan architecture choice).
Reduce code duplication whereever possible (even in HTML template code)
Get at least a source control tool and use it exclusively
Never let there be different code bases that do essentially the same thing
Reduce the number of different database schemas that store nearly the same information(try to abstract and unify the database schema where ever possible)
Have a strong set of unit tests in place
Place the meta description of your business objects as closely to the code as possible
And if you are a manager...
Let your developers refactor
Create a culture, where refactoring is part of the quality assurance of your product orservice
Sell it as the continuous fight for perfection
See the benefits it will bring you in the long run: Clean, easy to change code, flexible enought to grow with your business and not hindering it
Have you found other factor hindering your urge to refactor? What has helped you to makerefactoring easy and a constant way to improve your software. Let me know! I am very interestedin what you think.
Jiri
Previous Topic
