I saw this article recommended to me a month ago. This article changed my life this last month. It triggered the 15 year old in me, during the days watching Avatar The Last Airbender, and my imagination kicked in: I transformed this article into an animated video production coming soon. And actually, it might make you shed a tear.
Great article. KISS and YAGNI principles are often underrated in software engineering, yet they are crucial for creating efficient and maintainable systems.
Great article! Thanks for the quick summary as I sometimes forget about these concepts.
But I have to disagree with the example for DRY in this case. When refactoring code, it'll be a nightmare to detect when someone is getting a given product property (because sometimes business wants to change names). By having explicit method names, a dev will get compile-time errors if they missed a method on the refactor.
Another point, the generic "god" method doesn't check for presence of the property. A dev might misspell or mis-capitalize the property name and will only find the issue at runtime.
Last, if additional logic is required for the getters, you'd think you could add the explicit getter back. This could potentially break encapsulation where you would want the user to only use your method to read or manipulate the data. Now there are 2 pathways for any user of the class to access the data which could cause unintended consequences (and a late-night debugging call).
I'd argue that it's best to use boring old getters/setters here which basically follows KISS. However I admit that worrying about the above might have gone into YAGNI territory
Thank you for sharing your thoughts, Scott! 🙏 Agree with what you said. As giving it another look, I guess the example is not 100% correct and may add some confusion.
As with every principle and rule, understanding its pros and cons is crucial because there're no silver-bullets. Sometimes, DRY may be an overkill.
Thank you for bringing that up, Jay. Indeed, sometimes DRY may harm more than help. I'm thinking of writing a follow up article about DRY vs. Decoupled code.
I usually call the KISS as Keep It Super Simple
Love it! Thank you for sharing, Ledion!
I saw this article recommended to me a month ago. This article changed my life this last month. It triggered the 15 year old in me, during the days watching Avatar The Last Airbender, and my imagination kicked in: I transformed this article into an animated video production coming soon. And actually, it might make you shed a tear.
Coming very soon 😊
Happy to hear that, Adept! It will be interesting to see the video once it's ready. ^_^
Great article. KISS and YAGNI principles are often underrated in software engineering, yet they are crucial for creating efficient and maintainable systems.
Thanks, Sagar! 🙏
Great article! Thanks for the quick summary as I sometimes forget about these concepts.
But I have to disagree with the example for DRY in this case. When refactoring code, it'll be a nightmare to detect when someone is getting a given product property (because sometimes business wants to change names). By having explicit method names, a dev will get compile-time errors if they missed a method on the refactor.
Another point, the generic "god" method doesn't check for presence of the property. A dev might misspell or mis-capitalize the property name and will only find the issue at runtime.
Last, if additional logic is required for the getters, you'd think you could add the explicit getter back. This could potentially break encapsulation where you would want the user to only use your method to read or manipulate the data. Now there are 2 pathways for any user of the class to access the data which could cause unintended consequences (and a late-night debugging call).
I'd argue that it's best to use boring old getters/setters here which basically follows KISS. However I admit that worrying about the above might have gone into YAGNI territory
Thank you for sharing your thoughts, Scott! 🙏 Agree with what you said. As giving it another look, I guess the example is not 100% correct and may add some confusion.
As with every principle and rule, understanding its pros and cons is crucial because there're no silver-bullets. Sometimes, DRY may be an overkill.
You missed my favorite etc, east to change.
YAGNI can be overrated - sometimes engineers need to show Product what is possible with their product. Anyway mine are:
Don’t extract an interface until you need to
Only DRY when you are nearly done and you have a ton of tests to defend against abstraction leaks. (Nearly done means the epic, not a story)
Long and explicit code is better than short and clever code
Keep methods short, but not too short (see above) - no more than one laptop screen
keep lines to 100 characters (it makes you write simpler code)
Invert control everywhere you can (it makes systems adaptable to change)
Use builders where a factory is tempting, and never use factories (they poison inversion of control)
Factories are ok in utility libraries
Don’t be afraid to break the ‘rules’. There are no rules, just like there is no spoon. (See above)
Thank you for sharing your thoughts, David! 🙏 These are great additions!
YAGNI is so underrated.
Loved the article Peter
I love the actionable simple tips you are adding here, Petar.
Simplicity and brevity is an art. Even in code. The more experienced you are the more you should be invested on those concepts.
In fact you don't level up unless you level up in your simplicity and brevity concepts.
DRY - Adds dependencies and promotes unintended consequences. If you modify shared code you can break code elsewhere that you know nothing about.
Your post, like most programmer narratives, only covers the happy path.
Thank you for bringing that up, Jay. Indeed, sometimes DRY may harm more than help. I'm thinking of writing a follow up article about DRY vs. Decoupled code.
Excellent! I look forward to reading it. Dependencies have been the bane of my existence.