2 Making code small

Complex code is harder to read and understand than simple code. As a developer, you’ve likely experienced the mental strain of deciphering a 200-line method compared to a 20-line method. You feel tired even before you begin to read it. Highly complex code is also more prone to bugs. It’s easier to make mistakes in code that’s difficult to grasp. It’s also hard to write tests for complex code, as it has too many possibilities and corner cases to explore, and it’s too easy to forget one of them.

Making code simple and small is the first thing you should always consider. Even with a well-designed software system, it’s easy to lose sight of code complexity. Lines of code tend to become overgrown if we don’t actively work to prevent it, leading to oversized classes. Long classes and methods happen more often and more naturally than we like to admit. It’s too easy to open an existing class in the system and add more code instead of reflecting on the impact of these new lines and redesigning the code.

The gist of this chapter is that small code is easier to maintain. In the following sections, I’ll dive into patterns to help you make your code small.

2.1 Make units of code small

2.1.1 Break complex methods into private methods

2.1.2 Move a complex unit of code to another class

2.1.3 When not to divide code into small units

2.1.4 Get a helicopter view of the refactoring before you do it

2.1.5 Example: Importing employees

2.2 Make code readable and documented

2.2.1 Keep looking for good names

2.2.2 Document decisions

2.2.3 Add code comments

2.2.4 Example: Deciding when to send an update email

2.3 Move new complexity away from existing classes

2.3.1 Give the complex business logic a class of its own

2.3.2 Break down large business flows