Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't be clever

stitcher.io

Post reply on HN
Print view View original

141–150 of 231 posts

Re: Don't be clever

#141

Post by tomjakubowski »

hgsgm wrote: post #114
jader201 wrote: post #97

Earlier quoted context omitted.

I've also seen "scaffolding" used to generate code that shouldn't be manually modified. E.g.: https://learn.microsoft.com/en-us/ef/core/managing-schemas/s...

That's someone who doesn't know what words mean. When a building is built, the scaffolding isn't an immutable part of the final product.

Well if we're being anal about the metaphor, in construction and renovation, the scaffolding eventually goes away. Scaffolded code rarely disappears entirely; some of it usually sticks around.

Re: Don't be clever

#142

Post by max_hammer »

firefoxd wrote: post #136

Right now, I'm working on two databases that almost do the same thing. One is legacy, the other is the new and improved. I can't delete the old one because there are several teams that generate their reports from it, I can't delete the new one because new functionality depends on it. When we add a new feature, we run update queries on both databases (but not always). We need several months of work and create training…

If both database have same schema and data migrating reporting tools to new tool should not be a big challenge.

Also, I would put other DB in keep the lights on (KTLO) and not provide any support or patches. You need to make your problem thier problem.

Re: Don't be clever

#143

Post by sfn42 »

robertlagrant wrote: post #76
Verdex wrote: post #47

Earlier quoted context omitted.

Making things worse, I suspect there's at least two (and probably more) definitions for 'clever' that are thrown around and the intent half the time is that one definition is masquerading as the other. One plausible definition for clever code is that it's code that only works because of a non-obvious dependency on some other fact being true in the code base or outside of the code base. Once the fact is no longer true…

The other option is "yes this works well and is very neat, but it's not going to withstand 5 years of people changing it and only reviewing the diffs."

Does anything withstand that? I don't think that's the responsibility of the original author, I think it is the responsibilities of all those devs and reviewers to make sure changes make sense and don't make the system worse.

Nothing can stop morons from ruining good code. Good devs will evolve code into something that makes more sense.

Re: Don't be clever

#144

Post by code_runner »

things like this always have some underlying notion that there are objectively correct combinations of lines of code. There isn't. The cleverness problem can live at any level in a system.... this line is really clever because in is really just a , so if we use this we actually can do this all in one line!

You can also have system level cleverness, which is fine as long as you can explain the cleverness in a few sentences. Sometimes the data access layer is clever and the other stuff isn't....

at the end of the day, as long as you leave things such that they are easy to change, or at least you're brave enough to change them, none of it really matters. Someone is going to replace the "clever" code with other code that does more or less the same thing, and then next engineer will replace that code with something else.

Re: Don't be clever

#145

Post by slifin »

Composer/PHP never really supported proper autoloading of functions

So everything is a class

The majorities language's community has this super weird Java obsession The other half has a Rails obsession

The best career decision I ever made was to watch the Rich Hickey talks

2x my wage in a few years and don't have to care about any of this obvious mis-match ever again

Re: Don't be clever

#146

Post by mcv »

raincole wrote: post #110
mcv wrote: post #95

Earlier quoted context omitted.

Generated code is fine if it's newly generated on every build. If you're going to have to maintain the generated code, it's not generated code anymore, but duplicated code.

Yes and the original article is about how duplicated code is ok. The discussion finally went the full circle.

The original article isn't very convincing though. I mean, I fully believe the single abstract super controller was a bad idea, but there are far better options than that and duplicate code. He's just comparing two of the worst ways to do it.

Re: Don't be clever

#148

Post by pachico »

I read this like "if I was was really clever back then I would do what now I think is clever" and my humble opinion about the ultimate solution for it really horrifies me (the class generator).

Maybe I'm not clever enough. Maybe I don't hate copy and pasting enough.

Re: Don't be clever

#150

Post by lolsal »

The only time being clever has helped me has been putting out a fire in production, to stop the bleeding, and to buy us time for implementing a better fix in the next release.

Being clever during feature development is a red flag to me. I’m a huge fan of the YAGNI principle.

Post reply on HN