Prevent breaking your design, check dependency rules before merge
It is a common assumption that production code should not depend on anything from the test code. Or in a layered architecture, a middleware component should not depend on an application component. It should always be the other way around.
Breaking these rule can sometimes seem like a fast way to workaround or fix an issue. But most often it leads to unnecessary technical debt and complexity. Afterwards it usually gets difficult to fix it as new things are building on top of a bad dependency architecture and bigger and bigger refactoring needs arise. That's why you want to make rule violations visible. You want to prevent design flaws already before new code is merged to the main branch.
See an example below how we illustrate the case in code review. Here new dependencies have been added that violated the rules (example simple rule):
To prevent intentional and unintentional breaking of the design with bad dependencies, Softagram lets you define dependency rules for your projects. You can define the severity of each violation types, and give clear text reasoning for the author why he's seen the error in first place. If you are already using Softagram, read more on defining the rules from this help file.
Warning in the code review report if an unwanted dependency is being added.
Softagram dependency rule checks allows also effective refactoring. New interface modules would not allow any more imports with automated checks. Existing refactoring needs can be also seen clearly as they are visualized in the whole code base model browsable with Softagram Desktop.
See an example video of how the Softagram Bot shows rule violations e.g. in GitHub pull requests:
Benefits of informing the issues directly in the code review phase
Facebook study shows that issues found by any static analysis are fixed with over 70% rate when reported in code review. The bug fix rate alone clearly a great benefit. The affect is however multiplied by other benefits. If you need to fix a bug, it is easily up to 10 to 100 faster to do right after it's found, before the merge.
You don't have to follow any new process for the fix. There is no need for planning, no splitting of your mind and time between multiple tasks. You don't have to stop your existing work to go back on the case your might not even remember any more. No studying the area of code due it's the latest thing you did, and remember it well.
We all know the hassle if the bug, un-noticed, or not fixed, is found by the customer. All the escalations and planning and studying. It all would have been avoided would the finding been seen already before the code was even merged to main branch!
Dependency violations could be very dangerous. They are causing situations where they are no more fixable without a large refactoring. Detecting them early enough, might be only way to keep the software maintainable. Clear architecture allows to put efforts on new development and decreasing heavily the bug fix times.