Saturday, October 31, 2015

Why Modularity?

Originally, I wanted to focus on how modular code design increases reusability (thus reducing code duplication) and leads to new ideas… but really it applies to many things. So let me talk a bit about that first.

You probably remember as a kid, you played with Legos.  They came with basic small pieces (usually… I think there are bigger ones now), and you put them together to create whatever you thought of.

Similarly in school, at least in the early years, you learned the basics which were used to build/understand more complex ideas.

Now back to coding. Recently, this has been a growing movement, and I think driven by multiple forces but all really address the same thing: inter-dependencies in monster code (henceforth known as MC).

Agile
MC is hard to change without accidentally breaking some functionality, Also boundaries between components are fuzzy: many many "hidden" relationships that don't show up until something (in Production) causes it to blow up. This means more time spent testing and debugging.

Clear Code
MC usually does many things…  at the same time…  which means the whole logic is hard to understand and debug. Humans' minds can only keep track of a handful of variables, especially if they are called x, y, z.

Testability
MC is tightly coupled and have dependencies all over the place that impact results… or even whether you get one or not (tightly coupled external services).

So then these need to be tested manually… again huge waste of time. I commonly hear stories of releases taking whole days and a team of people because the testing is all manual and it is very hard to automate… culprit?  MC and poor systems design.

Small generic code is usually fairly easy to decouple,  just stick an interface between them. In fact, you can then use a mocking framework to "mock up" an implementation for unit tests.

But actually Testability needs to be designed into the system and usually that leads to... modular components. That's also why we need to move to TDD where modularity becomes a basic requirement.

Reusability
Creating independent modules means that you can take existing, well-tested code and plug them into other apps. This is probably the main reason for the Apache Java libraries that address a lot boilerplate code. Similarly, I have created my own libraries that I use in a lot of my C# apps.

By reusing code, development is faster. Moreover, you are not wasting time and energy writing something that you already implemented 6 months ago. Or copying the same code snippet 50 times when you need to make a bug fix or improvement. And I doubt you will do much of the latter with the amount of "work" involved. Generally, you want to follow DRY: don't repeat yourself. Again TDD should help: if you're writing a similar test, maybe you should look at an existing module...

This time and energy saved (along with that from automated testing and deployment) is usually where new ideas come from.

You can also take a handful of them and write some new code that puts them all together in some new way and…  Voila! You just quickly (and cleanly) solved a really annoying problem or created a useful new app/solution.


No comments:

Post a Comment