Table Of Content
Complexity makes it more difficult for a programmer to understandand change software, it increases the rate of errors, it slows developmentvelocity, and has other negative affects. I agree with the notion that if there are tricky aspects of the code that are not obvious from reading it, then you should write a comment. There are also two good examples on pages 118 and 119 on how to write comments for cross-module design decisions. In the scripting language Tcl that the author created, the unset instruction removes a variable.
Recommendations I don't necessarily agree with
I'm currently engaged in developing a prototype of what is going to be an extremely large software application, which tackles a multitude of complex tasks and issues. As an engineering manager, I strongly advocate and sometimes even insist on designing systems twice or even three times. Note that this is a countrary suggestion to the one from the “Clean code” book of Uncle Bob Martin. Here are some things that I found valuable in this book, and they are located primarily in chapters 2 to 11. You'll end up with a much better result if you consider multiple options foreach major design decision.
TDD focuses on features rather than abstractions and design
The functionality could have been provided by just one such class, reducing the boilerplate code needed. Furthermore, commonly needed features, such as buffered I/O, should be the default behavior, with extra parameters or setup only needed when it isn’t the common case. A Philosophy of Software Design is a well-written book with many good and practical ideas on how to reduce complexity to make systems easier to understand and work with. There are good examples illustrating the various techniques, and the writing is clear and concise.
Chapter 2 — The Nature of Complexity
A larger service that is cohesive results in less complexity than several smaller services, manipulating the same data source. But by splitting into new classes, you’re driving toward shallow modules. My own thought on this is that in order to write and work with high-qualitycomments, you need to be at a certain level of fluency.
An example is from the text editor, where sometimes text is selected, sometimes no text is selected. Using a boolean to explicitly keep track of if there is a selection or not leads to lots of special handling. Instead, if you allow an empty selection of zero characters, there is no need for special handling. It is compact and short, only 170 pages, so it is a quick read, but it contains many good ideas. The focus is on how to structure systems to make them easy to understand and work with.
This modular approach promotes reusability, scalability, and ease of maintenance. Additionally, adopting the principle of separation of concerns allows developers to isolate different aspects of the software, ensuring that each module focuses on its designated responsibility. A fundamental principle of software design philosophy is simplicity. Keeping software designs simple and minimalistic helps in reducing complexity, improving readability, and enhancing maintainability. By avoiding unnecessary complexity, developers can create software that is more manageable, adaptable, and less prone to errors.
John argues that exceptions introduce one of the worst sources of complexity and advocates for writing code that needs no exceptions to run. This is a section that seems to build on John's own experience, and him analyzing Windows APIs and does not bring classroom examples. Software design philosophy emphasizes the importance of designing software with flexibility and extensibility in mind. Building software systems that can adapt to changing requirements or accommodate new features is crucial for long-term success. Developers achieve this by designing software with well-defined interfaces, using design patterns, and applying modular and decoupled architectures. Flexible and extensible designs allow software to evolve and grow without requiring significant rework or disruption.
Meet a Worldliner: Luke, Software Engineer, New Zealand - Worldline
Meet a Worldliner: Luke, Software Engineer, New Zealand.
Posted: Thu, 13 Jul 2023 07:00:00 GMT [source]
The chapter ends with a good example from the RAMCloud system, where this thinking is applied to buffer allocation code, for a speed-up of a factor of two for the most common operation. Finally, also somewhat related to deep modules, is the idea that different layers should use different abstractions. For example in TCP, the top level abstraction is that of a stream of bytes. The lower level uses an abstraction of packets that can be lost or reordered. If adjacent layers contain the same or very similar abstractions, perhaps they should be combined to create a deeper module. A sign that this is the case is that there are pass-through methods – methods that does little more than calling other methods with the same or very similar signatures.
Rules of thumb, laws, guidelines and principles
Fundamental optimizations typically obtain the most significant optimization improvements. For instance, it can modify the data structure or algorithm or add a cache. To optimize the code and come as near to this ideal condition as feasible, the next step is to reorder it. In Chapter 11, the author considered a perfect way of thinking about designing software, and that is trade-offs. It is doubtful that you will produce the best design from your first thoughts about it, but it would be much better to have multiple options to choose from and analyze which one is the best for your case. Event-driven programming makes it hard to follow the flow of control.
This is my summary and notes from A Philosophy of Software Design, 2nd Edition by John Ousterhout. Please use the link if you decide to buy the book after reading this as it contains my affiliate code. This doesn't mean that there is no use-case for event-driven programming, butcare should be taken to mitigate this complexity.
In this article, we explore the philosophy of software design and its importance in the development process. Each piece of design infrastructure added to a system, such as an interface, argument, function, class, or definition, adds complexity, since developers must learn about this element. In order for an element to provide a net gain against complexity, it must eliminate some complexity that would be present in the absence of the design element.
No comments:
Post a Comment