Abstract: Find everything a module depends on so you can easily extract it into a separate binary.
I think my parents may have to give up on ever joining the “empty nesters” club. It can be hard to get those young adult children out of a basement and independent.
The CodeCheck window in Understand reminds me of a young adult living in a parent’s basement. Yes, it depends on Understand for a few things, but the window seems like an independent application with its own style and use case.
So, suppose I were to kick this window out of Understand and have it be its own application. At some point, I’d have to convince the project managers of the benefits. But I’ll start with a proof of concept so I have some data to back up my petition.
If CodeCheck is going to stand on its own, then it can’t have dependencies into other Understand GUI code. For example, since the application is just the CodeCheck dialog, it shouldn’t try to open editors. But it is still part of the family, so dependencies on API code are fine.
I can use Understand to find the places CodeCheck depends on the Understand GUI. Since our folder structure matches our library structure pretty closely, I’ll use “View Dependencies” on the CodeCheck GUI folder. If the module spans multiple folders, you can create a custom architecture for the same effect.
The dependency browser can be intimidating at first glance. The left tree is the source of the dependency and the right tree is the destination of the dependency. I can use the left tree to filter the right-hand tree by specific files.
But I don’t need that much complication. I’ll use the splitter to close the left tree and focus on the right tree. Now I’m just looking at the files and folders the CodeCheck GUI depends on.
At this point, I need a bit of familiarity with the Understand source code to know which libraries are okay to depend on and which ones aren’t. In this case, I know that maintainlib is the main library to avoid.
In this case, I only have 34 references I’d have to remove to run CodeCheck outside of Understand. All the references to ProjectApp::db() can be fixed by passing the database in at construction and all the remaining references are editor references (DefinitionWindow is the previewer editor and EntitySupport is also used to open editors). Removing the editor references will remove the references on the editor library too. All the remaining libraries are okay.
So removing those references is pretty fast. Then I can write a little more code to create an executable that takes an Understand project on the command line and opens the CodeCheck dialog for it. I have my proof-of-concept! Now I just have to convince the project managers of the benefits of kicking out independent children.