3 ms·

Basically saying that don't use numbers because somebody might write crap code and it'll get run on your deployment database?! If getting such dangerously awfu

Basically saying that don't use numbers because somebody might write crap code and it'll get run on your deployment database?! If getting such dangerously awful code deployed to production is likely then sequential IDs are just one of your many problems! Sequential IDs for key data can be good to avoid for a few good reasons but awful code isn't one of them. Testing, code reviews and not having bad programmers should be in place to fix that.

danpalmer 8y ago
All programmers make mistakes. I think the mark of good software design is using practices that make it impossible or much more difficult to make the mistakes that we know are going to be made at some point. Much of our code review is not about "is this code correct" - that's obviously important, but rather "will this be easy to review changes to in the future" or "if I came back here in a year, would I get it wrong". I think that's just as valuable. There's always a trade-off with complexity, and I'm not sure whether this one pays off, but designing _for_ programming errors is important for any team/company/product that is growing, and will introduce new developers who weren't around when the decisions were made.
- Chyzwar 8y ago
  I would reject PR that introduce code like this. I disagree with the article. You should not introduce "safeguards" as described in the article. In few years time, someone will make bug assuming that users id starts from 1. Instead, you can write this as (js): banSendersOfMessages(messages) { messages .forEach(({senders}) => senders.forEach(banAccount)); } In the ruby community, there is the principle of least surprise. Your design you should not introduce astonishing things.
tigershark 8y ago
You have to assume that a bug is the normality, not an exception. The more safeguards you put to make illegal state unrepresentable and illegal code uncompilable the better is it.
andrewflnr 8y ago
The author was an SRE at Google IIRC. Google has a pretty decent code review and testing culture. However, even if you have a process that eliminates 99.9% of the moronic mistakes like this, that kind of scale still makes it a certainty that stuff like this will get through occasionally. She still has to try to keep the service running. That's the perspective from which she's writing.
eesmith 8y ago
How do you draw the conclusion that the author is saying "don't use numbers because somebody might write crap code" when one of the suggested improvements was "to use a large key space, like the 64 bit integers (or perhaps the subset which can be represented by Javascript, sigh)" int64 are numbers, so the author cannot be saying "don't use numbers". Instead, it's specifically numbers generated by something like an auto-incrementing primary key in the database.
dominicr 8y ago
OK, some fair comments there. For me the article's negative was that it focused on one edge case reason to not use IDs, when there are others. While everyone makes mistakes I'd hope that using an array's size instead of its value is nigh on impossible to end up committed, let alone deployed to production. As everyone makes mistakes for me the main reason for not using numeric user ids is because you're much more likely to accidentally expose an API or query string param that can be used to look up other user ids. When that happens being able to enumerate ids makes for a massive data breach, whereas a GUID stops that. (There may be some reason why you'd be forced to use numeric IDs in a data store for performance at scale reasons but I imagine that's relatively rare.)

danpalmer 8y ago

All programmers make mistakes. I think the mark of good software design is using practices that make it impossible or much more difficult to make the mistakes that we know are going to be made at some point. Much of our code review is not about "is this code correct" - that's obviously important, but rather "will this be easy to review changes to in the future" or "if I came back here in a year, would I get it wrong". I think that's just as valuable. There's always a trade-off with complexity, and I'm not sure whether this one pays off, but designing _for_ programming errors is important for any team/company/product that is growing, and will introduce new developers who weren't around when the decisions were made.

Chyzwar 8y ago
I would reject PR that introduce code like this. I disagree with the article. You should not introduce "safeguards" as described in the article. In few years time, someone will make bug assuming that users id starts from 1. Instead, you can write this as (js): banSendersOfMessages(messages) { messages .forEach(({senders}) => senders.forEach(banAccount)); } In the ruby community, there is the principle of least surprise. Your design you should not introduce astonishing things.

tigershark 8y ago

You have to assume that a bug is the normality, not an exception. The more safeguards you put to make illegal state unrepresentable and illegal code uncompilable the better is it.

andrewflnr 8y ago

The author was an SRE at Google IIRC. Google has a pretty decent code review and testing culture. However, even if you have a process that eliminates 99.9% of the moronic mistakes like this, that kind of scale still makes it a certainty that stuff like this will get through occasionally. She still has to try to keep the service running. That's the perspective from which she's writing.

eesmith 8y ago

How do you draw the conclusion that the author is saying "don't use numbers because somebody might write crap code" when one of the suggested improvements was "to use a large key space, like the 64 bit integers (or perhaps the subset which can be represented by Javascript, sigh)" int64 are numbers, so the author cannot be saying "don't use numbers". Instead, it's specifically numbers generated by something like an auto-incrementing primary key in the database.

dominicr 8y ago

OK, some fair comments there. For me the article's negative was that it focused on one edge case reason to not use IDs, when there are others. While everyone makes mistakes I'd hope that using an array's size instead of its value is nigh on impossible to end up committed, let alone deployed to production. As everyone makes mistakes for me the main reason for not using numeric user ids is because you're much more likely to accidentally expose an API or query string param that can be used to look up other user ids. When that happens being able to enumerate ids makes for a massive data breach, whereas a GUID stops that. (There may be some reason why you'd be forced to use numeric IDs in a data store for performance at scale reasons but I imagine that's relatively rare.)