• +43 660 1453541
  • contact@germaniumhq.com

Creating Code Navigation Maps With UML

Creating Code Navigation Maps With UML

Now that we have ways to build the software when we change it, navigate around code, and fuzzy search through it, let’s see how we approach specific problems, and use UML to chart this map.

Let’s assume we have a bug in a non-trivial code-base. We’re able to reproduce the bug. We used our previous approaches (i.e. by finding some label from the UI, or message in the log) so now we are in some UI component. This is our entry point to the code, and finding what’s going on.

What I like to create is an UML that describes this relationship. I almost never generate the UML from the source code. Why? Because my personal experience is that the noise of all the methods and functions from a class, impedes our search, not aids it.

So I’ll start with an UML viewer (I actually use an old Enterprise Architect license that I have laying around), and simply add one or two classes in the diagram.

2019 03 06 navigating legacy code uml

Then as I’m searching for references, and finding usages of the class, I also augument the UML, with the findings:

2019 03 06 navigating legacy code uml2

Depending on the complexity, I’d also add nodes in the UML, or simply cross reference files with specific code.

The reason why I use UML is because I’ve noticed it’s generally resilient due to the nature of writing code, and it gives an immediate overview on what’s going on.

I also noticed that except very early in the code development, code doesn’t changes as much as people think. So the risk of map being the territory is rather low.

The whole process is also doable on simple sheets of paper. I actually prefer them if the problem I’m trying to solve is a one-off.

Simply creating this diagram gives us insight on the relationships, and allows us to have our bird’s eye view, on the whole dynamic of communication between the components. This insight allows us to solidify and validate our assumptions. It increases our understanding on what’s the best place to apply changes to the code. It shows us who’re the players directly affected by our changes.

So UML away!