One of the barriers inside most organizations that must be overcome is the issue of applications and frameworks that were built with tightly coupled code. A number of DevOps methods have been developed to try and overcome this issue, one of them being the move towards micro services.
In Tightly coupled code, classes and objects are dependent on one another. In general, tight coupling is usually bad because it reduces flexibility and reusability of code and it makes changes much more difficult and impedes testability etc.
When we have a tightly coupled object, it becomes an object that needs to know quite a bit about other objects and thus are usually highly dependent on each other’s interfaces. Changing one object in a tightly coupled application often requires changes to a number of other objects. In a small application, we can easily identify the changes and there is less chance to miss anything. But in large applications these inter-dependencies are not always known by every programmer or there is a chance of overlooking changes. But each set of loosely coupled objects are not dependent on each other.
In order to develop a DevOps pipeline and actually take advantage of its benefits, then we truly need to move towards loosely coupled code. Loose coupling is a design goal that seeks to reduce the inter-dependencies between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component. Loose coupling is a much more generic concept intended to increase the flexibility of a system, make it more maintainable, and makes the entire framework more stable.
In DevOps, we find that a major killer in our move towards developing a pipeline that allows us to quickly turn out high quality code is the affect tightly coupled code has on Unit testing. Make no mistake, if we do not have Unit testing in place then it doesn’t matter what tooling we create as part of our DevOps pipeline, we will still be dependent on having manually test runs in order to get the code out. While having tightly coupled code is not a complete death knell to Unit testing, it does require organizations to strategize their Unit testing more closely and also employ tooling such as SonarQube to overcome this Technical Debt issue.