Refactoring tools and their underlying algorithms have come a long way and are reasonably battle-tested. However, there may be a situation that you run into where the refactoring action cannot complete the intended transformation. A little nudge from the type-system can go a long way in such scenarios.

In the traditional sense, writing tests can often be difficult for many developers, especially for code authored by someone else. Nevertheless, it's the most reliable way to build and evolve the behavior of our systems.

One of the factors that could help people contribute to a codebase sooner depends on how well they know the codebase and the product. I would argue that good developers not only have strong technical skills but also the curiosity to understand the business they are in.

One of my favorite parts about software engineering is that there is no end to the list of things that you can try. Some ideas are wild, and surprisingly they work. I recently worked on a piece of code that I had to refactor. The code smell I addressed was refused bequest with a bloated interface; several classes in the codebase implemented an interface.

When you get used to refactoring with tests, one common pitfall people sometimes fall into is stopping writing tests and starting refactoring after they attain 100% code coverage. Code coverage can be a helpful metric under specific contexts and scales; refactoring is one.

We could almost agree that automated testing is the next best thing that happened to humanity since sliced bread. I won't evangelize testing in this blog post, but I aim to offer a word of caution about mitigating risks, particularly when you want to refactor code without the safety net of tests.

Large classes are a result of the "one more thing" problem. You have a perfect class that does one thing, and your users like it. However, they want it to do one other thing and another and then another. Before we realise it, the class becomes responsible for many different things.

The textual format is our primary way of interacting with source code, which is usually fine. However, things can become hard to grasp when you have source code that does not fit within a few mouse scrolls. That's because we are overwhelmed with information that exceeds human cognitive limits.

Most projects have humble beginnings. They usually start with a single module, and as they deliver more value to their users, they grow and become more complex. If the project is successful, the development teams that maintain these projects may break the single module into several smaller modules or create new ones to make the project maintainable, reusable, and in some cases—independently deployable.

The sheer amount of information, implementation details, and non-linear nature of source code require an alternative representation to grasp effectively. The interactive edge bundling graph in Eureka is the most successful alternative representation of source code we've experimented with in the past few years.

Whether it's examining someone else's code or revisiting our own past work, deciphering code can leave us feeling perplexed and inadequate. However, there are various approaches and techniques that can help developers gain a deeper understanding of source code and overcome these obstacles.

Large classes can be challenging to understand and maintain. They may be riddled with poor-quality code because what's one more broken window when the entire class has many of them? It accrues technical debt because large classes often keep growing unless someone cares to do something about it.