Table Of Content
In chapter 20, the author addresses the topic of performance optimizations. He says that if you try to optimize every statement for maximum speed, it will slow down development and create complexity. Still, if you ignore performance, it is easy to create a system with significant inefficiencies through the code (called the “death by a thousand cuts” scenario). The solution is in the middle, so we design things that are “naturally efficient” but also clean and simple to know which operations are expensive.
John Ousterhout
And in the best modules, the deep functionality is hidden behind a simple interface. If we think about the most complex problems in Computer Science, there are different thoughts on this. Where you must handle exceptions, you should prefer to handle many exceptionswith a single piece of code. There are two main ways to handle exceptions, each with their owncomplexity. The first is to complete the work in spite of the exception, and thesecond is to report the exception upwards (perhaps also running some unwinding /handling logic).
Rules of thumb, laws, guidelines and principles
What is Toyota Way? - Definition from TechTarget - TechTarget
What is Toyota Way? - Definition from TechTarget.
Posted: Thu, 07 Apr 2022 11:33:52 GMT [source]
For the benefit of people who already purchased the First Edition, I have made the two new chapters and the comparisons with Clean Code available in a book extract. It may not be worth buying the Second Edition if you already own the First Edition. Overall, I'm largely in agreement with Ousterhout and with your own assessment of his book. With respect, we disagree somewhat about things you question Ousterhout's text. Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
A philosophy of software design - John Ousterhout
By this the author means that the interface should be general enough to support multiple implementations, even though the implementation only covers what is needed today. Reducing the API to a few general purpose methods instead of many special purpose will do this and make the module deep. An example for an interactive text editor is given, where several functions, like delete, backspace, deleteSelection etc, were replaced by the more general purpose functions insert and delete. This resulted in clearer division of functionality, as well as a simplified interface. Calling out event-driven programming as something that makes the code less obvious (Chapter 18) is an interesting take, that I would have hesitated to phrase as such.
Comprehensive systems
When developing a module, look for opportunities to take a little bit of extra suffering upon yourself in order to reduce the suffering of your users. The simplest chapter abstracting the deeper complexities of what it means! It would also have been interesting if the author had included something about testing and how to write code that is easy to test.
BONUS: A Philosophy of Software Design, John Ousterhout (Talks at Google)
Any change to the sender usually also requires a change to the receiver. An example is if you add a new exception, and you then also need to add a new entry in an error message table, but the connection between them is not obvious. IEEE Software presents pioneering ideas, expert analysis, and thoughtful insights for software professionals who need to keep up with rapid technology change. The book does leave a glaring gap on testing and how testability and good architecture go hand in hand. I would recommend a book like Clean Code or Working Effectively with Legacy Code to augment the topics written here.
Everything that is discussed in the book is at a fairly general and high-level, but it's still very helpful. As developers, we ultimately owe to ourselves to ensure we reduce complexity. The by-product of reducing complexity for ourselves is that we develop better products for our users. Furthermore, when you work in a codebase, you can easily navigate in and out of methods. In these cases, a comment describing what a method does doesn’t help much.
Complexity defined
The author is a professor of Computer Science at Stanford, but he has also spent 14 years developing commercial software. John Ousterhout, professor of computer science at Stanford University, joined SE Radio host Jeff Doolittle for a conversation about his book, A Philosophy of Software Design (Yaknyam Press). They discuss the history and ongoing challenges of software system design, especially the nature of complexity and the difficulties in handling it. The conversation also explores various design concepts from the book, including modularity, layering, abstraction, information hiding, maintainability, and readability. By encapsulating complexity via modular design and making code simple and obvious, like eliminating special cases or using consistent coding styles.
'The Individualists' Review: The Philosophy of Freedom - WSJ - The Wall Street Journal
'The Individualists' Review: The Philosophy of Freedom - WSJ.
Posted: Wed, 28 Jun 2023 07:00:00 GMT [source]
If all special cases can be excluded at the beginning, no checks are needed after that. Maybe all the data needed could be combined in a single data structure. The next step is to rearrange the code to be optimized to get as close as possible to this ideal case. A connection with previous chapters is that deep modules are more efficient than shallow, since more work is done for each method call.
This book discusses how to decompose complex software systems into modules that can be implemented relatively independently. The discussion first begins with a fundamental problem in software design, 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 benefit of using the interface rather than the implementation directly is not very big, so it doesn’t help in reducing the complexity of the system. It is interesting that this is the complete opposite of the advice in for example Clean Code. There the mantra is to use many small classes and methods, rather than a few bigger ones.
Names should be precise (you usually want to avoid overly-general names likedata), and consistent - if a name is used in multiple places it should refer tothe same thing. If the same name is used to refer to different concepts, then atsome point a reader will be confused, which is likely to introduce errors to theprogram. This is not always bad - the important thing is that each new method shouldcontribute significant functionality. For example, a dispatcher method is apass-through method that can be very useful. Once a codebase gets complex enough, it is nearly impossible to fix, and youwill probably pay high development costs for the rest of its life. I have to be honest, that is exactly how I approached this problem initially.
You still often need to check the details of the code to know that your change will be correct. The problem with comments is that they can get out of sync with the code, and that they clog up the code. In most cases, well-chosen names for methods and variables makes comments unnecessary. If the code is so complicated that it needs to be explained with comments, perhaps it can be rewritten to make it clearer.
We can do this by masking exceptions by detecting and handling them at a low level or aggregating them in a single piece of code at a higher level. What we usually see with startups is pressure to build products quickly, which can result in spaghetti code. One of those is to hire great people who like to work with high-quality codebases. In addition, we need to make our development 10-20% slower, and you will get it all back in the future (this also reduces tech debt).
No comments:
Post a Comment