4 ms·
Yep, you nailed it. Often the problem is exactly this magic "decoupling framework", which ends up being exactly the problematic part that that one eventually w
by whstl 3y ago
Yep, you nailed it.
Often the problem is exactly this magic "decoupling framework", which ends up being exactly the problematic part that that one eventually wants to swap out.
- Terr_ 3y agoI've been trying to think of a micro-example from some refactoring I've been doing lately. Long ago somebody made a Thingy.find(...) method where you can pass all sorts of optional arguments to filter which Thingy comes back, like Thingy.find(primary_key=1) or Thingy.find(owner=123, active=true) etc. That complexity made it flexible for people writing caller-code, because they wouldn't need to alter the method to satisfy their future arbitrary needs, they can just pass whatever key-values they want to match. However now some original invariants have changed, and now I need to go find all the places it's being used ("flexibly") and reconstruct the caller's intent, because in some scenarios the correct return value is going to be a list of multiple results instead of 0-or-1. In contrast, the task would be easier if there was a named method that captured the intent for the 3-4 distinct use-cases.