But you should probably touch it before all the dependencies are outdated. And before everyone who understands how to work with it has left. Especially if it happens to be core to the business.
This is actually not a good advice, from my experience. If we don’t monitor, refactor, or improve the code, the software will rot, sooner or later. “Don’t touch” doesn’t mean we don’t ever think about the code, but we make the conscious choice not to modify it.
Ice cold take: You don’t have enough tests if you can’t safely refactor on a whim.
A well-tested project should allow you to refactor arbitrarily. As long as all existing tests pass, rewritten code is at least functionally equivalent to the previous code. This allows for fearless performance rewrites, refactoring, and even complete redesigns of components.
In other words, the tests are more valuable than the code itself. The spec for the codebase proper should be defined by the tests. When the spec changes or grows, the tests should change or grow, and then the main codebase should be modified to pass all tests once again.
TL;DR TDD evades this issue entirely and is fantastic for larger and/or longer-term projects
… said no programmer, ever. Especially not after hearing about a cool new feature in their favorite language or library that was just added in the newest unstable version!
Well over a decade ago I remember a coworker would just go through the codebase and add his own coding style.
Instead of if (predicate) {
He would do if ( predicate )
I would always ask why he did it and he said, “well we don’t have any coding standards so I’m going to do it” … I replied, “there’s things like unwritten rules and sticking to whatever’s in the codebase makes it easy”. I told the seniors and they chose not to do anything (everyone just merged into trunk) and they just left him for a while.
Then he turned rewrote built-in logical functions in code like this: if (predicate || predicate) {
Into code like this: if ( or( predicate, predicate ) ) {
This was C# and there was no Prettier back then.
Also, he would private every constructor and then create a static factory method.
Eventually the seniors told him to knock it off. All I said was that I initially tried telling them weeks ahead of time and now we got a mess on our hands.
I was mildly annoyed the other day when someone moved a works-fine function and reimplemented it with dropwhile. This apparently was a divisive idea.
Me: it worked fine. Don’t reimplement it for no gains. Don’t send people to somewhat esoteric parts of the standard library. No one on this team is going to know how that function works off the top of their head.
Them: it’s in the standard library it’s fair game. It still works.
One benefit of using dropwhile is that (with a bit of practice) it can actually be easier to read than a for loop. All for loops look similar. You need to read the for loop line by line to understand what it really do.
With dropwhile (or map, filter and reduce), it’s immediately obvious it will drop all elements until a certain condition turns false.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
That’s a good way of maximizing technical debt.
“That sign can’t stop me because I can’t read!”
But you should probably touch it before all the dependencies are outdated. And before everyone who understands how to work with it has left. Especially if it happens to be core to the business.
:)
Why would you touch your job security?
This is actually not a good advice, from my experience. If we don’t monitor, refactor, or improve the code, the software will rot, sooner or later. “Don’t touch” doesn’t mean we don’t ever think about the code, but we make the conscious choice not to modify it.
if it’s stupid and it works, it’s still stupid, and you’ve been lucky this far.
Ice cold take: You don’t have enough tests if you can’t safely refactor on a whim.
A well-tested project should allow you to refactor arbitrarily. As long as all existing tests pass, rewritten code is at least functionally equivalent to the previous code. This allows for fearless performance rewrites, refactoring, and even complete redesigns of components.
In other words, the tests are more valuable than the code itself. The spec for the codebase proper should be defined by the tests. When the spec changes or grows, the tests should change or grow, and then the main codebase should be modified to pass all tests once again.
TL;DR TDD evades this issue entirely and is fantastic for larger and/or longer-term projects
… said no programmer, ever. Especially not after hearing about a cool new feature in their favorite language or library that was just added in the newest unstable version!
I don’t care, you’re not to use static!
Well over a decade ago I remember a coworker would just go through the codebase and add his own coding style.
Instead of
if (predicate) {He would do
if ( predicate )I would always ask why he did it and he said, “well we don’t have any coding standards so I’m going to do it” … I replied, “there’s things like unwritten rules and sticking to whatever’s in the codebase makes it easy”. I told the seniors and they chose not to do anything (everyone just merged into trunk) and they just left him for a while.
Then he turned rewrote built-in logical functions in code like this:
if (predicate || predicate) {Into code like this:
if ( or( predicate, predicate ) ) {This was C# and there was no Prettier back then.
Also, he would private every constructor and then create a static factory method.
Eventually the seniors told him to knock it off. All I said was that I initially tried telling them weeks ahead of time and now we got a mess on our hands.
The best part is that his “or” function changes the semantics of the code in a subtle and hard to find way. :D
looks at the startup scripts I just took from a 2h runtime to 15m
Guess I gotta revert those changes.
I was mildly annoyed the other day when someone moved a works-fine function and reimplemented it with dropwhile. This apparently was a divisive idea.
Me: it worked fine. Don’t reimplement it for no gains. Don’t send people to somewhat esoteric parts of the standard library. No one on this team is going to know how that function works off the top of their head.
Them: it’s in the standard library it’s fair game. It still works.
One benefit of using dropwhile is that (with a bit of practice) it can actually be easier to read than a for loop. All for loops look similar. You need to read the for loop line by line to understand what it really do.
With dropwhile (or map, filter and reduce), it’s immediately obvious it will drop all elements until a certain condition turns false.
Its ok to touch up code. If you have lots of notes, on what its supposed to do… I learned this the hardway.
flipside: it needs to be fixed but the only person who understands it is OOO
Don’t touch things unless you have a good reason to do so. And when you have a good reason, touch it exactly as much as you need - but never more.