Chris Birchall - Re-Engineering Legacy Software

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 761 Shelter Island, NY 11964 Email: orders@manning.com

2016 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 Mannings 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 RoadPO Box 761Shelter Island, NY 11964

Development editor: Karen MillerTechnical development editor: Robert WennerCopyeditor: Andy CarrollProofreader: Elizabeth MartinTechnical proofreader: Ren van den BergTypesetter: Dottie MarsicoCover designer: Marija Tudor

ISBN 9781617292507

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 EBM 21 20 19 18 17 16

The motivation to write this book has been growing gradually throughout my career as a software developer. Like many other developers, I spent the majority of my time working with code written by other people and dealing with the various problems that entails. I wanted to learn and share knowledge about how to maintain software, but I couldnt find many people who were willing to discuss it. Legacy almost seemed to be a taboo subject.

I found this quite surprising, because most of us spend the majority of our time working with existing software rather than writing entirely new applications. And yet, when you look at tech blogs or books, most people are writing about using new technologies to build new software. This is understandable, because we developers are magpies, always looking for the next shiny new toy to entertain us. All the same, I felt that people should be talking more about legacy software, so one motivation for this book is to start a discussion. If you can improve on any of the advice in this book, please write a blog about it and let the world know.

At the same time, I noticed that a lot of developers had given up on any attempt to improve their legacy software and make it more maintainable. Many people seemed to be afraid of the code that they maintained. So I also wanted the book to be a call to arms, inspiring developers to take charge of their legacy codebases.

After a decade or so as a developer, I had a lot of ideas rolling around in my head plus a few scattered notes that I hoped to turn into a book someday. Then, out of the blue, Manning contacted me to ask if I wanted to contribute to a different book. I pitched them my idea, they were keen, and the next thing I knew I was signing a contract, and this book was a reality.

Of course, that was only the start of a long journey. Id like to thank everybody who helped take this project from a nebulous idea to a completed book. I couldnt have done it on my own!

This book would not have been possible without the support of many people. Ive been lucky enough to work with a lot of highly skilled developers over the years who have indirectly contributed countless ideas to this book.

Thanks to everybody at Infoscience, particularly the managers and senior developers who gave me the freedom to experiment with new technologies and development methodologies. I like to think I made a positive contribution to the product, but I also learned a lot along the way. Special mention goes to Rodion Moiseev, Guillaume Nargeot, and Martin Amirault for some great technical discussions.

Id also like to thank everybody at M3, where I had my first taste of release cycles measured in days rather than months. I learned a lot, especially from the tigers Lloyd Chan and Vincent Pricart. It was also at M3 that Yoshinori Teraoka introduced me to Ansible.

Right now Im at the Guardian, where Im incredibly lucky to work with so many talented and passionate developers. More than anything else, they have taught me what it means to really work in an agile way, rather than merely going through the motions.

Id also like to thank the reviewers who took the time to read the book in manuscript form: Bruno Sonnino, Saleem Shafi, Ferdinando Santacroce, Jean-Franois Morin, Dave Corun, Brian Hanafee, Francesco Basile, Hamori Zoltan, Andy Kirsch, Lorrie MacKinnon, Christopher Noyes, William E. Wheeler, Gregor Zurowski, and Sergio Romero.

This book also owes a great deal to the entire Manning editorial team. Mike Stephens, the acquisitions editor, helped me get the book out of my head and onto paper. Karen Miller, my editor, worked tirelessly to review the manuscript. Robert Wenner, my technical development editor, and Ren van den Berg, technical proofreader, both made invaluable contributions. Kevin Sullivan, Andy Carroll, and Mary Piergies helped take the finished manuscript through to production. And countless other people reviewed the manuscript or supported me in myriad other ways, some of which I probably didnt even know about!

Finally I would like to thank my wife, Yoshiko, my family, my friends Ewan and Tomomi, Nigel and Kumiko, Andy and Aya, Taka and Beni, and everybody else who kept me sane while I was writing. Especially Nigel, because he is awesome.

This book is ambitious in scope, setting itself the aim of teaching you everything you need to do in order to transform a neglected legacy codebase into a maintainable, well-functioning piece of software that can provide value to your organization. Covering absolutely everything in a single book is, of course, an unachievable goal, but Ive attempted to do so by approaching the problem of legacy software from a number of different angles.

Code becomes legacy (by which I mean, roughly, difficult to maintain) for a number of reasons, but most of the causes relate to humans rather than technology. If people dont communicate enough with each other, information about the code can be lost when people leave the organization. Similarly, if developers, managers, and the organization as a whole dont prioritize their work correctly, technical debt can accrue to an unsustainable level and the pace of development can drop to almost zero. Because of this, the book will touch on organizational aspects time and again, especially focusing on the problem of information being lost over time. Simply being aware of the problem is an important first step toward solving it.

Thats not to say that the book has no technical contentfar from it. Well cover a wide range of technologies and tools, including Jenkins, FindBugs, PMD, Kibana, Gradle, Vagrant, Ansible, and Fabric. Well look in detail at a number of refactoring patterns, discuss the relative methods of various architectures, from monoliths to microservices, and look at strategies for dealing with databases during a rewrite.