Imposing Rule-Based Architecture on Legacy Systems

This was the title of a talk by Michael Feathers (@mfeathers) at the OOP 2014 conference. I was looking forward to his talk because I like his book „Working effectively with Legacy Code“. In his talk he said that this book is about „bringing automated test in place“. I think that is a good summary.

After looking at various definitions of software architecture, he cited Kent Beck: „If you can’t explain your system using four objects you don’t have an architecture.“ This means you have a small set of things to think about and it makes a system understandable. Michael suggests a practice to tell the story of a system using four (or so) objects. I think I’ll make a blog post explaining the system I am working on in about four objects.

As an example of an architectural rule Michael mentioned the seperation of business logic and persistence.

He presented the following rule-based techniques.

Build checks. At build time check certain rules, can be as simple as grepping source code, i.e. using database code in web modules and failing the build. The problem is that people will find ways around these checks when in a hurry.

Dealing with corruption

Local tagging. (aka „TODO“) code comments that are grep-able

Component tender. someone who (temporary) „takes care“ of a component, i.e. watches and fights architecture or design degradation.

Silent alarms. like build checks but will not break the build

Progress

For making progress you can either fix things („Active Reduction Work“) or just stop making things worse („Thresholded Practice change“).Either way, things will get better.

As a direction for „better“: make the system simple.

His advice do not depend on a particular product. He mentioned „grep“ which is rather low level. In the Java ecosystem, I would mention SonarQube as a monitoring tool for architectural measurements. You can use JDepend with JUnit for implementing build checks.