3 ms·
Yes, this book is excellent. And it's an antidote to some common advice that really isn't very good.
by garethrowlands 3y ago
Yes, this book is excellent. And it's an antidote to some common advice that really isn't very good.
- burhanrashid52 3y agoYeah I feel the same. Its more of a philosophy. Its good to learn but hard to implement in this fast pace development process. It make sense if you have big team which job is to assess the quality of the code
- rgoulter 3y agoI 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 agoThat 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.