5 ms·
The article makes some very important points and it's certainly worth a read for every programmer. What the article misses to address explicitly however is tha
by rsp1984 11y ago
The article makes some very important points and it's certainly worth a read for every programmer.
What the article misses to address explicitly however is that the whole redundancy vs. dependency conflict is caused by modularization. Without modules there would be no conflict.
So the real questions to answer here are: When do you need modules or do you need them at all? What should be modularized? And, most importantly, how to choose smart boundaries? Good answers to these questions will save a project from a world of pain down the road.
The classic OOP / software engineering education these days lacks critical debate about software modularization. Modularization is almost always presented as a good thing. What nobody tells you however is that in real world engineering, on real world teams, modularization can cause a lot of trouble if not done the right way.
- agumonkey 11y agoI remember a language project without the concept of function. An massive inlining system to avoid the issue of modularization.
- mdpopescu 11y agoWithout modules you just repeat the same dilemma at the level of classes or even functions.
- loup-vaillant 11y agoCode is basically a dependency graph. Each piece of code depends on a number of other pieces of code. (Dead code is an isolated island in this dependency graph.) You want two things out of that graph: less nodes, because less code is simpler, better, cheaper. And less edges, because understanding, modifying, or troubleshooting a piece of code requires knowing about its dependencies (hopefully, only the direct ones). When the unit of organisation is the function, you kinda state that each function is a node, and the call graph are part of the edges (the call graph would cover everything in a purely functional settings, but side effect produces implicit dependencies). Trouble is, in any significant system, you're gonna have a lot of nodes and edges. How to make sense of that? That's why we have module. When you look at your dependency graph, you will most certainly note that parts of your graph are denser than others. Those clusters are the natural modules. If you formalise that, and draw module boundaries around those clusters, you can now have a two-level view: inside a module, you have a small dependency graph, with a few outbound edges. Outside, you can visualise a coarser graph of module dependencies. Again, fewer nodes and edges, because you have grouped them. Now the real benefits of module is, once you start drawing boundaries, you have an incentive to make small interfaces, to minimise inter-module dependencies. Additionally, visualising the module dependency graph directly helps you spot spooky dependencies that probably shouldn't be there. You can then cut some dependencies out, simplifying your graph in the process. Without modules, I don't see how you would manage this kind of scale. Oh and by the way, some monstrosities are so big that they effectively requires a third level. But I've never worked on such beasts.
- rsp1984 11y agoYes, that's a very good picture of things. Now the dependency vs redundancy issue comes in when two clusters are made modules. If they are mostly separated but still have some connections to each other the question is what to do with these. Cut them off means having to replicate so ultimately redundancy. Leaving them in means dependency. I guess the way modularization should be done is therefore as a min-cut through the dependency graph.