I’d go easy with the recommendation to couple components loosely. If you make things that belong together loosely coupled, you’ve created obfuscation, and added complexity to your codebase. Loose coupling makes sense, but not everywhere.
If higher-ups complain about intempestive code refactoring, it’s always a good idea to stop for a moment and to start becoming less trigger-happy with refactors. It’s OK to take some time to determine what actual value refactors bring to the project in tangible terms - intuition is not enough. Convincing a critical manager is a good start, because their tolerance for programmer bullshit is low if they don’t actually write code.
Very often, and this is especially prevalent among junior programmers who care about what they do, the reasoning for refactoring turns out to be something along the lines of “I don’t like this” or “I read some cool blog article saying things should be done that way”, without any care about whether or not the change in question is actually improving anything, or, if it does, if the improvement is worth the degradation in terms of quality (new bugs)/maintainability (added genericity making the code more difficult to understand, cryptic features of the language being used that make it hard to understand what’s going on, I’m sure there’s other examples…)
The problem is you often get in cases where the developer cannot back their intuition that something is actually harmful with facts. When it’s not just pure bikeshedding about code they don’t like and falsely claim to be a ticking timebomb, they fail to weigh the risks of leaving slightly offputting code in the codebase against the risks associated with significant code changes in general, which, even with tests, will still inevitably break.
Developers of all sorts tend to vastly overestimate how dangerous a piece of code may be.
To be clear, while I’ve seen it with other developers, I’m still guilty of this myself to this day. I’m not saying I’m any better than anybody.
It’s just that I’ve seen how disruptive refactoring can be, and, while it is often necessary, I thought it would be important to mention that I think it should be done with care.
If you can convince a manager with rational arguments in terms of product quality, it can be a good way to make the case for a refactor, because your manager probably won’t be impressed by arguments about unimportant nuances we developers obsess about.
Async is weird, and the generics salad stuff is clunky.
Just my gut feeling as well.
Damn, this thing slaps
Yeah, cause silly mistakes in one place never affect another place that’s completely unrelated.
Six levels of abstractions, sure, if you have that many, you may want 6 functions. But that contradicts Martin when he’s saying that there should be one line in an if, and everything more should be promoted to its own function. There’s no way a programmer routinely writes code so terse that you get six levels of abstraction in a dozen of lines of code. Otherwise, Martin doesn’t understand what an abstraction is.
Managing a stack in your head like a computer is very challenging as far as cognitive load is concerned. You don’t want to jump all over the place. Otherwise, when you reach your destination, you end up forgetting what got you here in the first place.
This form of code fragmentation makes debugging an absolute nightmare, and finding sources of mutation absurdly frustrating. Good tooling can help you track where a variable is used and in which order mutations happen trivially in code in a single function. It’s not as as helpful when it’s spread all over the place. You can infer so much less statically if you follow Martin’s advice.
I’m not advocating for 1000-lines functions here, mind you. When functions become too big, other challenges arise. What’s necessary is balance, which Martin’s book fails to teach.
It’s inspired so many crimes against engineering as a whole that it’s OK to discourage people from reading it. Not only is it pointless, but it’s also actively harmful to the industry as a whole.
When something is mostly garbage and good advice is so sparse in it, there’s no need to hold onto it. It’s as much of a mixed bag as a turd with a nice ribbon is a mixed bag of prettiness.
Burn it with napalm.
… Nah, I don’t actually mean it should be burnt, that was a joke. The book is a nice reminder that, on top of being a bigot, Robert Martin (not my uncle) should not be hired to write any kind of code in any professional capacity.
I know it is, and I find it to be a pretty ridiculously complex fix for a self-inflicted wound.
The disruption it’s caused me outweighs by far any minor inconvenience with the multiplication or micro packages in the NodeJS world. There’s that, and the Python 2 vs 3 shitshow from which the world still hasn’t fully recovered from yet.
I mean it: Python has no business laughing at Javascript. Get your act together, snek 😜
Python has other stupid problems related to pip. As much as stupid micro-dependencies suck in Javascript, they’re not the shitshow managing dependencies in Python is. It’s an inefficiency that never actually caused me noticeable issues in my former webdev life.
And let’s not talk about C++… People reinvent all sorts of wheels all the time because sharing anything is so annoying.
On top of being super bloated, Intellij’s Rider is far from “just working” in my experience. Not only is it super slow to boot, but it also changes asmdefs in my Unity project unprompted, in a way that prevents my project from working (creates cyclic dependencies). The debugger also sometimes doesn’t trigger breakpoints 😵💫
I absolutely despise it, viscerally.
I’ve been working as a professional programmer for many years and have never ever seen this kind of evaluation, not even once. I’m pretty convinced it’s an exception rather than a rule. And I’d add that it’s probably a very rare exception.
It’s not about freedoms. Your self-censorship is wasting everyone’s time, because we need to decipher what you meant.
This was not supposed to be a fucking riddle.
Your self-censorship actually makes your already bad meme even worse because it’s incomprehensible.
But sure, it’s your right.
Which advertiser are you talking about? 😵💫
This is a notoriously bad book. If you read the part about comments (which I don’t know about, and am willing to accept is good) make sure to skip everything else because Robert Martin is a fraud.
Even though I like intermediate variables myself, I’ve been told the same thing when co-authoring code.
What these anecdotes suggest is that this is subjective, and I think it can be overdone. I don’t think objective general rules can be established from the article, even though I think it’s good advice.
In my examples, I was overdoing it and causing too many indirections, creating leaky abstractions (leaky because, in my context, the abstraction was not tightly self-contained and understanding the “implementation” of the abstraction was necessary to understand what the line of code that was using it was doing).
I don’t think it’s a black-and-white matter. Your reviewer might not necessarily have been a moron, or might have lacked the self-awareness to realize they were imposing their own preferences onto you. But there’s a slight chance that you legitimately confused them with your indirections. Hard to say without context.
It’s the first time I see it, but that doesn’t mean it’s uncommon! 🙂
I had to look up what IINM means. For anyone wondering, it means “If I’m Not Wrong”.
Not sure this is worthy of an acronym, but that’s your choice! I just wanted to contribute context for people like me.
Not my experience. I’ve had the displeasure of having to use Rider at work, and it’s much slower than VSCode, if only for boot times which are a pain in the butt for large projects. You gotta pay for that bloat and feature creep somehow.
And that’s on a Xeon machine.
As for refactoring, yes, Rider has lots of options that don’t work and do half the job. So much so, that I don’t use them at all, because they’re unreliable.
The requirement for Copilot to qualify an IDE is a bit funny. First, VSCode has some support for it, and, secondly, this is super recent, so unless IDEs didn’t exist since last year, I’d say this is not core to the definition of IDE.