MANNING Ola Ellnestam Daniel Brolund FOREWORD BY Tom Poppendieck www.it-ebooks.info The Mikado Method www.it-ebooks.info www.it-ebooks.info The Mikado Method OLA ELLNESTAM DANIEL BROLUND MANNING Shelter Island www.it-ebooks.info For online information and ordering of this and other Manning books, please visit www.manning.com The publisher offers discounts on this book when ordered in quantity For more information, please contact Special Sales Department Manning Publications Co 20 Baldwin Road PO Box 261 Shelter Island, NY 11964 Email: orders@manning.com ©2014 by Manning Publications Co All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine Manning Publications Co 20 Baldwin Road Shelter Island, NY 11964 Development editors: Copyeditor: Proofreader: Typesetter: Illustrator: Cover designer: Cynthia Kane, Frank Pohlman Andy Carroll Katie Tennant Gordan Salinovic Martin Murtonen Marija Tudor ISBN 9781617291210 Printed in the United States of America 10 – MAL – 19 18 17 16 15 14 www.it-ebooks.info contents foreword ix preface xi acknowledgments xvi about this book xviii about the cover illustration about the authors xxii xxi PART THE BASICS OF THE MIKADO METHOD 1 Meet the Mikado Method 1.1 What is the Mikado Method? Basic concepts of the method 1.2 ■ When to use the Mikado Method The Mikado Method recipe How to work with the Mikado Method 1.3 Summary 14 Hello, Mikado Method! 15 2.1 Your first Mikado Graph 16 Making changes without breaking code 18 2.2 A slightly more complicated change Getting to know the code 24 ■ v www.it-ebooks.info 23 Reverting code 26 ■ Benefits vi CONTENTS 2.3 Making the code configurable 26 Get going with the Naive Approach 27 Revert when there are errors 29 Select the next prerequisite 30 Create an interface 32 Restart from the goal 33 ■ ■ ■ ■ 2.4 Summary 36 Goals, graphs, and guidelines 38 3.1 The Mikado Method guidelines Always start with the goal 39 the key to safe refactorings 40 3.2 The Mikado Graph ■ ■ 38 Use experiments 39 Revert— Focus on the leaves 42 ■ 42 The goal—business or technical? 43 The prerequisites 43 Prerequisite—step or decision? 44 How big should a step be? 44 More about the leaves 45 The dependency arrows 45 The check marks 46 ■ ■ ■ ■ ■ 3.3 Tips for using the Mikado Method 46 Focus on the goal 47 Follow the flow of the code 47 Keep it simple 48 Keep it visible 49 Iterate, increment, and evolve 49 Remember the state 50 Reflect on your work 51 ■ ■ ■ ■ ■ 3.4 ■ Relation to other thinking models Theory of Constraints 52 Pull systems 52 3.5 Summary 54 The scope of a change 55 Changes at different scales 55 graph? 58 4.2 51 Empirical control systems 52 53 Organizing your work 4.1 ■ ■ When I start drawing my How to approach a change 58 Working in different constellations 59 Where to put the focus in a team 62 Pain points when working as a team 66 ■ ■ 4.3 Summary 67 PART PRINCIPLES AND PATTERNS FOR IMPROVING SOFTWARE 69 Breaking up a monolith 5.1 71 The code of an online loan institute The existing functionality 73 ■ www.it-ebooks.info 72 The architecture and the code 74 vii CONTENTS 5.2 Beheading the beast 77 Set a goal 77 Create an abstraction 80 More LoanRepository duties 83 Back to the business goal 84 Update the graph 84 Revert and restart from a clean slate 86 ■ ■ ■ ■ ■ 5.3 Getting to the true leaves of the graph The first steps on the way back 5.4 Summary 92 ■ 92 Side effect–free programming 98 99 Emergent design 100 6.1 Designing classes 101 Code that does too many things 101 Code that isn’t stable in the face of change 105 Code that violates its contract 108 Bulky interfaces 111 Code with rigid call-dependency chains 113 ■ ■ ■ ■ 6.2 Designing packages 116 What to put in a package 117 packages 119 6.3 ■ Dependencies between Summary 122 Common restructuring patterns 123 7.1 Graph patterns 124 Group common prerequisites in a grouping node 124 Extract preparatory prerequisites 125 Group a repeated set of prerequisites as a templated change 125 Graph concurrent goals with common prerequisites together 126 Split the graph 126 Explore options 127 ■ ■ ■ ■ 7.2 Scattered-code patterns 129 Merge, reorganize, split 129 Move code directly to a new package 132 Move code gradually to a new package 133 Create an API 135 Use a temporary shelter 136 ■ ■ ■ 7.3 Code tricks 139 Update all references to a field or method 139 Freeze a partition Develop a mimic replacement 141 Replace configuration with code 142 ■ ■ 7.4 appendix A appendix B appendix C Summary 143 Technical debt 145 Setting the stage for improvements 171 Dealing with dynamically typed languages 192 index 209 www.it-ebooks.info 141 www.it-ebooks.info foreword Most software discussions, books, and articles seem to assume that development work starts with an empty codebase The Agile literature usually presumes that the detailed learning about what is needed to solve a problem for a stakeholder community can be discovered iteratively and incrementally This might be a valid assumption if one is starting fresh, but I seldom encounter teams with the opportunity of starting from scratch; there are always constraints Most investment in software today involves modifications or extensions to existing applications and environments Thus, in addition to discovering and implementing solutions to our organizational problems/opportunities, we have the constraint of fitting into the environment created by earlier development teams We need to discover and codify not just the applicable domain knowledge, policies, and organizational goals that drive our current development work, but also to understand how the changes we make affect the existing application environment Everyone who has done this kind of work knows that the information we need is only weakly represented in the documentation left behind by preceding teams One has to look at the source code to get reliable information about the constraints it imposes on additions and changes If the source code includes an effective set of automated tests, we’re in luck because tests illustrate the behavior required of the code by previous implementers to solve previous problems If these tests pass when executed, we know that the code behaves as they expected More often, automated tests were never created, and we’re left with only the source code itself The question then becomes how to learn what we need to know to avoid breaking previous work The barrier is sheer complexity Analysis of the preexisting code has proven to be a weak tool for tackling this complexity Much of the code we have to confront no longer ix www.it-ebooks.info ... xxii xxi PART THE BASICS OF THE MIKADO METHOD 1 Meet the Mikado Method 1.1 What is the Mikado Method? Basic concepts of the method 1.2 ■ When to use the Mikado Method The Mikado Method recipe... used together in the Mikado context, these concepts are the core of the method Without these key pieces, the method can’t help you make changes without breaking the codebase By no means are these... graph The contents of a Mikado Graph normally come from the experiments Besides the changes to your system, the graph is the only artifact of the Mikado Method The Mikado Graph illustrates the