ome time ago, I posted a blog entry entitled, “Refactor as you Develop.” I did so because a buddy of mine out in Chicago was stuck in Refactor hell, as he put it. Now, Eric (my buddy’s name) and I share a lot of design ideas and techniques so I know his comment [and term] came from the frustration he was feeling at that moment. However, it was not the first time I heard the term refactor used in a negative connotation so I thought it merited some comments.
It’s very rare that any project ends up exactly as the original design intended, at least from a code perspective. Nowadays, with buzz words swarming our industry like a locust plague, many forget the fundamentals of software development. The eagerness of many developers to have the “perfect” architecture laid out and the proper library of design patterns all set up in the class models has extended the “pre-code” period to an unnecessary length of time
But don’t misunderstand the above paragraph. Architecture and design are extremely important stages of any project. In fact, as a consultant I am sometimes called strictly for the initial architecting in order for another team to then take over the development. Such cases call for more detailed initial work to be done due to my absence afterward. But most projects I do tend to involve me from beginning to end, and indeed those are the ones I enjoy most. I have found that such projects require initial architecting and design but I also tend to push into the coding stage a little sooner rather than later.
Sure I design and lay out my initial object models, but even those typically start out as ORM models corresponding to some database layout. I don’t feel it necessary at this stage to figure out what pattern I need to used and where I will inject it. Nor do I find the need to plan out extreme code reuse from the very beginning. I am a big supporter of object oriented programming and design pattern use, and the end results of my projects show that, but I don’t get this detailed in the very beginning. Such over-architecting delays the time you start putting code together, and chances are you’re going to wind up changing the design anyway. It can also bloat your design to a point of complexity that can further delay the start of the coding cycle. I’m not trying to lay out the model for agile development because, in fact, there are some points of Agile or Extreme programming that I am not a fan of (pair-programming comes to mind); nor am I saying that you don’t need to have any idea of what your app is going to need?that would be ridiculous on my part. I’m just raising the altitude from where I see a project at the beginning from 1,000 feet to 10,000 feet.
|
I’m not recommending that you develop an entire application then go back and look at what you can change; that would be the other extreme. I’m talking about a constant looking-back at the code you’ve written at several “milestone” levels, usually points of functional achievement. There’s nothing wrong with writing a couple of classes in your model, then later noticing that they share a lot of code which you should not have to maintain twice. You can then refactor that code into a base class. You could repeat his simple refactor many times throughout the development of your project where your end result would be a nicely laid out object model with inheritance hierarchies that have grown throughout your development as the need has arisen. You can apply this simple example to Windows form visual inheritance, as well as the application of any pattern.
Programming using concreteness initially, then refactoring to abstractions, can get you started faster, get you to your goal faster, and achieve all of this while maintaining my favorite pattern of all, consistent throughout the project?the K.I.S.S. pattern. (I’ll let you look that one up.)
