Workflow

Unit tests

You like basejumping from buildings in China ? You like stratopheric jump ? You like refactoring without unit tests ? Well, it's your choice...

A quick view before madness

At first, try this command :

$ php mondrian.php digraph ~/MyProject

As I said, check the ratio class/interface and the ratio of contract method on concrete methods to evaluate the level of abstraction. The lower they are, the difficultier the refactoring will be.

Spaghetti incident

Second, try this command :

$ php mondrian.php spaghetti --cycle ~/MyProject

If there is no cluster (strongly connected components), you are a lucky developer. If not, I recommand you to break the circle.

What are these classes ?

Model classes

hmmm... you have to rethink and abstract the model, add some interfaces to decouple these classes. It can be tricky and you have perhaps to talk to the business people what they really want to do ?

Service classes

There are good chances you need a Mediator pattern to "bind" these colleagues to work together. Don't forget to make an interface for this Mediator.

Circles of confusion

Third, try this command :

$ php mondrian.php spaghetti --strategy=concrete ~/MyProject

Is there one big ball of mud ? Well, you can check if there would be false edges because of method name collision. You can ignore calls in .mondrian.yml file. But wait ! This could mean there is a common contract between all these classes. Try to add the --cycle option to see the most intricated components but don't try to break it now.

Narrow the good edges

Fourth, you could iterate these three commands :

$ php mondrian.php hidden ~/MyProject

It helps you to find if there is really a non-typed parameter between two classes. Therefore, you start to add new dependencies, go to first stage.

Since there is no type, add new interfaces or abstract classes.

And this one :

$ php mondrian.php liskov ~/MyProject

It shows you (in red) which classes need to be abstracted first. The red circles are the most used classes accross the source. If you abstract them with new interfaces, there are good chances you'll break many cycles and dependencies.

That's why it is the perfect time to use the refactor tool :

$ php mondrian.php refactor:abstract ~/MyProject

And make many iterations in this very stage.

What is really important

Fifth, now you have a better matches between source code and digraph, you could try this command :

$ php mondrian.php bottleneck ~/MyProject

It tells you what is the most critical component. It is not SRP since it should have too many responsibilities.

And this too :

$ php mondrian.php ripple ~/MyProject

It tells you what is "on the top" of this package and what is "under the facade". This is the time to use a Facade pattern perhaps.

Loop over...

Sixth, it's time to show all dependencies with this command :

$ php mondrian.php spaghetti --strategy=any --cycle ~/MyProject

Beware, if you have too many classes in a cluster, Cthulhu is coming.

... and over

Seventh, you can carefully eliminates bad edges with :

$ php mondrian.php cycle ~/MyProject

Check the collision, create new interfaces and go to stage two or three.

May the force be with you

As you can see, there is no magic behind refactoring. It is an iterative process but with this tools, you can check at each step if you go in the right direction. Don't forget to branch over and over with GIT it is made for that !

It is only an example. Your process may be very different, depending of what kind of source code you have.

The finish line

There are some guidances, in order of priority :

• When the graph generated by badcontract is empty
• When you have no cycle in the graph generated by spaghetti --strategy=call --cycle
• If the hidden coupling graph is empty (or, has only false edges)
• When you have no cycle in the graph generated by spaghetti --strategy=concrete --cycle
• When you have no cycle in the graph generated by spaghetti --strategy=any --cycle
• If you have no more than one class per cluster in the graph generated by cycle
• If the graph generated by liskov is a set of small acyclic subgraphs with one or two classes per group
• When the graph generated by spaghetti --strategy=any is a set of small (2-5) groups of classes

Of course, it is difficult to achieve these guidances, even from a project starting from scratch. Following Law of Demeter and S.O.L.I.D can be very tricky sometimes. That's why design patterns are useful instead of re-inventing the wheel, each time you encounter the same problem. But one uses a pattern when one needs it ! In fact, a pattern is most relevant when it emerges itself from the code in a refactoring stage.

---