How do you go about refactoring the front-end of a large website?

Question

I have a very large website that I need to refactor the front-end of due to maintainabilty concerns and performance issues:

Whats tricky:

• Lots of overcomplicated scripts
• Over-complicated CSS with a whopping filesize
• No selenium tests in place
• No js tests in place
• Back end developers concerned anything breaking
• The site has been live for a while and the client is happy

Tools available:

• Multiple servers for testing versions on
• Continuos integration setup
• Version control

Advice on how I should approach this would be most appreciated.

Answer 1

Well, it seems to me that the main problem you're facing is a lack of exiting JavaScript/Selenium tests. Once you've got those in place, you can start the real work of refactoring, taking small steps - confident that mistakes will be picked up.

Never refactor without having tests in place first.

Answer 2

Well I would start out copying the project to a new workspace and creating a place for your version control. This way your back end developers don't need to be scared anymore. Next I would look at the css files because you can change those and see the difference right away. When you like the css you have then you can go on to the script part.

Here you definitely need tests because else there will certainly be some errors or changes which are not wanted. I personaly would migrate the script in very(!) small junks so you are able to find errors very fast and run tests for every little thing you changed. This will lead to the most persistent outcome in my experience.

Another thing you need to think of is the deployment. I mean there are always some requirements or dependencies (I don't know if that's the case in your problem but you should really check that and work with your back end guys so they can give you some hints where the problems could be).

Answer 3

Some thoughts (after having done also bigger refactorings though more on backend side):

• create a play-branch where you start to "scribble" refactor. there you can see how the refactoring feels. I often find that especially big refactorings are like starting design/programming. You have to get hands on and see how your refactoring target feels like. This also has great to better estimate the overall effort.
• as your client is happy and it is more an investment for future take the incremental approach. Do not do a big-bang refactoring. Try to partition several refactoring areas (e.g. javascript vs. CSS) and also by pages.
• start with the easier refactorings steps. They help to get you "fit" with the harder ones.
• the scm is one of your biggest friends. It is vital to revert quickly and feel safe when refactoring. Even on your refactoring branch for bigger works you can create further "minor-branches" to go on with bigger refactoring steps.
• regression tests are vital. Get tests in place first. 100% test automation is hardly possible, so get one of your QA/Test team-members to help you along the refactoring and regression-test after each bigger refactoring-step. The 'it doesn't work anymore' after 3 months of refactoring would just smash you.
• for more difficult refactorings (hard to test) and flaky code structure do 'pair programming'.
• The fear backend developers not trusting big refactoring is correct, take them serious and ask for help (especially for the regression testing requirements).