4 ms·
In the mid-2010s I worked at a company that switched from using raw ints to refer to database rows to using (in C# terms) "Id<FooTable>". Across the entire cod
by ThePadawan 4y ago
In the mid-2010s I worked at a company that switched from using raw ints to refer to database rows to using (in C# terms) "Id<FooTable>".
Across the entire codebase, we discovered an entire class of bugs that only never cause any issues because all the important rows in all the important tables had Id 1 (e.g. Currency 1 was USD and Country 1 was USA) - so in a few places where the ints got mixed up, the correct row was still accidentally looked up in the wrong table).
- russianGuy83829 4y agohow did that work out in the end?
- ThePadawan 4y agoI mean, no problem ever occurred. Things just accidentally worked even though they shouldn't, and that isn't a bug. The introduction of the additional types everywhere did turn into massive headaches based around dependency management and versioning. So overall, I was personally disappointed in the results, but nevertheless happy to work with less "icky" feeling code.
- Waterluvian 4y agoOh wow. Was there a “stomach sank to the floor” sudden feeling upon discovery?
- ThePadawan 4y agoNot really. The whole thing was kept together with tape and silly string anyway, and I bet it still is now, more than 5 years on.
- macintux 4y agoSomething I learned long ago, but occasionally disregard to my peril: if you see something that looks like a bug, but the code/system still works, stop and figure out why it works. It's very easy to mentally shrug and move on, but more often than not it comes back to bite you; maybe it's a code path that's rarely triggered, e.g.
- Winsaucerer 4y agoI have the same policy for similar circumstances. Sometimes, something isn't working, and I make a change that fixes it, but I didn't expect that change to fix it. Almost always it's worth me investigating why it's now working, because it indicates a deeper problem that would come back to bite me.