Chapter 5. Breaking up a monolith
This chapter covers
- Getting to modularized code
- Unexplored nodes, decision nodes, and true leaves
- Tests that guide change
The most common questions we hear when we introduce the Mikado Method are, “What if I don’t have any tests and want to refactor safely? Will the Mikado Method solve my problem?” We believe that these questions are somewhat misguided. The real question you should be asking yourself is, “At what point do I need to know if my changes broke anything?”
If the answer is, “immediately,” then you need something (like automated tests) to validate that quickly. If you intend to wait and let your customers alert you to any problems, the answer is, “pretty late on.” If you have a huge QA department, your answer might be, “during the test phase.” If you asked us, we’d say, “as soon as possible.” We believe in fast feedback, and the faster it is, the better it is. One way to get fast feedback is from tests. We want the majority of our tests to be automated and preferably to be very fast. This opens up the possibility for instant feedback, and that lays the groundwork for flexibility.