// Lead // Track when a user expresses interest in your offering (ex. form submission, sign up for trial, landing on pricing page) fbq('track', 'Lead'); // CompleteRegistration // Track when a registration form is completed (ex. complete subscription, sign up for a service) fbq('track', 'CompleteRegistration');

Refactoring - to do or not to do

by Garry Viner
in UX & Web Development
Garry Viner

Every developer dreams of having the perfect code base. Code that is at all times simple, re-usable, well-documented, and most importantly, working. Every developer also knows that this is unachievable. No matter how well-planned, code will always be written that is not perfect.  This is not because programmers are not good at what they do, but rather because

  • Bugs may exist in the code, and patches introduced quickly to fix them.
  • Existing code may no longer be optimal due to changes in functionality requirements.
  • A rapid increase in site users means previously well-written code no longer performs well.
  • Even the definition of what constitutes optimal code may differ between team members who code differently.

In cases where old code no longer does the job it was originally written to do, there is no choice but to rewrite it. During one of our development cycles , new functionality will compete with bug fixes and rewrites of code that is past its use-by-date.

However for code that still does the job, but is less than perfect, the issue is less clear. Generally development teams will devote time to refactoring some proportion of the code base, but how much and how to go about it depends on many competing factors. Here I intend to list some of the pros and cons of refactoring as I see it.

Pros of refactoring a website design:

1. Re-usability

Part of refactoring a website design involves taking what are often large and cumbersome procedures and breaking them up into smaller components. These then can be called from other parts of the application, meaning less code duplication.

2. Performance

Refactoring often involves looking at the way the code is run and seeing if it can be done in a more efficient way. This might involve rewriting queries that are not optimal, tuning queries where indexes no longer work as well as they did, or changing the logical flow of the code.

 3. Simplicity

Code, particularly that of another developer, should be easier to follow if it is in bite-sized chunks and well-documented.  For a new team member, especially, large files full of poorly-maintained code can be overwhelming.

4. Ease of making changes

Because code is more modular, subsequent functionality changes involve updating less code.

5. Satisfaction

You can’t be a developer and not be a bit obsessive. I know that I feel a real sense of satisfaction when I’ve taken an unwieldy block of code and reduced it to something manageable.

Cons of refactoring a website design:

1. Time

Refactoring is a complex process and takes time. When planning a development cycle, you have to find the trade-off between the immediate bang for your buck you get from  some cool new functionality ,and the longer term gains of some massively less sexy refactoring.

 2. Difficulty

In a large and complex application like ours, it is by no means obvious in many cases exactly what a particular block of code is supposed to do. Perhaps it is clear when called in some cases, but there may be other less intuitive things happening under the covers, particularly when refactoring someone else’s code. Code may have been written many moons ago and the logic behind much of it may be hard to ascertain.

3. Scale

How much to refactor can be an issue. You might see a procedure that could do with refactoring.  Ideally you would handle it in increments. In reality, what starts off as an intended small rewrite soon develops a life of its own. It’s not uncommon to regret following the path you have chosen as the magnitude of the work hits you.

4. Testing

Not only will the developers have to find the extra time to refactor, but so will the testers. And while it is often clear to a tester how to test new functionality and bug fixes, this is not the case for refactored code.

5. Risk

Refactoring is not generally done on code that does not work. It is done on working code in an attempt to keep the foundations of your application from getting too shaky. Taking code that works and rewriting it introduces risks.

In summary, refactoring is an important part of the website development cycle if you want to plan for the future. Agreeing with the business analysts on the right proportion of time to spend on this is difficult, and there are pitfalls to be mindful of when embarking on a refactoring project.

More Information About Website Design & Development

Please let me know if you found this post interesting in the comment section below. I welcome feedback and the opinions of others. The Web Showroom is only one of many companies focused on website design in Sydney. However, I am of course slightly biased and therefore do consider ourselves one of the top firms. Feel free to also peruse my other posts to gain further insights on website development and to learn more about our Sydney based company.

Revised: 09/06/2012

Author: Garry Viner

Garry Viner is the Director of Development and one of the founders of The Web Showroom. He has worked in IT since 1995 and has focussed on web since 1999.

At The Web Showroom he is still actively engaged in his first love, which is writing the code and creating the database objects that power virtually every web design created at TWS. When he feels like sharing, he also allows his other developers to contribute.

Garry is committed to keeping Mission Control at the forefront of hosted CMS’s in Australia, ensuring your business has the platform to reach all its online goals.

Garry Viner
Preloaded imagePreloaded image