DEV Community

loading...

Discussion on: Refactoring Legacy Monoliths - Part 1: First Steps

Collapse
bosepchuk profile image
Blaine Osepchuk • Edited

Great post, James.

I've gone through this a couple of times and in my experience there are a few steps that help "prepare the code" for the changes you are suggesting such as:

  • Making sure the entire project is under modern version control
  • Running the entire project through a code formatter
  • Delete dead and commented-out code
  • Delete unused features
  • Run a bunch of static analysis tools on the code to get a feel for the magnitude of the problem
  • Run the existing tests with coverage and see where that's at
  • Identify and fix any emergency issues (update libraries to fix security vulnerabilities, or update the code to run on a newer version of the language if the currently used version is no longer supported, fix obvious and serious security vulnerabilities in your code)
  • Flag suspicious code with TODO or FIXME contents for further inspection at a future date

If you do these steps, I guarantee you'll find things that shock and surprise you and that you'll be able to delete quite a bit of code (about 10% of the project in my limited experience).

There's a really good book called Modernizing Legacy Applications in PHP, which I highly recommend if PHP is your language.

After that you have some options. I'm not exactly sure where James is going to go next but I'm sure he'll have good advice.

We use tons of the "extract method" and "extract class" refactorings to break out pieces of testable code from dependencies using the humble object pattern. We also break dependencies by using dependency injection. Classes and methods in legacy code are often too big and are doing too many things. So our first priority is usually to break things up and test what we can.

But there are a number of reasonable ways forward from here depending on your priorities.

Collapse
jamesmh profile image
James Hickey Author

Love it! Should turn this into a blog post altogether ;)

I'll have to repeat much of what you said as the series continues. I think one of the main issues that need to be tackled is the direction of dependencies and (as you mentioned in much more detail) how to break things apart in a way that will isolate dependencies. This leads to being able to test individual parts in an isolated fashion.

But I'm just repeating what you've said :)

I appreciate the additions - I'm sure this will be super helpful to anyone who's interested in this topic.