Modularity in Design

One of the main aspects of programming is modularity to ensure the code is not complex, easy to understand, and testable.

Just for debate, if we ask why we need modular code, as an analogy, just think of your wardrobes. If you dump all your apparels into single large box, what happens?

Some of problems that you face would be:

• It's not easy to find what you need when you need it.
• It's difficult to understand the look of it.
• Does not look clean.
• It is highly impossible for another person to decipher it.

It would look like a cobweb. The same issues are applicable for unorganized code. It is not merely enough to achieve the functionality. I have seen many developers saying or hurrying up to achieve the user story functionality and putting aside all of these best practices, thinking they'll clean up later. I don’t think that the time will ever come to go back and clean up your code unless the technical debt grows enough to start troubling you.

In the first place, refactoring the code again and again would make code fragile. It is like putting multiples patches to your shirt instead of using a single piece of cloth. The durability and robustness would be lost by doing too much of refactoring. Some of the other disadvantages would be:

• The effort to refactor, things might not fall in order to refactor and end up with too many compromises
• QA effort to regress again and again after it is refactored
• Dependent code may require refactoring other things, like test automation scripts, dependent methods etc.,

So the principles to follow would be

• Design first
• Do it right at First

When there is a problem, it is important to think first about the design and then organize your code into appropriate smaller methods. One of the biggest design principles it should follow is Single Responsibility. Every method should be written to achieve single responsibility.

As and when you add more responsibility, the complexity of the method would increase. Every possible code paths would add complexity to the method. You could easily measure them using any static code analyzer tool.

Just to step back to the original analogy of messed up wardrobes, in organized wardrobes, all your shirts, trousers, ties, belts, wallet, and watches are all organized in appropriate compartments. Each one of those boxes serves single responsibility. This way all the above problems would be resolved. In a similar way, our code should be modularized in appropriate compartments (methods) so that they follow single responsibility by each method.

This also reduces overall code complexity; makes code easy to test, debug, and reuse; and allows other developers to easily understand and enhance it. 

Another approach that I will follow would be decorating methods with algorithms. Write algorithms to achieve required functionality, put them as code comments, and start adding methods for each one of those algorithms.

The method will contain defined as multiple steps to achieve the desired output, such as taking inputs, validating them and choosing the operator to compute. 

These steps can also be instrumented in such a way that it is easy to identify just by looking at logs. The application logs should be like your ECG to find anomalies in your heart function. Any anomalies in your method can be identified just by looking at logs.

To recap it, ensure your thinking to solve problems begins with design. Your approach of solving a problem should be algorithm-based and each modular method should follow the single responsibility design principle.