I have to disagree with the first point in the article. The “zero, one, many” rule, or the related “rule of three” isn’t about how many items you have in your list, it’s about code reuse. The conclusion is correct though, that you should default to one:many relationships unless you know they are strictly one:one
Yagni Exceptions (2021)
61–70 of 214 posts
Re: Yagni Exceptions (2021)
#62Earlier quoted context omitted.
It's only bad if you read "YAGN Exceptions"
But this would be very good advice! Exceptions (a.k.a. modern-flavored COMEFROM statements[0]) are extremely confusing and have no place in a clean codebase. [0] https://en.wikipedia.org/wiki/COMEFROM
Exceptions do not specify from where exactly they should “come from” and are two-way protocol akin to setjmp/longjmp. Situations where exit through few levels of stack is required do happen regardless of code cleanness, and the only alternative is to pair every call with a flow control statement, turn primary return value into a status, and add two out-arguments for error and result. Some people love this, some not really.
Re: Yagni Exceptions (2021)
#63Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…
Multiple tables are the way to go with SQL, you'll need multiple tables all over the place. So if multiple tables give you a “wrong” feeling, I argue that the feeling is wrong for the technology.
It would be very normal to have tables as follows:
* Table "users" with an "id" column and some additional data about the user.
* Table "skills" with an "id" column and some additional data about the skill.
* Table "user_skill" with columns "user_id" and "skill_id" (and the corresponding foreign key constraints).
Re: Yagni Exceptions (2021)
#64YAGNI is not an excuse to take lots of shortcuts against known good implementation patterns. Second guessing years of people doing things right by naively assuming you won't need something is more likely to be a mistake than it is not. Do it properly the first time. Actively creating technical debt against your better judgment is silly.
> YAGNI is not an excuse to take lots of shortcuts against known good implementation patterns.
I’d say it is, because “best practices” and “patterns” are usually context dependent and will have a negative cost when applied when not needed.
Re: Yagni Exceptions (2021)
#65* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.
I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plu…
I might have something for you that reduces context switching. I am working on an IDE extension that shows the content of a localized message inline. A screenshot can be found here https://github.com/inlang/inlang#vs-code-extension.
Re: Yagni Exceptions (2021)
#66* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.
I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plu…
These patterns and practicee generally aren't intend for _you_ as the developer of the app right now.
They are intended for the poor shmuck 18 months later who has to work with a tangled mess of copy text stored in JS, server side yaml files and a CMS.
I've been that person at least 3-4 time now. I've waded through changes where having static strings got the UI would have simplified things immensely, and _none_ of these have had anything to do with internationalisation.
They have been far more prosiac (Legal request, product changes, rebranding, just general things like "where did this text under interest rate calculator come") but have still taken significantly longer than they should have.
When you are writing these apps it can feel like it's not that hard to go back later and pull out strings, just some grunt work.
But once you munge your code through three refactors and a framework change it becomes so much harder.
Re: Yagni Exceptions (2021)
#67Should maybe add security and privacy to that list, in this day and age. Not that it all needs to be implemented right away (depending on jurisdiction you're operating under) but having a plan for how to solve security and privacy considerations and working with that in mind from the start can make it a much less painful experience in the long run.
You are correct. How would you distill this in to a handful of elements akin this submission?
I probably wouldn't, since it is very use case specific what concerns are relevant. So more a suggestion to get an overview of the security requirements and privacy requirements one needs to deal with at some point and sketch some possible ways to make those requirements easy to solve when the time comes.
Examples of things to consider: zero trust, multi tenancy, permission structures, user data classification (for GDPR removal/extraction requests).
As a European, GDPR has far reaching consequences that may even dictate what other services you rely on. I.e. can you use that SaaS service for your product when it's located outside of the EU/EEC?
Re: Yagni Exceptions (2021)
#68* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.
Sure, but what if you never need to internationalize? Introducing a level of indirection have a cost. This is exactly why YAGNI applies. Refactor the code to support a requirement when the need arises .
Exactly.
Better imo: Don't use strings but a proper datastructure/wrapper. Later, if you want to add i18n, then change `Wrapper("Hello, welcome to the future")` into `Wrapper("Hello, welcome to the future", "welcome-user")` and just look for all wrappers to find all places.
Benefits: it's easy to find the code with a simple ctrl+f from the English version of the site and you don't have any disadvantage except for having the English translation (or whatever primary language you choose) inside the code and the other translations in mapping somewhere else.
Re: Yagni Exceptions (2021)
#69> More generally, instead of a boolean flag, e.g. completed, a nullable timestamp of when the state was entered, completed_at, can be much more useful. In my experience, the timestamps should almost always be entered in addition to the flag. select * from data_journal where status = 'Loading' is much easier to write and understand than select * from data_journal where started_loading_at is not null and finished_loadi…
If you have to answer: "does it usually take so long or is something broken?" The Timestamps would be handy. Oh and you can estimate an average for the execution time; investigate performance degradation or improvements
Yes, that's why I've written it's better to have both.
Re: Yagni Exceptions (2021)
#70Regarding the point about having a relational database: I was of the same opinion, but recently it has been challenged. We were working on a very simple application and one of the first requirements was: > User should be able to have a list of skills (e.g., Golang, Java, OOP, etc.). Users can be filtered by list of skills as well (e.g., "give me all the users with the skills "Java" and "OOP" but not ".net") So, the n…
Multiple tables are the way to go with SQL, you'll need multiple tables all over the place. So if multiple tables give you a “wrong” feeling, I argue that the feeling is wrong for the technology. It would be very normal to have tables as follows: * Table "users" with an "id" column and some additional data about the user. * Table "skills" with an "id" column and some additional data about the skill. * Table "user_ski…
I have also done this many times but I think GP has a point. This model needs more code, and a hassle when you're just trying to get something working.