Table of Contents

Copyright

Brief Table of Contents

Table of Contents

Foreword

Preface

Acknowledgments

About this Book

About the Cover Illustration

About the Authors

1. The basics of the Mikado Method

Chapter 1. Meet the Mikado Method

1.1. What is the Mikado Method?

1.1.1. Basic concepts

1.1.2. When to use the Mikado Method

1.1.3. Benefits of the method

1.2. The Mikado Method recipe

1.2.1. How to work with the Mikado Method

1.3. Summary

Chapter 2. Hello, Mikado Method!

2.1. Your first Mikado Graph

2.1.1. Making changes without breaking code

2.2. A slightly more complicated change

2.2.1. Getting to know the code

2.2.2. Reverting code

2.3. Making the code configurable

2.3.1. Get going with the Naive Approach

2.3.2. Revert when there are errors

2.3.3. Select the next prerequisite

2.3.4. Create an interface

2.3.5. Restart from the goal

2.4. Summary

Chapter 3. Goals, graphs, and guidelines

3.1. The Mikado Method guidelines

3.1.1. Always start with the goal

3.1.2. Use experiments

3.1.3. Revert—the key to safe refactorings

3.1.4. Focus on the leaves

3.2. The Mikado Graph

3.2.1. The goal—business or technical?

3.2.2. The prerequisites

3.2.3. Prerequisite—step or decision?

3.2.4. How big should a step be?

3.2.5. More about the leaves

3.2.6. The dependency arrows

3.2.7. The check marks

3.3. Tips for using the Mikado Method

3.3.1. Focus on the goal

3.3.2. Follow the flow of the code

3.3.3. Keep it simple

3.3.4. Keep it visible

3.3.5. Iterate, increment, and evolve

3.3.6. Remember the state

3.3.7. Reflect on your work

3.4. Relation to other thinking models

3.4.1. Theory of Constraints

3.4.2. Empirical control systems

3.4.3. Pull systems

3.5. Summary

Chapter 4. Organizing your work

4.1. The scope of a change

4.1.1. Changes at different scales

4.1.2. When do I start drawing my graph?

4.2. How to approach a change

4.2.1. Working in different constellations

4.2.2. Where to put the focus in a team

4.2.3. Pain points when working as a team

4.3. Summary

2. Principles and patterns for improving software

Chapter 5. Breaking up a monolith

5.1. The code of an online loan institute

5.1.1. The existing functionality

5.1.2. The architecture and the code

5.2. Beheading the beast

5.2.1. Set a goal

5.2.2. Create an abstraction

5.2.3. More LoanRepository duties

5.2.4. Back to the business goal

5.2.5. Update the graph

5.2.6. Revert and restart from a clean slate

5.3. Getting to the true leaves of the graph

5.3.1. The first steps on the way back

5.3.2. Side effect–free programming

5.4. Summary

Chapter 6. Emergent design

6.1. Designing classes

6.1.1. Code that does too many things

6.1.2. Code that isn’t stable in the face of change

6.1.3. Code that violates its contract

6.1.4. Bulky interfaces

6.1.5. Code with rigid call-dependency chains

6.2. Designing packages

6.2.1. What to put in a package

6.2.2. Dependencies between packages

6.3. Summary

Chapter 7. Common restructuring patterns

7.1. Graph patterns

7.1.1. Group common prerequisites in a grouping node

7.1.2. Extract preparatory prerequisites

7.1.3. Group a repeated set of prerequisites as a templated change

7.1.4. Graph concurrent goals with common prerequisites together

7.1.5. Split the graph

7.1.6. Explore options

7.2. Scattered-code patterns

7.2.1. Merge, reorganize, split

7.2.2. Move code directly to a new package

7.2.3. Move code gradually to a new package

7.2.4. Create an API

7.2.5. Use a temporary shelter

7.3. Code tricks

7.3.1. Update all references to a field or method

7.3.2. Freeze a partition

7.3.3. Develop a mimic replacement

7.3.4. Replace configuration with code

7.4. Summary

Appendix A. Technical debt

A.1. How you get into debt

A.1.1. Acceptable debt builders

A.1.2. Unavoidable debt builders

A.1.3. Unnecessary debt builders

A.1.4. Bad debt builders

A.2. More about technical debt

A.2.1. Lactic acid

A.2.2. What is the interest?

A.3. Influence and type

A.3.1. Third party—technical and imposed

A.3.2. Bigwig—market and imposed

A.3.3. The boardroom—market and incurred

A.3.4. Propeller hat—technical and incurred

A.3.5. Borderliners

A.4. Attacking the technical debt source

A.4.1. Get to the bottom of the problem

A.4.2. Third party—create defensible space

A.4.3. Bigwig—probe and prepare

A.4.4. The boardroom—talk and learn

A.4.5. Propeller hat—form an opinion and align

A.5. The way out of technical debt

A.6. Summary

Appendix B. Setting the stage for improvements

B.1. Before your restructuring

B.1.1. Shorten your feedback cycles

B.1.2. Use a version control system

B.1.3. Use automated refactorings

B.1.4. Use one workspace

B.1.5. Use one repository

B.1.6. Merge frequently with the main branch

B.1.7. Scripting languages to the rescue

B.1.8. Use the best tools

B.1.9. Buy the books

B.1.10. Know the dynamic code

B.1.11. Consistency first, then improvements

B.1.12. Learn to use regular expressions

B.1.13. Remove unused code

B.1.14. Prepare yourself mentally

B.1.15. Prepare others

B.1.16. Measure code problems

B.1.17. Hire a critical mass of change agents

B.1.18. Encourage collective code ownership

B.2. During the restructuring

B.2.1. All things are relative

B.2.2. Be aware of the code

B.2.3. Create an opinion about what good code looks like

B.2.4. The road to better often runs through worse

B.2.5. Code of conduct

B.2.6. Find the ubiquitous language

B.2.7. Pay attention to your gut feelings

B.3. When the crisis is over

B.3.1. Refactor relentlessly

B.3.2. Design never stops

B.3.3. You ain’t gonna need it—YAGNI

B.3.4. Red-green-refactor

B.3.5. Continue using the Mikado Method

B.4. Summary

Appendix C. Dealing with dynamically typed languages

C.1. How to get feedback in a dynamic environment

C.2. The loan server (again)

C.2.1. A run-through of the Node.js code

C.2.2. Extending the test

C.3. Summary

Index

List of Figures

List of Tables

List of Listings