A Philosophy of Software Design, 2nd Edition
$22.95
Related Products
This book addresses the topic of software design: how to decompose complex software systems into modules (such as classes and methods) that can be implemented relatively independently. The book first introduces the fundamental problem in software design, which is managing complexity. It then discusses philosophical issues about how to approach the software design process and it presents a collection of design principles to apply during software design. The book also introduces a set of red flags that identify design problems. You can apply the ideas in this book to minimize the complexity of large software systems, so that you can write software more quickly and cheaply.
Publisher : Yaknyam Press
Publication date : July 26, 2021
Language : English
Print length : 196 pages
ISBN-10 : 173210221X
ISBN-13 : 978-1732102217
Item Weight : 10.2 ounces
Dimensions : 6.5 x 0.45 x 8 inches
Best Sellers Rank: #13,621 in Books (See Top 100 in Books) #3 in Software Development (Books) #4 in Microsoft Programming (Books) #20 in Business Technology
Customer Reviews: 4.5 4.5 out of 5 stars (2,594) var dpAcrHasRegisteredArcLinkClickAction; P.when(‘A’, ‘ready’).execute(function(A) { if (dpAcrHasRegisteredArcLinkClickAction !== true) { dpAcrHasRegisteredArcLinkClickAction = true; A.declarative( ‘acrLink-click-metrics’, ‘click’, { “allowLinkDefault”: true }, function (event) { if (window.ue) { ue.count(“acrLinkClickCount”, (ue.count(“acrLinkClickCount”) || 0) + 1); } } ); } }); P.when(‘A’, ‘cf’).execute(function(A) { A.declarative(‘acrStarsLink-click-metrics’, ‘click’, { “allowLinkDefault” : true }, function(event){ if(window.ue) { ue.count(“acrStarsLinkWithPopoverClickCount”, (ue.count(“acrStarsLinkWithPopoverClickCount”) || 0) + 1); } }); });
Mr. Bikes, Books, Music, Watches, Tech, Stocks –
Just read it. It’s short. It’s great.
I think every person who has written a fair amount of code should read this book. Managers should buy it for their teams. It should be required reading for new team members (it doesn’t long to get through – a few hours).It is NOT for beginner programmers in my mind – you will not have written enough code to understand the points being made. I’d say it’s perfect for mid-level to advanced programmers. Why for advanced? Because they can quickly get throught it, and challenge some of their own design assumptions and practices. Mid-level programmers will find it a treasure.The title of the book is perfect, because it really is more philosophical and high-level. But that doesn’t mean it’s abstract nor boring. I find the ideas very applicable and easy to understand. The opening statements are very powerful – what is complexity, the difference kinds of complexity (“cognitive load” is an excellent concept), etc. It ends with a gem – you know your code is complex if you end up spending a lot of time fixing bugs in it. Complexity begets complexity.Don’t let the critical reviews stop you from reading this book – so what, it ignores functional programming. Readers can buy books on that and contrast the desgin philosphy. Yes, it’s OOP-based, but so what? It’s easy to apply these ideas to non-OOP languages or concepts.Some complained about “3 chapters on comments alone”. Not true – the three chapters cover different subjects, and provide excellent guidelines for commenting first (designing with your comments – kind of like writing a mini-spec, if you will), what constitutes a useful comment, and how to name variables. I found it very useful.The concept of “deep” versus “shallow” classes is very interesting, even if some of the reviews have criticized it. The author provdes a very nice clue to whether or not code should be broken out – do you have to keep flipping back and forth between the sub-task and the original function? Maybe it shouldn’t have been broken out. Deep classes have simple interfaces and accomplish a lot for the caller. Shallow classes, on the other hand, require the caller to know about them, how to call them in order, etc. Good stuff.It’s a short read. You’ll scarcely find a book that’s so short be so valuable.You can get through it in about 3-4 intense, focused sessions.
James Koppel –
Beautifully-written, but with blind spots
Since 2016, my job has been to teach software design at the advanced level to professional engineers. I run workshops, speak at tech companies, and blog on software design. So when I heard of this book, I naturally took a look to see if I could recommend it to students.PoSD is best read as a tactical guide of how-to’s. About a quarter of it is spent on naming and comments, and much of the rest is about specific patterns. His few attempts to jump from tactical advice to principles are either done by trying to blur together similar-sounding tips, or are hamstrung by his inability to see the meaning of a program beyond the code. He demonstrates the lack of principles comically in Chapter 19, where he promises to apply the books’ “principles” to several software trends, and then fills the rest of the chapter with standard (but solid) advice on unit-testing and OOP, with nary a reference to the rest of the book. On the whole, the book’s advice is higher-level than beginner books like Clean Code, but most of its contents will be familiar to a senior software engineer, and the novel parts are hit-and-miss.A huge underlying theme of the book, and one of its few novel parts, is Ousterhout’s idea of deep modules: modules should have an implementation which is simpler than the interface. This sounds elegant, and impossible to argue with. Unfortunately, it’s also objectively wrong. Further inspection shows that actually many common abstractions like stacks fail this test, and even Ousterhout’s own example of a deep module has an interface which is far more complex than he claims. Overall, Ousterhout misses the deeper notions of complexity, the kind which is about what a piece of code means and how it may be used and how it may be changed, rather than the kind that can be gleaned by glancing at the code. This is a major blindspot which damages the book significantly, and limits his ability to give precise advice.When Ousterhout tells you do reduce complexity, it often sounds like telling someone going on a date or interview “just be yourself:” the advice only works if you already understand complexity.Despite that, there is a lot of really good advice in this book, and it’s explained with clear and concrete examples. I especially enjoyed his sections on comments. While I don’t agree with everything in that section either, there are some really good points that I hope become common practice, and which I have not seen others write about. His chapter on performance engineering is also gold.So, read the book, savor the advice, but take his justifications with a grain of salt and know that they’re not universals, because there are deeper principles to be found.I wrote a much longer review on my blog, going into these points in more detail. For my full review, see: http://www.pathsensitive.com/2018/10/book-review-philosophy-of-software.htmlA Philosophy of Software Design is a good book, but not a great one. But it’s one of the only books of its kind out there. Hence, I am proud to recommend it to all junior-level software engineers.
João Henrique Santos –
Great book! Very clear and pragmatic explanation of what matters in Software Design. Also recommend the The Pragmatic Engineer podcast episode with John Ousterhout (author) for a great overview of some ideas in the book.
Cliente Amazon –
Mi pareja compró este libro para leerlo, tal y como ha hecho con otros libros. Sin embargo acaban decorando una estantería.
Samahell –
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.
Ana Paula Monetti Nishimoto –
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.
Kocsonya –
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.