Goodbye, Clean Code • Hacker News Board

Re: Goodbye, Clean Code

#361

Post by skrebbel » Sun, Jan 12, 2020, 9:24 AM UTC

Stratoscope wrote: post #262

scarface74 wrote: post #25

Earlier quoted context omitted.

That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…

The Rule of 3 is a great rule, except when it isn't. I had a colleague some time ago who wrote a couple of data importers for FAA airspace boundaries. There were two data feeds we cared about, "class airspace" and "special use airspace". These airspace feeds have nearly identical formats, with altitudes, detailed boundary definitions, and such. There are a few minor differences between the two, for example different…

To be honest I don't get it. What language was this in, that you couldn't duck type the data or make the data structures inherit from some shared interface that encapsulated the commonalities?

Re: Goodbye, Clean Code

#362

Post by vonseel » Sun, Jan 12, 2020, 9:26 AM UTC

burlesona wrote: post #10

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 ne…

I’m just wondering where you draw the line.

As with everything, it often becomes a big grey area on what is acceptable and what is not.

Example: my (fictional) company sells a B2B platform which provides companies with an online marketplace or some other type of online application. Each installation requires different, though often similar, integrations with the customer back-ends - think Postgres vs MySQL, but some customers may also use TotallyEffingObscureDB, which doesn’t even speak SQL. Those backends are usually the source of truth for the entire stack, storing user data, etc, the local data is just a mirror.

So, given this scenario, how should we approach user registration processes? Is that a product component or custom (not DRY) code? What about all the other (similar, common, and basic) features of our platform that every customer wants but invariably needs to be implemented slightly differently?

I’m only posing these questions because I worked in a situation where something similar happened, and it wasn’t dealt with well, and I’m wondering what other HN coders have to say...

Re: Goodbye, Clean Code

#363

Post by useful » Sun, Jan 12, 2020, 9:27 AM UTC

Stratoscope wrote: post #262

scarface74 wrote: post #25

Earlier quoted context omitted.

That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…

The Rule of 3 is a great rule, except when it isn't. I had a colleague some time ago who wrote a couple of data importers for FAA airspace boundaries. There were two data feeds we cared about, "class airspace" and "special use airspace". These airspace feeds have nearly identical formats, with altitudes, detailed boundary definitions, and such. There are a few minor differences between the two, for example different…

but it was used in many places, so the rule of three applies.

Personally, I would have kept the code that he wrote and made something that handled the special cases you are talking about.

Everything should be replaceable, not extendable. Now if the special cases change, my code can be thrown away without changing the data feed code.

Re: Goodbye, Clean Code

#364

Post by werber » Sun, Jan 12, 2020, 9:28 AM UTC

If someone rewrites my code better than me, I feel like I owe them a beer

Re: Goodbye, Clean Code

#365

Post by mytailorisrich » Sun, Jan 12, 2020, 9:28 AM UTC

scarface74 wrote: post #25

burlesona wrote: post #10

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 ne…

That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…

Generic enough code that can be adapted to future cases is code with clean architecture that follows standard OO principles.

On the other hand, trying to handle all the hypothetical cases because "that makes the code generic and future-proof" is usually a complete waste of time.

My view is to develop the simplest, well architected OO code that can handle the use cases at hand.

Re: Goodbye, Clean Code

#366

Post by genezeta » Sun, Jan 12, 2020, 9:29 AM UTC

bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

> ...and you want to rewrite code I wrote...

I think the key to most of this situation is right there. It's also something the original author largely misses.

The key is this: want.

If you want to rewrite some code you find, then kindly leave that keyboard and go play with some toys. This, "wanting", is the actual origin of the author's anecdote. "I saw this and I thought it was bad and I felt the urge to rewrite it". Ok, but don't.

What is missing is knowledge on the circumstances of the code. You see some piece of code and you're only seeing that, the code itself. But why is it that way? Is this code supposed to be modified/extended/reduced/deleted in a near future? Frequently? Or simply, as a first question: Does this code need to be better?

And even if the answer is yes, then in what aspects does it need to be better? What does "better" mean for this piece of code? Did you want to just make it cooler looking because you didn't like it? Or have you actually detected that some of the needs this code was supposed to fulfil aren't being fulfilled? Of course, if you only now saw the code and do not know what those needs are then you're in no position to rewrite it, just because you want.

But then again, if there is indeed motive to rewrite it, by all means, do.

Following this idea will probably lead to having to ask, sure. But you won't be asking for permission, you'll ask because you need information before you can decide.

Re: Goodbye, Clean Code

#367

Post by blub » Sun, Jan 12, 2020, 9:30 AM UTC

bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

What projects is everyone working on that they have the time to keep rewriting each other's code all the time? :)

If such teams did code review, maybe they'd get it right on the first commit and would only have to refactor when the requirements change or there's a clear benefit.

Re: Goodbye, Clean Code

#368

Post by tragic » Sun, Jan 12, 2020, 9:30 AM UTC

jt2190 wrote: post #103

temac wrote: post #13

> A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I'm against the idea that people should be attached to "their" code (that is: the code they wrote). Now I also understand that humans that humans, but the priority should be to make them evolve toward more detachment from their…

> You should not take issue of your work being reverted (for good reasons), like other people should not take issue of "their" code being modified. Better ask for forgiveness than permission. Changing one developers _working code_ after they’ve invested a significant amount of time into without discussing it with the team first it is to basically heap on a number of unwritten requirements and also decide that the sch…

> If removing repetitive code is a requirement then the team needs to be informed that code will be reviewed for repetition, and introduced to various techniques for spotting and removing repetitive code.

Things like this are never requirements, at least in the conventional sense of 'things the stakeholders ask for the software to do'. Nor should they be: it's our job as professionals to know how to do our work. I don't want a PM or sales rep worrying about the Liskov substitution principle (unless I'm working for code climate or something): it's a waste of their time.

Code cleanliness should make future changes easier. Of course, some 'cleaning' expeditions do the opposite, so there should still be code review etc.

Re: Goodbye, Clean Code

#369

Post by mytailorisrich » Sun, Jan 12, 2020, 9:35 AM UTC

teh_klev wrote: post #196

burlesona wrote: post #10

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 ne…

> 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. This ^^^. I'm in my mid 50's now and worked as a software dev since my teens. I've learned over time that certain lumps of code need to be left alone for a while before jumping in and aggressively refactoring the perceived "duplicati…

This isn't about rudeness or courtesy unless they are responsible for that code, in which case they should be involved or leading the change.

As you mention it's about technical knowledge: They know exactly why the code is the way it is so consulting them is "due diligence".

Re: Goodbye, Clean Code

#370

Post by hising » Sun, Jan 12, 2020, 9:36 AM UTC

Mirioron wrote: post #198

burlesona wrote: post #10

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 ne…

I wonder if we could have IDE features that will make #2 less likely. Eg marking some lines of code that they're similar to lines of code elsewhere. And if you then change it in one place the IDE will remind you about the others.

JetBrains has something like this in their tools. It pointed me in the right direction a couple of times when touching code that is similar to something elsewhere.

https://www.jetbrains.com/help/idea/analyzing-duplicates.htm...