Skip to main content

5 Tips For Refactoring In Brownfield Land

1. Don't try and refactor on the branch / clone you are working on

Whilst doing some of the everyday work, I couldn't help breaking into a refactor mission the problem is that refactor missions always take you down deeper than expected. You still need to get the other jobs done and other bugs may come up too. This has caught me out so many times when I just think I will do a little fix here or there. Be patient, you don't need to do the re-factor straight away.

2. Plan the refactor with clear objectives

Ugh, another of my favourites. When starting my current refactoring mission, I was like an ape in the produce section of Asda. My code was highlighted in blue Resharper squiggles and I could see duplication everywhere. Now I have calmed down and grown a little wiser. I have begun making a list of objectives and sections that I plan to refactor. Make a list of what each section of code does, if you have an appropriate tool that you can tag it with then do that. You can then approach sections together like "Front end refactoring" you could also make estimates on how long it could take. For example the list could be like:

  • Making a note of functionality so it can be rearranged and grouped together.
  • Removing in-line CSS from elements.
  • Refactoring JavaScript on pages.
  • Extracting interfaces on service or task classes then implementing an IoC Container.

 

3. Write tests around the functionality. Make sure you aren't breaking things.

This can be hard unless you do some of the refactoring first. Once you have extracted some of the external classes to interfaces and you can squirt test cases in, you can start testing the real behaviour of the class and how it should react. Document this correctly and give the test behavioural names like;

Namespace: GivenAnApartmentsRentIsDue

Class: WhenTheReminderIsSent

Method: ThenTheCorrectReminderDateIsSet

Method: TheCorrectAddressIsSet

When you have a lot of behaviour tests, providing you have grouped your tests together well, you really get a feel for the functionality of the system.

4. Don't moan about the code that's there. It will annoy the people you are working with.

Yes the code is crap, yes you are busy because every job takes 10 times longer than it should and only Ming the Merciless himself would devise such a cruel way retrieve users from the database. But you have been that person before; normally things get muddy because of a mixture of uncertainty, lack of details, and lack of time, no training and money. There are all sorts of reasons, but if you moan all the time about them you will just annoy / alienate people and it creates a crappy negative feeling in the team.

5. Create a baseline of functionality and performance before you refactor.

Users get really angry if you make things worse. It only takes one or two users to notice poor performance and the word will spread. It can really shake confidence in your software. If needs be and the changes are big enough (especially if there are front end usability changes), create an acceptance site for users to try out and ensure that the interactions on it are logged (anonymously perhaps) so that you can get an idea if people really have tried it out.

Summary

Hope that helps / confirms what you already know :-)

Comments

Popular posts from this blog

Motorola MC65

We have a new PDA in town now. As a replacement for the army of MC9000 and MC70s that are in the field and are being discontinued, we now are moving up to the Motorola MC65. I have had the new handheld for about a week now and have been impressed so far. It's a great improvement over the MC70. I have no idea how the numbering system of the Symbol / Motorola devices works. I assume there must be several ranges such as the 50s 60s and 70s.? Anyway the?PDA?has windows mobile 6.5.3, a better touch screen and is faster. Much faster. The skin that has been put on the OS has also applied to our software and I think it makes it look much cooler. We had several problems in adjusting our software so it would work with the new MC65. First was the change in resolution. The MC70 has a much lower resolution than the MC65s and as some of our screens were not using the auto scale settings in the form and some of the buttons on our forms were created at run time rather than design time, this posed

Accessing the UI Thread with Tasks in F#

I have a Windows Forms program written in F# that can deploy a code base to n number of sites at once (you select the sites you would like to deploy to and it goes off and completes a number of tasks (backing up current sites, various unpacking and moving of files etc... ). Once you start it, it begins it's merry journey and begins to update the UI with what has happened. At the moment this method of updating the UI is not pretty because the threads I am doing the work on can't update the UI so I perform some fiendery to make that happen (don't ask). I knew there was a better way using some newer .NET features but I just hadn't got round to having a fiddle yet. I have now found that if you use the built in Task class but break your code up in a nicer way and then chain the tasks together you can then pass the correct context into the task that you want to talk to the UI. Here's a little script to give you a feel for it. You can press the "start" butt

Cab Control

Received another call today from a company interested in my  Cab Control Software . Basically it's taxi management . The software needs a re-write to get it from Windows Forms onto the web. I have great hopes for the software. It really just needs to time and ingenuity pouring into it. I have loads of ideas for it but just have so little time.  It currently has this functionality which I'll need to get across:  Add drivers and Taxis and keep track of their contact details, addresses, licence details, CRB checks and eligibility to work in the UK. Basic account management functions, such as creating a customer account and putting the account on hold.  Add Bookings for drivers and customers Creating reports for customer accounts that could be exported as a CSV file for billing purposes.  Creating reports for drivers to know how many pickups the drivers had made. Query the bookings for enquiries and police check up reports. Provide management tools to check MOT and Service details