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

My home office upgrade wish list.

My home office is almost due an upgrade. I have been holding off until my youngest daughter is out of her cot as then we can finally dispatch the enormous monstrosity of a cot out from the kids bedroom and the drawers that are in my office can be banished giving me better access to my wonderful whiteboard. My other improvements will be purchasing a new, larger monitor. I currently work from a single 22ich Samsung which just doesn't cut it anymore, I did have two at some point but I can't recall what I did with it. I really enjoy using a touch screen so I think I will go for one of these 27inch Hannspree models that I have used before. I put a lot of hours in at home and whilst I have a reasonable chair I still tend to suffer with some back problems, so my next port of call will be to get a Varidesk for home. It works an absolute treat at work and just lets me switch stuff up when I feel like it. they take a reasonable amount of desk space up but I tend to leave my desk fairly

Making your domain less mutable

This happens regularly to me (and from my anecdotal investigation everyone involved in large / old projects). We need a new piece of functionality. I write it, it's beautiful and I win the internet. I have estimated 8 days (or 22.23 lol-points depending on how you live) and it's only taken 4 days. Ah, but then a very small; mostly ignored and very unimportant detail rears it's cruel head. You need to make it work with the code that exists already. This is normally in the form of saving to some pre-existing entities. Oh dear. You save everything through the various management / service classes that exist already and nothing works. So begins the next couple of days of horror. You find that you didn't set the work = true . Most of my woes in this area are caused by modifications at layer further down (or the stored procedure it finally ends up in) changing the object that I was trying to save or not saving part of the object because of some rule. So many errors

Creating star ratings in HTML and Javascript

I'd searched around a little for some shortcuts to help in doing this but I couldn't find anything satisfactory that included the ability to pull the rating off again for saving. I'd ended up coming up with this rather cheeky solution. Hopefully it helps you too! This is my first post in a while (I stopped blogging properly about 8 years ago!) It's strange coming back to it. Blogger feels very crusty and old by todays standards too.