Based on my highlights
It's been a while since the last time I wrote the review of the first part of chapter I. I've just read it, 10 mins ago and I can say it sucks. It does makes sense to me though. The idea is not to write about how I struggle to come up with digested content of the book, its to have something useful for me and hopefully for you.
So let's continue digging into the second part of this chapter.
Modular design has its own pros and cons, but the book of course concentrates more on the goods because, well, you have to become a master on it.
When a module is small and decoupled, a.k.a. modular, the amount of code you have to see at each time is decreased.
Interfaces are always the primary citizen, and we get constant reminders of how important it is to keep it minimal / sufficient / consistent.
The most important part of a module is its Interface and it should be treated like such.
Although the book doesn't actually explain what modular granularity is but mostly try to give right away insights design an implementation considerations. I was trying to connect all the tips/facts/quotes that I found it more relevant to this concept. First of all I ask myself, What is Modular granularity ?.
My friends, I think we all have an idea, or we can easily try to define it. I will also take my shot here.
Modular granularity is a "property" that describe how granular a module is.
Granular doesn't only have to be seen from the point of view of size, but also complexity.
According to the book, we have to make our modules granular enough. The "why's" are very well explained in the paragraph of the book but I'll leave my top selection here:
For me, until today, how granular a module has to depend on your experience and knowledge about the system you are building.
I feel like granularity is not to be spotted right from the first time. As your system is evolving, new requirements will come to you and you'll have to decide wether is worth to modify your modules and attach that complexity to one of those or create a new module where that new feature should live. Either way, there is always a trade off.
If you make your modules way too granular, you'll end up with a bunch of one-line functions that are so granular that basically you are creating a layer of indirection for every little piece of code. (going to the extreme)
We all know what happens when a module is big. It's really hard to read, you feel like you are reading a book instead of code.
Modular granularity is hard, the book does not say the contrary and my personal opinion is,
keep the size of your modules manageable, not only for you, but also for your teammates.
Coding is a shared effort, and smaller modules benefit the whole team.