A Philosophy of Software Design, 2nd Edition

Sometimes a little wordy, but great read for Developers or anyone building their own software

Book explains concept really well. This will change your perspective regarding code and help you to improvise your self while writing code.

Amazing book. Designing software systems are complex. There are many books and courses which teach software programming. But very few talk about design. This book is not a "How to" guide for software design, nor will it give you detailed design patterns. This book answers a profound question "What is a good software design?". This book, with many examples, gives us a fundamental understanding of good software design. I can confidently say no other software design book tackles software design as this book does. Highly recommended, and keep this book open when writing code.

Most of the causes of problems and the principles to address the problems can be applied to life as well. Reduce complexity by reducing dependencies and obscurity. Decide what matters and what doesn't and spend time on what matters

I read this book after reading Clean code and following Uncle Bob Martin for many year's! I got more out of this book because I had read Clean code and vice versa. So thanks to John Ousterhout and Uncle Bob Martin as well!

I bought this with high hopes, as the author is well respected, well known. I felt the content is too basic (simple) which anyone with a bit of experience in computer-science/software-engineering would already know!

Must read for IT professionals of all levels. Apt examples complementing every idea discussed by the author which makes it easy to follow, understand and remember.

I like the author's approach to the subject. He debunked most of the design myths by using simple examples and explained the process of decomposition.

「ソフトウェアの複雑性を下げる」は、設計の主要な目標ですが、これについて簡潔に包括的に書かれた本です。 深い(浅い)モジュール/名前の横断性/コメント規約/情報隠蔽(漏洩)など、古い設計手法も新しい視点で書かれています。 Linterや計測ツールを作りたくなりました。

Excelente

Possibly my favourite tech book ever. Unlike other "clean code" books, it's not just a collection of advice, it unfolds a real theoretical framework that embodies the perks it touts in good design: simplicity, concision, consistency and pragmatism. It felt like the author somehow found just the right abstractions to describe what we pursue in good code. All served by spot on mental models (deep modules, information leakage), simple yet precise language and telling examples.

It's an amazing book where you get insights about how to build and maintain a software design. It's technical, but not a heavy reading, which makes it even more enjoyable.

The book's examples are mostly from programs running on an OS, with significant iron underneath. I mostly work with embedded systems, which are severely resource contained, often running on bare metal with a limited thread scheduler. Still, I found the book being generic enough to be applicable for that niche as well. I completely agree with Prof Ousterhout regarding shallow methods, variable duplication and the like being red flags. He repeatedly re-iterates the importance of hiding implementation details, which is actually one of the stated goals of OOP, The book tries to drive a point through: your system's long-term manageability depends on its abstractions, how you partition the task at hand into self-contained chunks with minimum, or preferably no interdependence between them. Yes, it cost a a lot of design time without cranking out any code, but this investment will be paid back during the actual implementation, and, more importantly, during the lifetime of the project (which with embedded systems is often decades). I especially like his talking about commenting the code and how comments provide meta-information that the code does not convey. The code should be obvious, sure. You read it and should know what it does. But will you know why it does it the way it does? Often the code is written on a particular way to accommodate peculiarities of the underlying hardware, and it incorporates a lot of knowledge/mathematics of a completely different field that the device services. You might have it all in your head when working on the project, but expecting the next guy (or even yourself a few years later) to know it all is not realistic. Comments can point out all those externalities and provide a rational for particular, possibly counter-intuitive, design choices employed in the code. Overall, I think the book is an eye-opener, at least it should make you think about abstractions, interactions, separation, generalisation, and, the most important message of the book, minimising complexity.