For anyone experienced in writing good OO code, the design is critical. Planning ahead is essential in creating reusable objects. I have been working on some old code that I wrote when I first started my current job and at the same time was very new to Java. Its horrible. Everything thrown in together. Control, view and models all in one class; kludges, hacks and workarounds thrown in instead of proper refactoring. Right now I am adding a new feature to the system. I had two choices glue another piece of code to the mess or refactor the whole code base while adding in this change. The result an extended project but more maintainable code, better code generally. Additionally many things that I am aware could be added or an issue have been taken care of, so that they should be easier to deal with later.
So why was it such a mess in the first place?
There are many reasons, but it comes down to perceived amount of time to finish a task. If I think I can get something done with a little hack or a quick kludge then thats the way its going to get done. I know its wrong and I know in the future it might cost me but my environment can sometimes dictate that it must be done now. I am the CTO, I am the bridge to the technical staff. My position is to get the technology working based on the requirements of my non technical bosses. The situation where my bosses think something simple in their heads should be easy and quick to implement happens time and time again
The non technical management want working systems or products. My products are two separate systems. One system is an offline system. They run it, it does something, and produces a result. The other is a live realtime system that runs 24/5 communicating with the outside world. That is what they want to see, it is my job to make sure they are produced, working and reliable. Occasionally they request changes or we have routine upgrades. This is where things get complicated. They want it done. They want it done soon. They have no understanding of unit testing, refactoring and documentation.
What is the solution?
Get it done. Many could argue getting it done means unit tests and refactoring as you go. They would say that doing testing and keep code maintained is actually efficient in the short run as well. This maybe the case but some times I am just too short sighted to see it like that. I am under pressure, I have to get it done, why would I write some more code that isnt really "relevant" right now.
I am in a good position right now. I have two working systems and though there is pressure to get this new feature into production I have more time, and I am able to fend off my bosses so long enough to refactor a large chunk of my system.
Conclusion. My code looks a lot nicer. I have implemented the MVC pattern nicely, well considerably better than before. I have reusable objects that have meant creating the two different view layers considerably easier. Small changes to the model in the future will require only making changes in one and not two spots. Its obvious now, but I am glad to see how much I have learned since I started.
So I got it done and now I have got it right. It would have been nice to get it right first time, but they next project will benefit from what I have learned. I will not necessarily get it right but it wont be as wrong as the code that I have just rewritten was.
Edit: This post was written concerning refactoring the offline system. A change was made to the live system recently that used the refactoring of the offline system. The change was smooth and easy because it simply reused previously tested and working components from the offline system. go me!
