idea how long a change can take 01. 02. There is no correlation between the business and the technical complexity 03. You don’t know when something will break
of the fear involved in making changes to large code bases is fear of introducing subtle bugs; fear of changing things inadvertently. Without test, you just don’t know whether things are getting better or worse. » — Michael Feathers
of your software 01. 02. Without bringing the remaining parts with it 03. Optimize your software for replacement A natural process that cannot be stopped
it appear? Refactoring helps to keep complexity under control 01. 02. A good software design is critical in the long term 03. Technical debt ≠ legacy software, but it can accelerate the process
to refactor This is the « boy scout rule » 01. 03. When you found a bug, fi rst write a test that triggers it, then fi x it. 04. Beware of the broken windows syndrome Developing a new feature and refactoring doesn’t mix well! 02.
The « We’ll fi x it later » syndrome 01. 02. The same cause always produces the same effect Instead provide a learning time, so you stop writing legacy code 03.
must not call directly the Legacy code 01. 02. The Legacy code must not call directly the Green fi eld code 03. Even through the persistence system: database or event/message bus
pattern How to tackle it? You’ll need to coordinate your actions at the system level 01. 02. Beware of functional debt 03. Optimize your new system for replacement!
E ff ectively with Legacy Code • Refactoring Going further Thanks to Michael C. Feather, Adam Thornhill, Cyrille Martraire, Thomas Pierrain, Martin Fowler, Jean-Baptiste Dusseaut, Ola Ellnestam, Daniel Brolund, Adrian Bolboaca