3 ms·

> For me this one also seems inevitably connected to the idea of microservices Oh yeah. But I've seen this also happening in frontend libraries, and sometimes

by ratww 5y ago

> For me this one also seems inevitably connected to the idea of microservices Oh yeah. But I've seen this also happening in frontend libraries, and sometimes even inside monoliths. I find that inexperienced developers tend to break up services/libraries/classes purely because they believe that "code should be neatly organized", not because there is a logical boundary between two parts of a system. Thus, we get lots of tight coupling, chatty microservices, and 20 lines of imports at the top of the file. I find that A Philosophy of Software Design by John Ousterhout [1] has a good rule of thumb: classes (and services, libraries, repos, applications) should be "deep, not shallow". The "surface" (aka the part that touches external components) should be as small as possible, while the internals should be larger. Of course that doesn't sit well with people looking to "neatly organise code". [1] https://www.goodreads.com/book/show/39996759-a-philosophy-of-software-design https://www.goodreads.com/book/show/39996759-a-philosophy-of...

selfhoster11 5y ago
I believe that code should be neatly organised, though I have no preference about how this is accomplished. What would you suggest I should do, if not split classes?
- ratww 5y ago
  You should split classes! But only where it makes logical sense, where there is a clear logical boundary. Splitting code as a way to visually organize code can lead to tight coupling, which tends to be worse than large classes. If you split a class but there’s still multiple “points of contact” between both, it wasn’t a good split at all.
  - selfhoster11 5y ago
    People split classes for visual reasons? That sounds unwise. I only ever split because the class is getting too large, or because some functionality is better off being moved to its own class. And those other classes also should preferably only have one or two methods exposed to the outside, there's nothing worse than a large surface area unless it's a library class.
    - ratww 5y ago
      Yep, you are completely right, this is extremely unwise. Problem is, a lot of material aimed at beginner developers basically instructs that. Also a lot of linter documentation shepherds users into doing it (I'm thiking of some Ruby linters here). > there's nothing worse than a large surface area unless it's a library class Yep, exactly. Even big classes are better than tightly-coupled classes with large surface area.

by ratww 5y ago

selfhoster11 5y ago

I believe that code should be neatly organised, though I have no preference about how this is accomplished. What would you suggest I should do, if not split classes?

ratww 5y ago
You should split classes! But only where it makes logical sense, where there is a clear logical boundary. Splitting code as a way to visually organize code can lead to tight coupling, which tends to be worse than large classes. If you split a class but there’s still multiple “points of contact” between both, it wasn’t a good split at all.
- selfhoster11 5y ago
  People split classes for visual reasons? That sounds unwise. I only ever split because the class is getting too large, or because some functionality is better off being moved to its own class. And those other classes also should preferably only have one or two methods exposed to the outside, there's nothing worse than a large surface area unless it's a library class.
  - ratww 5y ago
    Yep, you are completely right, this is extremely unwise. Problem is, a lot of material aimed at beginner developers basically instructs that. Also a lot of linter documentation shepherds users into doing it (I'm thiking of some Ruby linters here). > there's nothing worse than a large surface area unless it's a library class Yep, exactly. Even big classes are better than tightly-coupled classes with large surface area.