4 ms·
> A common failure mode I've noticed is that people only test the functionality they've added and not other parts of the system that may be affected. This fai
by justin_oaks 3y ago
> A common failure mode I've noticed is that people only test the functionality they've added and not other parts of the system that may be affected.
This failure mode often comes from parts of the system being coupled when they shouldn't be, or it's not obvious that they are.
Have you ever had a change to a logging statement break cause some other code to stop functioning? I have. And I was thoroughly disappointed by the person who made a logging statement have any effect outside of logging.
Clean code needs to adhere to principles such as the Principle of Least Astonishment[0], otherwise code is bound to break when other people modify it.
[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
- throwaway2037 3y agoAbout "Principle of Least Astonishment": In theory, it is cool. In practice, it is often used by gate keepers to shutdown newbies. After seeing that behaviour too many times, I stopped using the term. A nicer way to say it (from pair programming ethos): If someone asks you a question to clarify some code, then it needs a comment (or a re-write/re-factor). Note that I didn't say anything about the experience level of the asker. One more thing: I've met (multiple) people who are firmly in the "Convention over configuration" camp and the "Principle of Least Astonishment" camp and cannot understand how new joiners are continuously surprised by this or that convention.