Sometimes it can be hard to convince management and/or non-technical people to weigh in on code refactoring. Firstly, the term “refactor” may not be well known outside of the software development circle. Once explained, however, the concept is very intuitive and most would agree that it is something that should be done on a regular basis.
Code refactoring is the term given to the clean-up of existing code to improve its structure and make it easier to be understood by other programmers. The definition from Wikipedia states that refactoring is “any change to a computer program which improves its readability or simplifies its structure without changing its results”. Unfortunately, the audience will be keen to point out the fact that the resulting output from the software has not changed, or there is no (visible) benefit to the customer. Given the already tight schedules and budgets that most development teams face, it’s not surprising to see resistance against spending resources on refactoring code. There are numerous reasons why code refactoring should be a best practice implemented by all software development teams, and a well-formed argument will go a long way to justify refactoring.
Many web-based applications are fixated with the perpetual beta. Companies apply the term “beta” at the end of their product’s name, and in doing so, allows new functionality to be added into the system at anytime without a major release (as well as to limit the liability of bugs in the program). I personally believe that this is the only way to go for web-apps because anyone with an idea and a compiler can and will be a direct competitor for web traffic. And in order to quickly and effortlessly add new functionality into an existing system, code must be easy to read and understand in order to be edited or updated. To constantly introduce requirements without refactoring is similar to playing Jenga. The higher the tower becomes, the longer it will take to remove and place a game piece.
We all know how a game of Jenga ends.
I agree that from time to time, code should be refactored, especially at the core component level. As stated, most timelines for projects are far shorter than proper coding practices can be implemented. However, at the same time, some care should really be taken in providing proper habits (I prefer not to use the term “Best practices”, as history has dictated that “Best Practices” are fluid in nature and have a habit of changing, at minimum, monthly).
Refactoring should not be relied on for proper coding methodology, but rather as a “TODO” item for the long term. What is often seen is that a developer will race through the code without having developed proper planning for objects and sequence/state diagrams (I am completely guilty of this, as are many people who say they aren’t), which ends up with poor/obsolete code right at first release (Beta as this article indicates), with the thought that “Oh. It’ll be fixed up in the refactoring cycle”.
What should happen is that the developer should develop and implement some of the primary habits (”Best Practices”) of designing their objects first, figuring out what has what, what state delegates which method and so on. Once this has been worked out, then start coding with the idea that “This is it!”, and write the most elegant and effecient code they can for the objects/processes. If these criteria are met first, then the developer can be justified down the road in saying that “Hey. I’ve found a better way to do this, let’s refactor it.”, and then place it in the refactoring cycle.
To have a cycle in which all it is is refactoring of old code, simply means that it wasn’t really done properly the first time, and certainly shouldn’t have gone out the way it was. This may seem like timelines won’t be met, but in my experience, proper planning, research and habits up front will make the actual implementation go that much faster, produce better results, and reduce the need for refactoring.
…of course, I may also be just talking out of my a@#….
Comment by Zach Lawrence — March 28, 2007 @ 12:57 pm
In an ideal world, there would be no need for refactoring. As Zach stated, things should be done right the first time, and not simply put off until some later phase. This I completely agree with. Refactoring is not the solution to writing bad code. This is in no way what refactoring was meant to solve. Refactoring is meant to counteract the inevitable ’software entropy’ that all long-term projects face. Any code base should be reviewed to ensure that it is wise to refactor it before moving on.
There are numerous reasons why a codebase would be in a state where it requires refactoring. Perhaps the schedule for a project was slipping and corners had to be cut in order to ship a product, or what was once considered good, clean code no longer satisfies the new requirements. Or the developer was just hung over from a long night of drinking and playing World of Warcraft and just wrote sloppy code the next day. Also, No two developers are the same, and even the same developer last year is not the same as he is now. I myself have looked over old code, said “Who the hell wrote this crap?” only to find out later that it was actually me.
Whatever the case, there are numerous benefits to refactoring. It allows the developers to solidify the code base, clean up inconsistencies, and improve the overall quality of the product without affecting the user output. When done correctly, the end result is a code base that can save time, energy, and debugging headaches in the future. It should be able to support the addition of new features quickly and easily (improved extensibility and scalability), and reduce the amount of maintenance work required.
Another analogy you can use for refactoring (or software development in general) is Gardening. Over time, despite how well you grow your plants and arrange them into neat patterns, you eventually grow weeds. If you don’t stop and pull out these weeds, they will eventually spread and overwhelm your entire garden. The same holds true with any software development project that needs to be refactored.
Comment by Allen K. — March 28, 2007 @ 2:53 pm
Divide movies to several clips
Comment by dudevu Downloader — June 11, 2010 @ 12:23 am