3 ms·
List the properties of an object. List the operations performed. Fill in the matrix. Remember it mostly by remembering your own failures. One should know about
by gostsamo 6y ago
List the properties of an object. List the operations performed. Fill in the matrix. Remember it mostly by remembering your own failures.
One should know about all versions of null and empty or overflowed, about stuff being too big, about operations being performed out of sync.
Maybe, the easiest is to ask yourself: What can go wrong? on every line of the code.
- twy30 6y agoThank you. Let me try repeating your advice in my own words: * Collect all assumptions (regarding data and actions). * Attack each assumption by throwing known/common/trivial edge cases at it. * Explore each assumption's necessary conditions: what they are ; how they could possibly be false/broken/absent.
- tudelo 6y agoThese seem like a good set of rules to follow. I would also add that in my experience once you get burned a time or two in production you start to develop a healthy level of paranoia and skepticism towards the code you write. I'm not sure if that step can be skipped, realistically we all create a dumpster fire here and there anyways. A healthy code review process helps as well.
- twy30 6y agoThank you. I like your idea. Let me try putting it into a bullet point form: * Get/give healthy feedback to mitigate against tunnel vision or unknown unknowns. * Learn from failures and mistakes.
- gostsamo 6y agoYes, something like that. With the caveat that we have really deep assumptions about the world and something will always surprise you. Be ready to learn from many past mistakes.
- kukkia7 6y agoCan you elaborate on what you mean by property of an object? Does operations performed mean all the function calls associated with said property(like some struct or class object??)