3 ms·
Yes, but all the "don't care" stuff needs to be inside a "don't care" module. For example, I don't actually care about GUI code. I just need "pressing this butt
by globular-toast 2mo ago
Yes, but all the "don't care" stuff needs to be inside a "don't care" module. For example, I don't actually care about GUI code. I just need "pressing this button emits this event or callback etc". If the GUI module interface is well defined then it doesn't matter how it's implemented as long as it works.
The problems start when you don't have clean separations. If your GUI code is also implementing ad hoc business logic like policies and workflows etc then you won't know what you care about and what you don't.
So you need to build little ring fenced enclaves where you can say "do whatever you want to implement this interface with this behaviour". If it gets fucked up you could just throw away the whole module and start again.
- dave_sid 2mo agoExactly. I think this is it. Clearly separate what must be perfect and well understood (security, business logic), from bits that you are happy to throw some code at and see if they work. And don’t let the latter get its hands on the former. I think going back to OOP principles and SRP/separation of concerns can make this work. Just some conscious planning needed rather than handing over the reins entirely.