Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Well at least you didn't beat them with a book.
One thing I always wonder is, does that person even ... know there are other options?
Like I haven't worked anyplace where I was involved in regular code reviews but I was sitting with some folks over beers once and someone who worked elsewhere went off about some n00b and they did something and I dared as "Yeah but do they know it could be done differently?"... and dude who was upset about n00b had no idea.
Now if someone is told and doesn't do it better WTF, but someone's gotta tell them.
I mean I had to look up these two patterns... -
@N00bPancakes
The beatings are figurative, I assure you. It's all covered in our onboarding classes. Some people are just lazy 😋 -
I have to admit Ive never seen such way of building code.
Which context this is useful? Do you know some article that would explain this? -
@WorstVarNames
This is the best resource for most versions of the pattern. As mentioned, it's useful when your configuration is complex or unclear:
https://amazon.com/dp/0321712943/...
You can probably also find portions of it plagiarized heavily on sites like geeks for geeks, medium, etc but the veracity will be questionable. -
@FrontEndLove
Yes, though it's equally valid js in the case of the builder example -
@SortOfTested ahh makes sense, the syntax looked familiar to me so thats why I think its typescript
While reviewing a PR from one of our newer FE devs, I ended up spending more time than I would like mulling over its composition. The work was acceptable for the most part; the code worked. The part that got me was the heavy usage of options objects.
When encountering the options object pattern (or anti-pattern, at times) in complex scenarios, I have to resist the urge to stop whatever I'm doing and convert it to the builder pattern/smack them in the head with a software design manual. As much as I would like to, code janitor is one of the least valuable activities I engage in daily, and consistently telling someone to go back to the drawing board for work that is functional, but not excellent is a great way to kill morale. Usually, I'll add a note on the PR, approve it, add a brown bag or two on that sort of thing, and make attendance mandatory for repeat slackers. Skills building and catharsis all rolled up in a tiny ball of investing in your people.
Builders make things so much cleaner; they inform users what actions are available in a context; they tend to be immutable, and when done well, provide an intuitive fluent interface for configuration that removes the guesswork. As a bonus, they're naturally compositional, so you can pass it around and accumulate data and only execute the heavy lifting bits when you need to. As a bonus, with typescript, the boilerplate is generally reduced as well, even without any code generation. And they're not just a dumping ground for whatever shit someone was too lazy to figure out how to integrate into the API neatly.
They're more work in js-land, sure; you can't annotate @builder like with Lombok, but they're generally not all that much work and friendlier to use.
rant
your uncle
javascript
typing the things
typescript
bob
builders