This is my short list of ideas I’ve taken away from reading 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 anArrayList, 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!).