Sugendran Ganess: Refactoring legacy code

Sugendran Ganess (@sugendran) was talking about refactoring legacy code at Scotland.js, these are my notes from his talk.

We've been making Ajax requests for 15 years.  We have websites that are running 10 year old code - that code works and people are reluctant to change it.  However, new tools make our lives easier and we want to use them.

Coming into a team there is typically a big learning curve as you learn a large codebase, you need to recognise this.  We chose backbone as people are familiar with it, steadily moving things over to backbone.  

Don't forget that past decisions were made for a good reasons - the people who made these decisions are the reason you are employed right now.

A rewrite is very dependent on time to ship - everything else has to wait for it.  If you rewrite you might lose several years of incremental knowledge that is baked into the old system.

Don't work alone, on our own we don't have all the answers.  Having someone who is as stubborn as you is important - keeps you honest.

Take time to understand the domain, not everything is documented.  Time spent not programming pays off.  Limit the scope to you can ship but don't do this until after you have done the research.  Talk to the rest of the team to work out what they think are the problems with what you're working on, if you make their life worse then they'll hate you - make sure you keep lines of communication open.

Release early, release often  Get work into master as fast as possible and use feature gates - gets your code to your team fast but holds it back from your users.  This was important as there were three features working in parallel, would have been a mega merge if they only landed after they finished.

Tests give you confidence.  Fork the tests so that both old and new tests can live side by side.  Old tests can identify if your new code is leaking.  If there are no tests for the legacy code then add them - every time you touch old code then write a test for it.  Istanbul is a useful tool that gives you code coverage - you're not going to get perfect test coverage up front but work on it.

Think about how you want people to interact with your API.  Hack up different approaches.  Plato.js will track complexity - indicator of how maintable your code will be: number of paths through your code.

Don't let the scope creep - you need to ship.  The longer you spend the less benefit you get.  You want feedback ASAP.  Avoid the long tail of bugs, if you are in master early and behind a feature gate then you can catch these early without affecting all your users.  Use non-technical people in your company.

If you left things out of scope then document them - they'll be useful to people who have to work on the code after you.