How to stay in control of your code and save your sanity

When was the last time you found yourself working on a file containing 7,000+ lines of code?

I’m doing exactly that at this very moment. I’m refactoring some functionality from a legacy project along with writing this article.

Trust me, this sucks.

Unfortunately, this is a reality for tons of developers—projects grow out of control for various reasons or a particular change might not fit the current process or become ineffective in the long run.

These situations often lead to developers implementing temporary solutions to keep things running. There’s nothing wrong with that. The problem is aggravated when these solutions get reused in different functionalities.

Reusing a solution without understanding the conditions under which it was developed and what problem it was solving only increases your technical debt.

What is technical debt?

My favorite definition of technical debt is that it is a set of intentional trade-offs made during various development stages of an application.

But what does it mean?

When creating a new product, important decisions must happen at every stage. Each decision holds a particular weight that affects the development process. Trade-offs must occur.

Do we sacrifice coding standards so we can ship faster? How do we create this feature without over-engineering? The product doesn’t need a complete architecture right now, but we’re going to have to improve it later on.

As we make more decisions, these trade-offs start to impact the development process. Maintenance problems arise and new features aren’t shipped as fast as they used to be.

This is the moment where motivation goes down the drain.

I’ve worked on projects in the past based on the following premise:

“We’re going to switch to a different technology and everything will get discarded. For now, as long as it works, don’t worry too much about coding standards.”

If that doesn’t sound too bad for you, let’s look at it from a different angle:

Why refactor?

When to refactor your codebase

When to resist the urge to refactor

Conclusion