
Why Small Modules Matter - fagnerbrack
https://medium.com/@fagnerbrack/why-small-modules-matter-4e4d629321b8
======
Someone
_" Conclusion By separating the concerns and trying to create more efficient
abstractions, we can build a small amount of functions that are perfectly
decoupled and reusable. This way we don't need to think too much when making
changes to the domain."_

For me, that is the case for small _functions_, not small -modules_.

The problem with small modules is that they run the risk of being slightly
incompatible with each other. You create some object of type T with module X,
pass it to module Y, but the modules disagree about 'minor' details of type T.
Proponents will argue that both should build on a module defining T, but
before you know it you are handing with types T, T', T'', etc. all being
almost the same thing. Even if you don't, the modules will disagree about how
to return errors, do logging, etc.

That problem can be solved when one party packages a set of potentially well-
interacting modules, removes redundant functionality, tweaks them to interact
really well, and ships the result as a larger module.

Now, that still can lead to many modules shipping overlapping coherent
functionality. In that case, I think competition should drive competition from
the market. It also can help if a large party uses his power in the market, as
happened with Microsoft and .Net. Compared to Java, there's way less chance
that you will find that you need two XML parsers or two different concurrent
set implementations in your project (yes, in some cases that is 'solved' by
making XML parsers or logging libraries pluggable, but I think that
overcomplicates things.

Because of that, I think there is some kind of "seven plus or minus two"
equivalent for modules: they should form a tree that has a limited branching
factor, so that both the top level module and all submodules build on not too
many other modules (value of 'not too many' TBD)

You don't see a C program do

    
    
      #include <strlen.h>
      ...
      #include <strcat.h>
    

it just includes a single header that brings in a set of related functions,
and lets the linker ignore unused ones.

Of course, in the JavaScript world, there is no linker yet (or at least,
proponents of tiny modules haven't (fully) realized that their minifier
could/should strip out unused functions) so people waste time manually
specifying exactly what to include.

Also, the JavaScript world still lives in the Wild West, and it will be a
while before larger libraries will start making sense. That JavaScript is so
loosely typed doesn't help, but I expect that the move to Web Assembly (or
whatever the idea is called nowadays) will see this change rapidly. That
certainly will happen if/when entities start shipping web assembly binary
blobs.

~~~
fagnerbrack
Sorry to take so long to respond.

Your arguments applies to modules that are external, not internal ones. The
article specifically talks about internal abstractions, not abstractions that
should be all exposed for external consumption (multiple projects). That is
definitely up to the requirements.

There is no difference between using a single module with many functions than
using many functions inside a feature directory. I would argue the last one
make the intent clear while not having to think about another searation (the
module file).

