> people are simply terrible at modularizing code.
Once you realize you needed it, its too late.
Then once you've been burnt on that fire for a bit, you go all out in designing the next few projects with framework and forethought and wind up with 100 lines of that for a 10 line script.
the moral is "life's a bitch"
Re:Give me back my monolith (2019)
by 1penny42cents on Tuesday May 10, 2022 @05:31PM
(#31332993)
That oscillation is necessary to be able to converge on the optimal medium for any given problem.
Otherwise we get stuck in "modularization bad" or "modularization good" mindsets, where both are wrong.
I agree; people are much more careful about splitting responsibilities and designing APIs between processes (REST, GraphQL, XML-RPC) than between code modules. Simply switching from a monolith to microservices makes them more thoughtful about the consequences of design.
Re:Give me back my monolith (2019)
by throwaway6532 on Wednesday May 11, 2022 @08:04PM
(#31347610)
>Simply switching from a monolith to microservices makes them more thoughtful about the consequences of design.
Well, in my experience it makes _some_ people more thoughtful about those things.
It seems to me that people are simply terrible at modularizing code. (Including me.) I've seen this problem far more often than not, in every organization I've worked with, for my entire career.
Just the other day I worked on a function that did some Windows API calls for file I/O, allocated a bunch of memory, and processed the file contents. I split it up so the code that needed the Windows API did just that - it didn't allocate any memory, and the processing was done with a callback.
That meant the Windows API accessing code didn't need to import anything from the rest of the program, and the rest didn't need to import the Windows API.
(There are some success stories. The popularization of generic algorithms and ranges (or iterators) has been a big improvement. And the use of global variables has become frowned upon.)