Chapter 13. Refactoring
This chapter covers
- A drag-and-drop example
- Adding some features
- Contrasting refactoring between OOP and FRP code
In your job as a programmer, you’ll often add a feature or fix a bug by adding extra code to a class or method. As the code gets longer, it can get messier. In this chapter, we’ll illustrate that process by example.
As the Agile software development methodology emphasizes, when you start to smell that “code smell” of untidy code, it’s usually a good idea to refactor the code by breaking the class or method into smaller pieces. This is important because messy code is complex code, and we’ve argued that complexity can compound. We’ve also argued that this should be less of an issue in FRP due to its compositionality, but refactoring is still important. Fortunately, refactoring with FRP is as easy as falling off a log.
If you add extra state and logic to an existing class, this is the question you must ask yourself. Latent problems in code usually manifest when you make modifications. Often, deep in your heart, you’ll hear a little voice calling, “Refactor me!” But do you always listen?
The complexity you added gives you an uneasy feeling. That’s because you know at some point you’ll need to split things up. “It’s only a few small changes,” you reply to yourself. But the longer you put off refactoring, the more work it will eventually be, as you can see in figure 13.1.