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
I usually call the KISS as Keep It Super Simple
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 š
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
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)
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.