Have you guys read John Lakos "Large-Scale C++ Software Design?" For those that haven't, it's essentially a whole book about physical dependencies in software, and how to write code that can be separately compiled without spaghetti dependencies. In a sense, it describes alla prima strategies for getting to the end state Mikado is shooting for. If you've read the book, care to comment on the relationship? Does Mikado help you guide your system towards Lakos' ideal physical design?
Note: Amazon seems to indicate that a new edition of this rather dated book is due out soon!
We have not read that book, probably because we haven't worked with C++. :-)
As Ola has stated in one of the threads here, the Mikado Method helps you find what is stopping you and keep track of your change path (graph) to achieve a goal. The direction in which to take your codebase is up to you, speaking strictly Mikado Method.
But, we thought it would be evil to just leave our readers with that ;-) so in part II of the book, we do have a chapter where we talk about the things that has helped us immensely when restructuring (OO) code: Design principles. Low coupling, high cohesion, SOLID and the package principles, DRY, and more.
Looking at for instance SOLID and the packaging principles, they are what usually makes us avoid changes to ripple through the code base, making it possible for a large system to compile fast. We don't go into great detail, but we explain the basics and some smaller examples of what it might look like, in packages and in Mikado Graphs.
If Lakos takes the code in some other direction, you can use that direction when deciding how to resolve what is stopping you.
I hope that was some sort of comment on the matter. :-)
Can you really tell me that we aren't dealing with suspicious baked goods? And then there is this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!