About this Book
As a codebase grows large and more complicated, and they often do, there usually comes a time when you want to improve portions of it to meet new functional requirements, new legal requirements, or a new business model. You may also just want to change it to make it more comprehensible. For small changes, you can keep things straight in your head, but for larger ones the chances of getting lost on a sea of broken code increases dramatically.
As you desperately try to navigate that sea, it’s easy to start labeling the code. You can come up with all sorts of names for the code, especially bad code that isn’t fit for its purpose. Legacy code is one of the more popular terms, which literally means code someone (else) wrote and that you are now responsible for. Michael Feathers, in Working Effectively with Legacy Code (Prentice Hall, 2004), suggested it can be defined as code without tests, which has since become the de facto definition.
Another term for bad code is big ball of mud, popularized by Brian Foote and Joseph Yoder in their paper Big Ball of Mud (http://laputan.org/mud/). This paper describes a big ball of mud as “a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle.” Some synonyms for this type of code are crap or a mess, and we can think of quite a few more in our native language (Swedish).
When code like that needs to change and trouble appears, it’s easy to label the code legacy, a big ball of mud, a mess, crap, or just impossible to work with. If it’s really bad, developers often distance ourselves from the code and start lobbying for a rewrite, because changing the code is perceived as too hard.
In addition to the big-ball-of-mud systems, there are at least two more types of systems that need attention. First, there are systems that look well organized, maybe even having high test coverage, but under the surface they’re hard to work with or to extend. Second are the systems that look good and have served well, but don’t anymore.
This book is about changing and improving all these types of systems. It offers a way to regain control over your codebase. We call it the Mikado Method.
Roadmap
Chapter 1 is an introduction to the Mikado Method. After reading this chapter, you’ll understand how the method works at a high level. For some people, this will be enough to start experimenting on their own problems.
Chapter 2 shows the mechanics of the method with the use of two small examples. This chapter explains how to use the method when working with code.
Chapter 3 goes into the theory of the method in depth. After reading this chapter, you’ll know the nuts and bolts of the method, and understand why and how it works.
Chapter 4 is a guide that shows how you can use the method in different working constellations, and when to start using the method on a problem. After reading this chapter, you’ll understand how to get the most out of the method in a team, a pair, or on your own.
Chapter 5 presents a longer example that mimics a somewhat real scenario. This chapter will show you how to include tests and how to deal with monolithic code, a common problem for many software developers.
Chapter 6 is about emergent design and the design principles we use when we want to change a system for the better. After reading this chapter, you’ll know which direction to take your code in when you change it.
Chapter 7 presents some recurring patterns we’ve come across when we use the method—patterns related to both drawing graphs and implementing changes. This chapter will give you ideas about how to simplify your graphs and how to go about tricky, but common, changes to code.
Appendix A is a deep dive into the concept of technical debt. This appendix will help you recognize the different types and sources of technical debt, and mitigate those at an early stage.
Appendix B is about setting the stage for an improvement effort. This appendix outlines the most common preparations needed before heading out on an improvement effort. You’ll also get some tips on what to do afterward, to sustain the improvements you’ve made.
Appendix C contains an example in JavaScript that shows how you can use the Mikado Method to approach changes in an environment that uses a dynamically typed language.
The code in the book
The code from the longer examples in the book is available at GitHub at the links shown in this section. It is also available as a download from the publisher’s website at www.manning.com/TheMikadoMethod.
You will find the code from chapter 2 at https://github.com/mikadomethod/book-example-1. In the branches of that repository, you can find the detailed steps of the two examples in that chapter.
The example in chapter 5 is available at https://github.com/mikadomethod/book-example-2. For this example, there’s one branch for each graph in the chapter, with the names of the branches mapping to the goals of the graphs, respectively. The prerequisites are mostly mapped to a commit, and in some cases a couple of prerequisites are bundled in a commit.
The example in appendix C is available at https://github.com/mikadomethod/book-example-3. This example also contains detailed branches for the steps in the book.
The graphics in the book
We prefer and recommend using hand-drawn graphs and diagrams for work, but for clarity (and to save you from our handwriting), we’ve used a couple of tools to make the graphics in this book.
Most of the UML diagrams in the book are drawn using Inkscape (http://inkscape.org). The Mikado Graphs were mostly generated using Graphviz (http://graphviz.org), and sometimes drawn using Inkscape. The resulting graphics have been touched up by the Manning production team. The cartoons were drawn by Martin Murtonen of the Manning team, based on originals by Ola Ellnestam.
The font used in the graphics is Architects Daughter, a beautiful font created by Kimberly Geswein (http://www.kimberlygeswein.com). The font is free if you download it from http://www.fontsquirrel.com/fonts/architects-daughter.
Author Online
The purchase of The Mikado Method includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the authors and other users. To access the forum and subscribe to it, visit http://www.manning.com/TheMikadoMethod. This page provides information on how to get on the forum once you’re registered, what kind of help is available, and the rules of conduct on the forum.
Manning’s commitment to readers is to provide a venue for meaningful dialogue between individual readers and between readers and the authors. It is not a commitment to any specific amount of participation on the part of the authors, whose contribution to the forum remains voluntary (and unpaid). Let your voice be heard and keep the authors on their toes!
The Author Online forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.