Code generations is just metaprogramming. The worst case, where you have to compile twice. The first one to generate the code and the second to compile the generated code.
Don't be clever
121–130 of 231 posts
Re: Don't be clever
#122The issue at hand is not about cleverness. Code was devised to address a specific problem (DRY), which it did quite elegantly. Then, the situation evolved, rendering the solution inappropriate. When a controller starts to deviate from the standard approach, it's best to refrain from inheriting from the base controller and instead create custom ones. Once all controllers operate independently, the base class can be sa…
Experience will tell you that this happens often, and it’s often better not to DRY in the first place.
If there is no process for re-evaluating code architecture choices, it can create challenges regardless of the approach taken.
Experience tells me that relying on copy+paste as a solution isn't a cure-all, or even a better approach, and often introduces new problems in the future. A thoughtful and adaptive approach to code development is crucial to ensure long-term success and maintainability.
Re: Don't be clever
#123Earlier quoted context omitted.
So much about programming in a larger sense is just getting abstractions correct. Too loose and they don't standardize/remove enough boilerplate. Too strict and they break or multiply when changes are needed. I am curious, since my own backend experience is limited (obviously there will be many opinions on this) but it seems to me like his mistake was using the inheritance of classes. If he had simply had a CRUD laye…
In my view, there's duplication that could use an abstraction and duplication that is merely coincidental. (See The Wrong Abstraction by Sandi Metz [1]) Unless something screams "this should be the single source of truth about this" forget abstracting all together and just copy and move on. The problem with trying to create 1 "CRUD controller" is that there are always going to be hairy things that make parts one offs…
Thank you for that link, I've never heard that but it's definitely going to be one of the new things I meditate on quite a bit. Especially combined with the concept of all "all abstractions are leaky"
If you're designing a backend service that has multiple "heads" - say, a web application and a mobile application. Then it makes sense that service should be code that manipulates the database(s) via business logic, and at the very least should be in one place.
But broadly, programmers do see value in abstracting interacting with the DB at least somewhat. It's why ORMs exist.
I don't know if there's a real answer. An abstraction can be right for a while and then become wrong when you add a new requirement right? So is it pointless to use abstractions at all? That definitely feels like the wrong takeaway. I guess instead, it's don't immediately abstract out anything that feels abstractable when writing new code and don't feel obliged to use existing abstractions in a codebase until you're sure they fit what you're doing.
Re: Don't be clever
#124I have swung both ways and I think I now settle somewhere near "boring is good" and "repetition is harmless (compared to the astronomic costs of wrong abstraction)". Especially repetition seems to be hated with the might of a thousand suns and while I get it, because I myself hated it, I now can see the beauty of it. What is currently a superficial repetition - a bunch of endpoint handlers, some forms - will often tu…
I feel the same way. Repetition is fine when you're working within a solid, well established framework. If you're writing 100s of GET endpoints, and most of them requires you to prefix your endpoints withs some @GET and @RequriesToken decorators, so be it.
If there are other forms of repetition within the user-code, there are ways of dealing with it. But writing a super class to solve superficial code repetition is most often the wrong way to go.
Re: Don't be clever
#125Earlier quoted context omitted.
I hate repetition because it's nearly always laziness - it takes less thought/time to copy and paste a few lines of code than it does to factor them out into a reusable function and decide where to put it (and with what name). I'm taking about scenarios where the business logic needs to be exactly the same in both cases, there just happens to multiple ways to reach that point. On the other hand I also hate having to…
If the function grows like you describe it's because the developers are doing bad work. Instead of extending the function into a monster it should be split appropriately according to the new requirements. In some cases it may end up being multiple classes and that's fine. What isn't fine is cramming multiple classes worth of complexity into one function just because it almost did what you needed.
> If the function grows like you describe it's because the developers are doing bad work.
Exactly. Evolving a nice function into one that accepts lots of arguments is a product of the same mindset that copy-pastes code.
Re: Don't be clever
#126Earlier quoted context omitted.
Yeah, you've hit the nail on the head—no one got rich selling a book called "There Is No Magic Bullet: Everything Sort of Depends"
Now I'm tempted to write that book, maybe it could work. Find examples of things people desire and write the simple 'common knowledge' rules to achieve it, acknowledging the role of bad/good luck. Want to be healthy, in good shape? Get lots of sleep, eat well, exercise. Unless you suddenly get cancer. Want to be rich? Work a steady, boring job that pays well and live below your means. Unless a financial disaster occu…
Honestly I think that would be a really interesting book! It could be case studies of people who were 100% invested in a "system," but found that they got just as good (or better) results from following common sense guidelines and not sticking to them too rigidly.
Re: Don't be clever
#127I never heard about class generators before, could someone please point me to some resources to learn more about it?
Re: Don't be clever
#128Earlier quoted context omitted.
that’s the danger. you built a system for cogs. someone hired a thinker.
Eh, in this case your "thinker" sounds kinda dumb to me.
we aren’t disagreeing.
thinking isn’t always smart. being a cog isn’t always dumb.
sometimes the smartest thing to do is understand how a system is built and accept that until you understand it, you should learn about it. as a cog.
Re: Don't be clever
#129I would frame this as:
1. Make sure there's always a trap-door where you can implement special cases
2. A good way to always have (or to create) a trap door is to compose out of smaller pieces; then if you need something to be different in one case you just "reassemble it" with pieces added, removed, or rearranged
In the author's case, maybe CRUDController's key pillars of functionality could be broken out, still bundled together as CRUDController for normal cases, but then for special cases they could just assemble custom solutions out of those pieces instead of bending CRUDController into shape
Re: Don't be clever
#130While I agree with the sentiment to keep things simple, I feel that saying "don't be clever" is just a way for developers to sound actually clever. :-D