"We don’t have the time to waste on cleaning up the code. We have to get this feature implemented now!" Have you ever heard such a comment? Have you ever made such a comment? Chances are that you probably have both heard and made the comment! Well this is probably one of the most common objections to Refactoring as it is explained in the book Refactoring HTML by Elliotte Rusty Harold and summarized in the following series of posts: The Cafes » Objections to Refactoring.
But let's start from the beginning. What is a Refactor? As stated on Wikipedia, in software engineering, "refactoring" a source code module often means modifying without changing its external behavior, and is sometimes informally referred to as "cleaning it up". A refactor is a source code transformation that does not alter the behavior of the program. Historically refactorings have been applied to make the code more maintainable and have been almost within the exclusive realm of sophisticated programmers. In recent years IDEs like Visual Studio.NET have started to support refactoring and the term is starting to become part of the standard programmers language. However, the concept of a refactoring has only been applied to small localized changes in the source code. Changes that somewhat improve code maintainability or that perform some modification in an automated manner that help the programmer increase its productivity while editing code. Of course refactorings are a good thing, and in general if you can improve the maintainability of your code you should, specially when you know that your code has to continue to evolve.
When we were designing Aggiorno the first way of referring to what Aggiorno would do was: "Refactoring for the Web". However, we soon realized that even if Aggiornings are similar to refectorings in the sense that they perform transformations on code they are different in their purpose and this is why we coined the name.
Aggiornings are a form of encapsulated knowledge aimed at providing business value as directly as possible. For instance, an aggiorning will help you make your page XHTML compliant (web standards). And we already know from previous posts that making a page standard helps you with SEO, accessibility, maintainability, etc. Another scenario where aggiornings help is when you want to separate content from style. The immediate business benefit is that maintainability costs go down, but also, it is much easier to port the code to mobile browsers and it is also easier for google to index your page and not get confused by cluttered markup. Aggiornings might or might not preserve equivalence in the code they transform (refactorings always do) and even if we preserve equivalence when it makes sense to do so, we also make other changes that produce a big return on investment even if they do not preserve equivalence. Another big difference about aggiornings is that the user can always request an explanation and aggiorno will show exactly where the changes happened so the user can ultimately decide if he wants to go trough with them or not.
Going back to the title of this post, source code improvements that are aimed at improving maintainability are in general a very good thing to do. If you look at refactorings from the perspective of aggiornings the code improvements are even more important. We are talking about improvements whose ROI can immediately be measured from the business perspective. There really should be no objections to using refactoring techniques or aggiornings on your code. If you have an objection, let me know!
ahh... and let me encourage you to download aggiorno Beta and explore aggiornings for yourself.
