How strongly do I recommend A Philosophy of Software Design?
5 / 10
The first 100 pages of A Philosophy of Software Design are solid and worth reading. These first 100 pages feel like a primer for Clean Architecture.
However, the final 70 pages are filled with recommendations about code comments that I find hard to support. Most of the examples the author provides of useful comments could easily be replaced with better named variables and methods. Because of this poor advice, I can’t recommend this book for junior engineers.
Rather than read the last 70 pages, I would recommend Clean Code or Code Complete.
We should strive to build modules that solve problems completely.
Solving a problem completely comes from having deep functionality. And in the best modules, the deep functionality is hidden behind a simple interface.
jQuery was a deep module – it solved a problem completely and contained deep functionality hidden behind a very simple interface.
As a budding developer, using jQuery extensively taught me the importance of simple interfaces in driving adoption of your code.
The author makes a solid case against classitis – the compulsion (particularly in the Java community) to split everything into a new class.
But by splitting into new classes, you’re driving toward shallow modules. You’ve actually introduced complexity in the name of simplicity.
When you’re performing a code review on a class, smell around for special purpose code mixed with general purpose code. This mixture represents an opportunity to split off the general purpose code into something more reusable.
As an engineering manager, I strongly advocate and sometimes even insist on designing systems twice or even three times.
Let’s say we’re designing the database tables for new functionality. I will often say things like:
I play devil’s advocate because I want my engineers to really think through and justify their design decisions, especially when those decisions involve data storage because data structures are unlikely to change once created.