I recently finished reading A Philosophy of Software Design by John Ousterhout. If you enjoyed Clean Code or The Pragmatic Programmer, you’ll likel...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
One addition to the importance of tests section. Unit-tests can help force better modularity. Code that only has one "consumer" (other code that uses it) can have leaky abstractions and poor boundaries. But if you know, going in, that it will have unit-tests... suddenly you have to design it for multiple consumers (the production code, and the tests).
Even w/o running the unit-tests, you end up with better code! :-)
100% agreed!
This is great advice. So very often methods are written and consumed by a single caller, which makes it easy to unintentionally make the methods more tightly coupled than they should be.
This is so valuable. It's good to remember this, especially when working with a team. For solo projects, you can bootstrap a dirty design to get things done. I don't support dirty design, but I am trying to clarify where the design can affect the entire team. Of course, as you become more experienced in designing for later, you will gradually fade away from dirty design. Good design is a design you don't regret after revisting. Thanks so much for this piece.
Perfect! Although I've not read this book, so I cannot judge your notes for completeness; otherwise they are concise (hence pleasant on reader) while sharing some original wisedom from the author. Thanks 🙏🏻
Greate notes🙏
Thanks!
You take great notes!!
Thanks!
Very valuable and practical design advice in a presented in a concise manner
Thanks for the summary.
I started reading this book but yet to finish it. I agree with most of the points, I have different opinion on complexity and coding style.
Most of the developers I worked with (specially someone joined recently in team) always find existing code complex and ugly. another book on refactoring says most developer find code writen by others of not good quality. In this case, you need to judge the feedback properly. Probably focus on value it brings to business or accurate estimate of dev productivity improvements.
On system design, it's specific to domain, in Fintech requirements (where deadline is always, yesterday) change so quickly that if you wait for better or nicer approach you are late. This approach has so many downsides but I am yet to find a better way to work in this situation.