3 ms·

Absolutely, there are definitely many ways this could've been prevented (such as the builder pattern you mentioned). I guess the point of the article is to sho

Absolutely, there are definitely many ways this could've been prevented (such as the builder pattern you mentioned). I guess the point of the article is to show that many bugs I've encountered aren't due to a bad initial design but because of additional requirements that get added later, resulting in new code that doesn't play well with the old code. Additionally, developers are generally trying to Get Things Done (and quick), so a lot of times you have to make a situational call to either 1) just modify the existing code to add the new needed functionality and accept the tech debt, or 2) spend extra time rewriting the whole class. There aren't really any good metrics (that I know of) that can definitively tell you when it's time for #2, I guess it's just intuition based on bad past experiences (like this one)? I remember having access to the new (ish) Time API and Streams and stuff, so it was definitely at least Java 8, but alas no Records. P.S. thanks for reading!

kelnos 5y ago
> many bugs I've encountered aren't due to a bad initial design but because of additional requirements that get added later I only sorta agree with that. The initial design here wasn't great, either. While the multiple constructors likely more or less handled the various cases properly, it was still a recipe for future mistakes. And that's the kind of thing I try to drill into the heads of junior developers during code reviews. Instead of solely thinking about the problem at hand, they need to think about how the code they write might need to be changed in the future, and guard against possible mistakes and misuse. No one will ever be perfectly prescient, but we can at least try. Sometimes there's no substitute for experience here, though. I do agree that additional requirements added later can put us in a bad spot. But I think if we examine why that is, though, we have to demand more rigor when these kind of updates happen. I get that there's often some urgency to adding these sorts of things, but that update would never have passed review by me. I would have insisted that the code be refactored so constructing that class would have been safe by design. I get that it's not really the "fault" of the person making the change ("oh, the code was like that already; I'm just adding something to it"), but that's not really the point. The changes made an already not-particularly-safe interface and made it even more unsafe to the point that the change actually broke things.

kelnos 5y ago

> many bugs I've encountered aren't due to a bad initial design but because of additional requirements that get added later I only sorta agree with that. The initial design here wasn't great, either. While the multiple constructors likely more or less handled the various cases properly, it was still a recipe for future mistakes. And that's the kind of thing I try to drill into the heads of junior developers during code reviews. Instead of solely thinking about the problem at hand, they need to think about how the code they write might need to be changed in the future, and guard against possible mistakes and misuse. No one will ever be perfectly prescient, but we can at least try. Sometimes there's no substitute for experience here, though. I do agree that additional requirements added later can put us in a bad spot. But I think if we examine why that is, though, we have to demand more rigor when these kind of updates happen. I get that there's often some urgency to adding these sorts of things, but that update would never have passed review by me. I would have insisted that the code be refactored so constructing that class would have been safe by design. I get that it's not really the "fault" of the person making the change ("oh, the code was like that already; I'm just adding something to it"), but that's not really the point. The changes made an already not-particularly-safe interface and made it even more unsafe to the point that the change actually broke things.