Goodbye, Clean Code

But I don't think you necessarily need to ask permission to refactor code. On the projects I had the past couple of years everyone understood that code was open to be changed by anyone.

In practice we'd often ask "why did you do X" instead of just rewriting it.

I trusted the people I worked with on those projects though and if they thought they had to rewrite part of my code for whatever reason, that was fine by me. And vice versa, I changed their code and that was fine.

Re: Goodbye, Clean Code

#5

Post by rckclmbr » Sat, Jan 11, 2020, 9:48 PM UTC

quaquaqua1 wrote: post #2

what the fuck did i just read

A good post about someone learning that writing code is more than just about how pretty it looks. How you work with others is incredibly important in this industry

Re: Goodbye, Clean Code

#6

Post by adamisom » Sat, Jan 11, 2020, 9:50 PM UTC

quaquaqua1 wrote: post #2

what the fuck did i just read

Would it help to point out the the author of that post invented React?

Re: Goodbye, Clean Code

#7

Post by BelleOfTheBall » Sat, Jan 11, 2020, 9:51 PM UTC

rckclmbr wrote: post #5

quaquaqua1 wrote: post #2

what the fuck did i just read

A good post about someone learning that writing code is more than just about how pretty it looks. How you work with others is incredibly important in this industry

Is that not common knowledge? I feel like this is a well-written post with a good point but it's a familiar point. You could boil part of it down to 'all's good in moderation', so don't just keep your code clean, keep it clean and easy to read, etc.

Re: Goodbye, Clean Code

#8

Post by scarface74 » Sat, Jan 11, 2020, 9:52 PM UTC

Insanity wrote: post #4

I agree that not every "smart approach" is worth it if you sacrifice legibility. But I don't think you necessarily need to ask permission to refactor code. On the projects I had the past couple of years everyone understood that code was open to be changed by anyone. In practice we'd often ask "why did you do X" instead of just rewriting it. I trusted the people I worked with on those projects though and if they thoug…

Well in his case, did refactoring the code to clean it up add business value?

There has to be a very good reason for me to refactor existing/working code for instance for performance.

I won’t refactor code to reduce existing duplication but I will refactor code if I see there is some functionality that I need elsewhere so I won’t just copy and paste.

Re: Goodbye, Clean Code

#9

Post by boffinism » Sat, Jan 11, 2020, 9:53 PM UTC

I think this highlights an important nuance to the Don't Repeat Yourself maxim. It's not just about whether two bits of code are similar now. It's about whether, when they change in future, they are likely to change in the same ways. If not, then DRYing up the code now is only making more work for yourself down the line.

Re: Goodbye, Clean Code

#10

Post by burlesona » Sat, Jan 11, 2020, 9:54 PM UTC

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often.

There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right?

So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you need to start passing options and configuration into your helper method... and before long your helper method is extremely difficult to reason about, because it’s actually handling a dozen cases that are superficially similar but full of important differences in the details.

I encourage my devs to follow a rule of thumb: don’t extract repetitive code right away, try and build the feature you’re working on with the duplication in place first. Let the code go through a few evolutions and waves of change. Then one of two things are likely to happen:

(1) you find that the code doesn’t look so repetitive anymore,

or, (2) you hit a bug where you needed to make the same change to the boilerplate in six places and you missed one.

In scenario 1, you can sigh and say “yeah it turned out to be incidental duplication, it’s not bothering me anymore.” In scenario 2, it’s probably time for a careful refactoring to pull out the bits that have proven to be identical (and, importantly, must be identical across all of the instances of the code).