diff options
Diffstat (limited to 'content/posts/2022-02-11-philosophy-software-dev.smd')
| -rw-r--r-- | content/posts/2022-02-11-philosophy-software-dev.smd | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/content/posts/2022-02-11-philosophy-software-dev.smd b/content/posts/2022-02-11-philosophy-software-dev.smd new file mode 100644 index 0000000..6319350 --- /dev/null +++ b/content/posts/2022-02-11-philosophy-software-dev.smd @@ -0,0 +1,28 @@ +--- +.title = "Book - Philosophy Of Software Design", +.author = "Martin Ashby", +.date = @date("2022-02-11T19:18:07Z"), +.layout = "single.shtml", +.custom = {"comments": true}, +--- + +This is my short list of ideas I've taken away from reading [a Philosophy of Software Design](https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design) by John Ousterhout. + +* All the following advice is to be taken in moderation and with consideration for individual circumstance. Taking anything to it's logical extreme usually results in poor outcomes. +* Complexity is the enemy of understanding. +* 'Deep' interfaces are better than 'shallow' ones. Practically this means: keep your interfaces as simple as possible, and contain/handle the complexity in the implementation. Prime example was the linux/unix file system API. +* Spend time on design. Consider alternatives, discuss them with colleagues. +* Choose accurate, consistent names. +* If a reviewer doesn't understand your code, it is not clear enough. Listen to them, and make it clearer somehow. + +I agreed very strongly with all of the above. The idea of 'deep' interfaces expresses something I have been previously unable to express succinctly, and I will try to apply this in my own code and reviews. I also think I will try this tip: + +* Write comments/documentation _first_, i.e. while you are designing. This helps to find high-level problems in the design, before you have already spent time coding it. + +I disagreed on some minor points: + +* in section 8.2, it is advised to avoid configuration parameters. They are an indication that your system isn't handling complexity, and shifting responsibility to the operators of the system. In general, I think it's much better to: 1. make everything configurable (within reason) and 2. provide sensible defaults for the most common cases. The author recommends auto-tuning parameters, however I think this is overkill in most cases, and also takes away control from the operator or user of the software. +* In section 18.2, it is advised to always use the same type for variable declaration and allocation. The author gives the example of a local variable declared as a `java.util.List`, but instanciated as an `ArrayList`, and cites differing performance characteristics as a potential hazard for users of the variable. I think this example is poor; it sounds like premature optimization, and it risks users of the variable using implementation-specific methods and making it more difficult to e.g. change the type of the list later. +* In section 19.3 the author asserts that unit tests have the greatest coverage, and are therefore the best tool for uncovering bugs. I think this is something where YMMV. It really depends on the quality of the unit tests, and the most typical sources of bugs in your application. I think (although I can't prove) that _most_ bugs are found in the interactions of multiple modules, and unit tests will not catch those as they are (by definition) only testing one module. + +I would recommend this book to pretty much all software developers at any level. I think everyone in software could find something to take away and use in their work, to the benefit of their projects (and colleagues!). |