Martin Fowler chats about the work he’s done over the last couple of years on the rewrite of the original Refactorings book. He discusses how this thought process has changed and how that’s affected the new edition of the book. In addition to discussing Refactors, Martin and Wes discuss his thoughts on evolutionary architecture, team structures, and how the idea of refactors can be applied in larger architecture contexts.
Key Takeaways
- Refactoring is the idea of trying to identify the sequence of small steps that allows you to make a big change. That core idea hasn’t changed.
- Several new refactorings in the book deal with the idea of transforming data structures into other data structures, Combine Functions into Transform for example.
- Several of the refactorings were removed or not added to the book in favor of adding them to a web edition of the book.
- A lot of the early refactorings are like cleaning the dirt off the glass of a window. You just need them to be able to see where the hell you are and then you can start looking at the broader ones.
- Refactorings can be applied broadly to architecture evolution. Two recent posts How to break a Monolith into Microservices, by Zhamak Dehghani, and How to extract a data-rich service from a monolith by Praful Todkar on MartinFowler.com deal with this specifically.
- Evolutionary architecture is a broad principle that architecture is constantly changing. While related to Microservices, it’s not Microservices by another name. You could evolve towards or away from Microservices for example
Subscribe on:
Show Notes
- 01:15 Introducing Martin Fowler, author of Refactoring, Improving the Design of Existing Code. Originally published in 1999, the second edition will be published later this year.
- 02:04 Fowler's motivation for writing the second edition was because the first edition was really starting to show its age, especially the code samples. Also, the Java samples tended to lead to class-centered and object-oriented patterns, but refactoring is not limited to object oriented languages.
- 02:46 Fowler hopes the new book will also remain relevant for 20-years, because refactoring is a really important skill for programmers to have. The new book is almost a complete rewrite.
- 03:26 The new edition uses JavaScript for the examples. This was mainly because it was high on the list of languages that many developers can understand.
- 04:11 Fowler is still a big fan of objects. Sometimes, you want to refactor towards objects, while sometimes you may refactor away from objects. JavaScript provides the ability to express some of those refactorings.
- 05:04 The core idea of refactoring hasn't changes: a sequence of small things allows you to make a big change. Many of those "small things" are still the same, such as Extract Function.
- 05:46 Fowler has put more emphasis on Split Phase, which is the idea of dividing complicated computation into two distinct phases, with a data structure between them. This was a refactoring that he had been doing, but didn't know what it was called until discussing the idea with Kent Beck.
- 06:46 Publishing of all kinds, not just of technical books, has been dramatically impacted by the Web since the first edition was published. Although he's focused a lot of attention on martinfowler.com, the book was an opportunity to cover a lot of ground in a cohesive way, which is not possible on a web site.
- 07:48 Beginning in 2015, Fowler wrote a series of essays about refactoring, available on his home page. These served as the foundation for the book.
- 08:41 The web edition of the book is the canonical edition of the book, available if you purchase the printed book. This will allow Fowler to provide continual updates as well as additional refactorings that didn't make it into the book.
- 10:46 Some of the online refactorings include Remove Dead Code and others that are just about moving data around. These are all useful, but can seem too trivial to be put in the book.
- 11:43 An important refactoring is replacing loops with collection pipelines. Because of how languages evolved, this is now much more common than it was in 2000.
- 13:30 The book tries to take the approach of Fowler pairing with the reader, and explain what he would be thinking and saying about the code. This even includes when to commit to version control, since the role of version control also evolved.
- 15:01 The first edition had UML diagrams, but these have been removed. In most cases, just showing the code is more valuable than UML, and fewer people use UML than in 1999.
- 17:01 The highest priority is to make code comprehensible. Graphical notation can be helpful, but should be a secondary goal.
- 18:16 Ralph Johnston had a metaphor about early refactorings being like cleaning the dirt off of a window -- you need them just to be able to see where you are. Then you can start looking at the broader refactorings. Josh Kerievsky covered this really well in the Refactoring to Patterns book.
- 19:31 Fowler's general approach to refactoring is breaking complicated things down into smaller pieces, which makes them easier to move them around and reorganize them.
- 20:14 In 2014, Fowler wrote an essay known as "You must be this tall to use microservices." Although his focus on the book hasn't allowed him to keep up with all the tools that are "providing a box to stand on," the fundamental prerequisites still apply.
- 21:36 In a monolith, you don't expect in-process calls to fail. But with microservices you acknowledge that and have to think through how to handle failed requests. The fundamental complexity of distributed programming will not go away, regardless of the tools available.
- 22:51 Two recent articles on martinfowler.com have addressed architectural refactorings. The first, by Zhamak Dehgnani looks at breaking a monolith into microservices. The second, by Praful Todkar, looks at a solid example of this process. This follows the same process of taking something big and breaking it down into manageable pieces.
- 25:06 Evolutionary architectures, much like Extreme Programming, is an idea that a design is always changing, and doesn't have to be fully defined before beginning work. You should design your architecture with that change in mind.
- 26:54 Following Conway's Law, acknowledge that your team structure and your architecture will both evolve, and try to evolve them in a compatible way. The Inverse Conway Maneuver is when you restructure your team in a way that will encourage your architecture to follow it.
- 28:16 Fowler is a big fan of product-oriented teams, focused on a business capability, and not in favor of technology-oriented teams, such as a front-end team and a back-end team.
- 30:41 Now that the book has gone to the publisher, there's still more work to do, especially on the online version of the book.
- 31:31 The book will be available on December 31, 2018, possibly earlier. A rough cut is available now through Safari.