|
|
|
|
|
|
by sam0x17
1771 days ago
|
|
|
> Doing this doesn't hurt. There's nothing stupid about it unless you coded everything in a way where it's NOT modular. It does. If I open up an arbitrary Ruby on Rails app for example, it is going to be easier to navigate for example a super fat model file than it is to navigate one that has been divided up into 10s of helpers and companion modules. There are similar scenarios in every other language. Extracting code and moving it somewhere else can truly be a death by a thousand cuts. My rule of thumb is if there aren't at least two places in the code that need to call My Extracted Thing (tm), then it shouldn't be extracted in the first place. If you're being DRY, it's OK to have a long class/file/method/function/module, and it's probably preferable to obfuscating your codebase and making it more difficult to navigate. |
|
|
This is not what I mean by modularity. Let me be more specific. The code CAN be seperated and it can be recombined without a structural code rewrite. That is what I mean by modularity. Actually dividing code up and organizing it among different files is an opinionated organization scheme and NOT what I'm talking about.
When you do extract code and move it anywhere it's not exactly "death" it's just harder to read. Structurally the code is still sound. You can meet the requirements without rewriting the code, it's just the code is more complex to understand.
The bad scenario I'm talking about here is when you can't extract code and you can't move it around. When your requirements necessitates logic to be moved around and you can't because code is too coupled with other code. That is more closer to literal death by one cut. You are technically unable to meet requirements with existing code.
The modular primitive that prevents this from happening is the immutable pure function. But it's not a one size fits all solution.