Summary: Your smart people know what your code’s dependencies are supposed to look like. Understand can help you see what they actually look like and provide the tools to get them back where they should be.
What does your code look like at a high level? Experienced engineers develop a feel for the components that make up their projects, and can use Architectures to share that knowledge with the new folks. Each component has dependencies on other parts of the code, and frequently there is a disconnect between how your code structure should look and how it actually looks. That can cause issues that are hard to track down and even harder to fix.
Let’s look at a real-life example from Understand. We have great APIs that let you access all of the power of our analysis from outside of the Understand GUI. Some of our customers want to use them as part of their DevOps process on headless Linux systems, which works great, except for one thing. Currently, they have to install X11 system libraries for those APIs to work correctly. That seems dumb. Why do we need graphical libraries to run APIs? I decided to use the Understand Architecture Dependency graph and Architecture Browser to look closer. I can see that there are four direct dependencies where API is using types defined in UI – that shouldn’t be hard to fix!
But after removing those I still get the X11 errors. These four were just the direct dependencies, how many indirect dependencies are there? Understand’s Dependency Checks will let me define the rules I want to enforce and test how well they are being followed. There are a lot of different options for creating rules – but I just need this one: API cannot depend on UI.
After hitting Save & Run, Understand shows all of the dependencies between the two, both direct and indirect. There are several panes in this view, so I’ll walk through each section.
And here is the full, massive graph for this rule.
Every line in this graph is a dependency where API is using something that uses something else that relies on UI. Understand also identified a minimal set of references that would need to be “cut” to make the code compliant with this rule – these are the bolded lines. In this case, there are a whopping 428 locations in Understand’s source that need to be modified or removed. That’s a lot of work that we don’t have anyone scheduled for right now. After talking with our senior engineers we decided to leave these connections for now. However, we want to stop new dependencies from being added here going forward. That’s where CodeCheck comes in.
The new Dependency Checks section in CodeCheck will show any dependency rules that you have made and let you select them as part of your CodeCheck settings.
Now anytime I run CodeCheck I can see if an engineer has accidentally added another dependency here. By adding this rule to our company CodeCheck configuration, it instantly became part of our automated DevOps process in Jenkins. Now, if an engineer does add another dependency they will receive an email warning that looks like this.
This is bad news for those Linux sysadmins, they will still need to install the x11 libraries for now. We’ll probably start removing those 428 violations as we come across them in their respective areas of the code. At some point, we may even make a concerted effort to remove them all, but in the meantime, we can be assured that no new violations are being added and the problem isn’t getting worse.
Interested in learning more about how we calculate dependencies? Natasha goes into detail here.