3 ms·

I liked the books emphasis on "interface" vs "implementation", and how this affects complexity. But one tidbit I did like from the book was along the lines of

I liked the books emphasis on "interface" vs "implementation", and how this affects complexity. But one tidbit I did like from the book was along the lines of "if every use case involves the same action, it would be simpler to incorporate that action". (e.g. Something like if ".delete()" were to fail if the file didn't exist, and if every invocation would be like "if .exists() { .delete() }", then it'd be simpler to have a method without the "fail if file didn't exist" requirement).

austin-cheney 3y ago
That sounds like DRY, don’t repeat yourself. Taken to another level I try to think of this as instruction elimination. Where can I eliminate the most instructions, still pass all my tests, and then compare execution speeds? Instruction elimination and DRY are basically the same things in practice but the former produces a more aggressive and utility focused mindset. I find when I think about large applications with instruction elimination mindset I am constantly churning on refactoring as requirements increase but the code size grows so very slowly that there is less to maintain and test automation continues to be measured between less than 7 seconds and up to 2 minutes depending upon the scenario and number of machines involved.