During my day job, I had a case where I needed to use some pattern matching to do some type checking. If you don’t know, pattern matching in C# allows you to test the type of an object and perform some additional “magic” at the same time. While having the chance to play around with this feature some questions arose from my usage.
As a software developer, it’s important to know what tools are available to you. Tedious and repetitive tasks or large “one-off” time-consuming tasks can often be automated by third-party tooling. And yes – sometimes it’s even worth purchasing some of these tools with your own money. Specifically, when refactoring, we should have some knowledge of what refactoring tools are available to us.
Continuing my “Refactoring Legacy Monoliths” series – I want to go over a few tools that I’ve found super helpful and worth investing in.
To make this blog post more useful than a list of products, I’ll go through some high-level steps of a plan that you might also find helpful when tackling a major refactoring expedition on a large project, and highlight some of these tools along the way. 🙂
I really did make LINQ 6X faster! Even though the title is “click-bait-ish”… This was a little experiment to see if I could speed up LINQ queries by using the functional
pipe technique. By “piping” LINQ queries, we can avoid the inherent issue with LINQ whereby each query will issue a whole iteration over the collection. This optimization allows us to issue the equivalent of one iteration and pass each element through the entire method chain.
So your engineering team is convinced that you need to make some drastic changes. The direction of future development needs to improve. Things can’t stay as they are. Management is also convinced that the product needs to move in a new direction. What’s next? Well, before doing any actual changes or refactoring to your product, planning a refactor is your next step. In other words, you need a game plan. I’ll also discuss some refactoring tips for you to get started!
How do you convince management to invest time and money into refactoring your legacy monolith? Convincing management that benefits of refactoring are worthwhile can be a stopping point for many. It’s your job to provide a cost-benefit analysis of refactoring your legacy monolith and convince your team that this makes sense.
Btw, this is a sequel to my previous post on this topic where I discussed a starting point when facing this topic:
- Code that can be tested (at all!)
- And… have tests
- Business logic separated from your presentational logic
- Stop wasting time building code that is already available in stable/tested 3rd party libraries
Let’s look at overcoming the next hurdle in this process.
Where do you even begin when considering “fixing” or refactoring legacy monoliths? I’ve been thinking about this lately – as I’ve been doing it for the last month or so.