You've yourself here. You can not predict how it wull change. Which means that whichever design for change you've made, may just as well completely miss the future utilization

Which doesn't mean that we shouldn't design for change at all... Just saying.

[–] [email protected] 7 points 8 months ago* (last edited 8 months ago)

You can build your systems with as few assumptions as possible. The fewer assumptions you make, the less probable it is that any of your future assumptions will conflict with your previous assumptions. Your code will be built for change.

If your API call to some external system assumes the existence of a particular button in the UI, then your system isn’t built for change. Maybe you want to change this button? Then you need to go through all places in the code that relies on this particular button to see if it doesn’t conflict with any of their assumptions.

[–] [email protected] 6 points 8 months ago

As long as loose coupling, and separation of concerns are well tinkered into your application you minimise risks of breaking everything on a restructuring.

If you have for example shared state leaking everywhere into the program, your most probably doomed on the slitest changes.

I am not saying you're wrong, but there are ways to mitigate the risks even without knowing what will happen in the future.

[–] swordsmanluke 5 points 8 months ago (1 children)

Just saying.

.... Saying what, exactly?

I said that we should

design for change
"within reason"
because we can't know what exact changes are needed.

And you argued... The same thing? Just in the reverse order?

[–] [email protected] 1 points 8 months ago

Seems like he's worried you'll Java everything up, which can be valid.

I think a good, easy example is whether your application should allow a selection of databases or be tied to one database.

You can make arguments for either, often (but not always) regardless of your use case.

[–] [email protected] 2 points 8 months ago

You can design it to be changeable at all, though.

In the simplest case that's just proper abstractions. You can't change details in the rest controller, if the persistence layer absolutely needs to call methods from the rest controller for no reason.

Finding the right balance between YOLO and YAGNI is almost impossible to get right. But you can at least try not to land on the extremes.