5 ms·

Fragmentation

19 points by r4um 3y ago

Jean-Papoulos 3y ago
As with anything, it's in the middle ground that the best solution is often found. I'm working on a piece of software that's so unfragmented that one of the exe it produces, which by all accounts ought to be around 10MB, ends up being 110MB. Because it's not possible to detangle the mess. At the same time, too much fragmentation will lead you to, indeed, have so many callbacks and other "controller" classes that you'll need a non-trivial amount refactoring anything you need to add a new feature, because the previously chosen lines of delimitation don't correspond to what the new feature needs.
inamberclad 3y ago
Encapsulation vs decomposition is a recursive problem. It can happen at any complexity scale. The trick, I think, is to find the level between the two that works for your project. Can you decompose your project into small, independent, testable units? Can a single unit be tested in isolation from all the others? One person will tell you that's a fragmented system while another person will tell you that all your software components are nicely encapsulated. It depends on your perspective and your needs. P.S. in any case, a robust interface specification is a prerequisite to good engineering.
jongjong 3y ago
> If the problem was decomposed based on ‘natural’ lines that tend away from dependencies, then the idea of treating stuff as fragments would work. But they don’t know what that means, so it doesn’t happen. This is such a good line. Most dependencies I see in enterprise software fail miserably at this and that's why they think they need a monorepo. I've found that people with substantial open source experience are often much better at figuring out what the 'natural' lines are because they tend to see the modules and libraries which they produce as final products. Their libraries are designed to be highly composable and cater to a broad range of use cases and systems. The key is writing components that are generic and broadly compatible. You want to avoid putting business logic into your dependencies. Try to keep all the business logic at the highest level possible in your code. It's very simple if you think about it; just imagine that you're a new developer on a large project, what would you want the code to look like? Most likely, you want to be able to understand what the system is doing by reading as few files as possible and you want the system's features to map to these top-level files in an obvious way. Because when you're debugging a feature, the first thing you need to do is figure out where in the code that feature is implemented. If you can't come up with a simple answer to this, then your system is probably poorly implemented.
- vincent-manis 3y ago
  I strongly agree with this, but there is a danger:over-engineering, where you build a very generic module where a much simpler one will do. The key point: build the most specific module that will do the job; if it needs to be more generic for a future application, then you go back and modify it as needed, adding a second interface if necessary. Generic features that have not been used or even tested are basically garbage code.
  - jongjong 3y ago
    It needs to be generic while also being as simple as possible. So you're building the module for a specific situation but leave it as open as possible for other situations without explicitly optimizing for them.
cloogshicer 3y ago
I don't think encapsulation is the answer either. It leads to the same problems that the author mentions (which I think are real). Brian Will has a very good video explaining this (timestamp is where he talks about encapsulation). https://youtu.be/QM1iUe6IofM?t=1090 https://youtu.be/QM1iUe6IofM?t=1090

19 points by r4um 3y ago

As with anything, it's in the middle ground that the best solution is often found. I'm working on a piece of software that's so unfragmented that one of the exe it produces, which by all accounts ought to be around 10MB, ends up being 110MB. Because it's not possible to detangle the mess. At the same time, too much fragmentation will lead you to, indeed, have so many callbacks and other "controller" classes that you'll need a non-trivial amount refactoring anything you need to add a new feature, because the previously chosen lines of delimitation don't correspond to what the new feature needs.

inamberclad 3y ago

Encapsulation vs decomposition is a recursive problem. It can happen at any complexity scale. The trick, I think, is to find the level between the two that works for your project. Can you decompose your project into small, independent, testable units? Can a single unit be tested in isolation from all the others? One person will tell you that's a fragmented system while another person will tell you that all your software components are nicely encapsulated. It depends on your perspective and your needs. P.S. in any case, a robust interface specification is a prerequisite to good engineering.

jongjong 3y ago

> If the problem was decomposed based on ‘natural’ lines that tend away from dependencies, then the idea of treating stuff as fragments would work. But they don’t know what that means, so it doesn’t happen. This is such a good line. Most dependencies I see in enterprise software fail miserably at this and that's why they think they need a monorepo. I've found that people with substantial open source experience are often much better at figuring out what the 'natural' lines are because they tend to see the modules and libraries which they produce as final products. Their libraries are designed to be highly composable and cater to a broad range of use cases and systems. The key is writing components that are generic and broadly compatible. You want to avoid putting business logic into your dependencies. Try to keep all the business logic at the highest level possible in your code. It's very simple if you think about it; just imagine that you're a new developer on a large project, what would you want the code to look like? Most likely, you want to be able to understand what the system is doing by reading as few files as possible and you want the system's features to map to these top-level files in an obvious way. Because when you're debugging a feature, the first thing you need to do is figure out where in the code that feature is implemented. If you can't come up with a simple answer to this, then your system is probably poorly implemented.

vincent-manis 3y ago
I strongly agree with this, but there is a danger:over-engineering, where you build a very generic module where a much simpler one will do. The key point: build the most specific module that will do the job; if it needs to be more generic for a future application, then you go back and modify it as needed, adding a second interface if necessary. Generic features that have not been used or even tested are basically garbage code.
- jongjong 3y ago
  It needs to be generic while also being as simple as possible. So you're building the module for a specific situation but leave it as open as possible for other situations without explicitly optimizing for them.

cloogshicer 3y ago

I don't think encapsulation is the answer either. It leads to the same problems that the author mentions (which I think are real). Brian Will has a very good video explaining this (timestamp is where he talks about encapsulation). https://youtu.be/QM1iUe6IofM?t=1090 https://youtu.be/QM1iUe6IofM?t=1090