TLDR
You’ve been asked to consider replacing 2 open source modules–here is how to use Understand’s Architectures and Dependency analysis to let your boss know how much effort/risk this will entail.
Details
Let’s imagine my boss asked me to replace some open source packages that were inactive, might have security issues, and that could be replaced with newer actively-maintained projects. Sound familiar? Yes, I’m a boss, and I’ve asked for that very task more than once…
In my last example, I showed how to use Architectures to identify, measure, and track dependence on Open Source code. We are going to use a similar technique in this article to divide our code into what we will keep and what we will remove (refactor).
The projects in question are cmark and lpeg and libssh2.
I create a simple Architecture graph called Refactor, with “Keep” and “Refactor Out.”
I dragged all the source into “Keep” and then moved cmark, lpeg, and libssh2 into “Replace.”
Now I’m ready to see what the damage is…. I’ll make a graph of it by choosing “Graphs->Dependency Graphs -> Refactor, which yields this:
And I’m pleased to report… Hey boss, we aren’t EVEN USING cmark and lpeg. We can take them out entirely.
We use functions from libssh2 42 times. I expand the graph and find that most of the uses are coming from the _other_ open source packages.
That’s a bit thorny. I’m not sure I want to muck around in their code…
The code that uses it, that we did create, has just 7 uses. And, I can see exactly where they are in the Dependency Browser.
So I tell my boss, “Good news! It’s not that bad…in our code. Bad news–we’d have to mess around with open source code we don’t maintain to rip out libssh2.”
May the meetings begin!
Summary
- Make an Architecture divided into Keep and Refactor
- Use Dependency Graphs to visualize and measure the dependence on what we want to refactor. This includes what parts of our remaining code will be touched.
- Use the Dependency Browser to visit all those uses when the time comes to do the work.
