A Philosophy of Software Design by John Ousterhout

bokomslag

★★★★☆

A Philosophy of Software Design by John Ousterhout

Contrary to its name, it is not much philosophy, but high level advice on software design.

Most tips are fairly common sense:

• Avoid complexity and obscure unreadable code.

• Comments should not simply repeat the code, but explain details or overall purpose of the code block

• Hide complexity by abstracting away unnecessary details

A few times the author disagree with authors other software design principles books, eg. Martin’s “Clean code” or repeat common known reference points like the Agile manifesto or “Design Patterns” by Gemma et. al.

Highlights

The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it up into pieces that can be solved independently.

— location: 171 ^ref-56123

Programmers aren’t bound by practical limitations such as the laws of physics; we can create exciting virtual worlds with behaviors that could never exist in the real world. Programming doesn’t require great physical skill or coordination, like ballet or basketball. All programming requires is a creative mind and the ability to organize your thoughts. If you can visualize a system, you can probably implement it in a computer program.

— location: 227 ^ref-36964

The second approach to complexity is to encapsulate it, so that programmers can work on a system without being exposed to all of its complexity at once. This approach is called modular design. In modular design, a software system is divided up into modules, such as classes in an object-oriented language. The modules are designed to be relatively independent of each other, so that a programmer can work on one module without having to understand the details of other modules.

— location: 241 ^ref-62704

There are two general approaches to fighting complexity, both of which will be discussed in this book. The first approach is to eliminate complexity by making code simpler and more obvious. For example, complexity can be reduced by eliminating special cases or using identifiers in a consistent fashion. The second approach to complexity is to encapsulate it, so that programmers can work on a system without being exposed to all of its complexity at once. This approach is called modular design. In modular design, a software system is divided up into modules, such as classes in an object-oriented language. The modules are designed to be relatively independent of each other, so that a programmer can work on one module without having to understand the details of other modules.

— location: 239 ^ref-21906

way. Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

— location: 311 ^ref-7487

Change amplification: The first symptom of complexity is that a seemingly simple change requires code modifications in many different places.

— location: 334 ^ref-25154

Cognitive load: The second symptom of complexity is cognitive load, which refers to how much a developer needs to know in order to complete a task.

— location: 341 ^ref-27426

Unknown unknowns: The third symptom of complexity is that it is not obvious which pieces of code must be modified to complete a task, or what information a developer must have to carry out the task successfully.

— location: 356 ^ref-5260

One of the most important goals of good design is for a system to be obvious. This is the opposite of high cognitive load and unknown unknowns. In an obvious system, a developer can quickly understand how the existing code works and what is required to make a change.

— location: 370 ^ref-26879

The second cause of complexity is obscurity. Obscurity occurs when important information is not obvious.

— location: 395 ^ref-11473

Deep and shallow modules. The best modules are deep: they allow a lot of functionality to be accessed through a simple interface. A shallow module is one with a relatively complex interface, but not much functionality: it doesn’t hide much complexity.

— location: 600 ^ref-39237

What is the simplest interface that will cover all my current needs? If you reduce the number of methods in an API without reducing its overall capabilities, then you are probably creating more general-purpose methods.

— location: 996 ^ref-4141

One way to separate specialized code is to push it upwards. The top-level classes of an application, which provide specific features, will necessarily be specialized for those features. But this specialization need not percolate down into the lower-level classes that are used to implement the features.

— location: 1016 ^ref-14067

Another way of expressing this idea is that it is more important for a module to have a simple interface than a simple implementation.

— location: 1309 ^ref-39821

File deletion provides another example of how errors can be defined away. The Windows operating system does not permit a file to be deleted if it is open in a process. This is a continual source of frustration for developers and users. In order to delete a file that is in use, the user must search through the system to find the process that has the file open, and then kill that process. Sometimes users give up and reboot their system, just so they can delete a file. The Unix operating system defines file deletion more elegantly. In Unix, if a file is open when it is deleted, Unix does not delete the file immediately. Instead, it marks the file for deletion, then the delete operation returns successfully. The file name has been removed from its directory, so no other processes can open the old file and a new file with the same name can be created, but the existing file data persists. Processes that already have the file open can continue to read it and write it normally. Once the file has been closed by all of the accessing processes, its data is freed.

— location: 1679 ^ref-52177

The overall idea behind comments is to capture information that was in the mind of the designer but couldn’t be represented in the code. This information ranges from low-level details, such as a hardware quirk that motivates a particularly tricky piece of code, up to high-level concepts such as the rationale for a class.

— location: 1974 ^ref-2323

Unfortunately, many comments are not particularly helpful. The most common reason is that the comments repeat the code: all of the information in the comment can easily be deduced from the code next to the comment.

— location: 2053 ^ref-55323

Comments augment the code by providing information at a different level of detail. Some comments provide information at a lower, more detailed, level than the code; these comments add precision by clarifying the exact meaning of the code. Other comments provide information at a higher, more abstract, level than the code; these comments offer intuition, such as the reasoning behind the code, or a simpler and more abstract way of thinking about the code.

— location: 2124 ^ref-14680

Good names are a form of documentation: they make code easier to understand.

— location: 2549 ^ref-35299

The best time to write comments is at the beginning of the process, as you write the code. Writing the comments first makes documentation part of the design process.

— location: 2755 ^ref-5354

The best way to ensure that comments get updated is to position them close to the code they describe, so developers will see them when they change the code. The farther a comment is from its associated code, the less likely it is that it will be updated properly.

— location: 2866 ^ref-4844

Test-driven development is an approach to software development where programmers write unit tests before they write code. When creating a new class, the developer first writes unit tests for the class, based on its expected behavior. None of the tests pass, since there is no code for the class. Then the developer works through the tests one at a time, writing enough code for that test to pass. When all of the tests pass, the class is finished.

— location: 3233 ^ref-64514

One place where it makes sense to write the tests first is when fixing bugs. Before fixing a bug, write a unit test that fails because of the bug. Then fix the bug and make sure that the unit test now passes. This is the best way to make sure you really have fixed the bug. If you fix the bug before writing the test, it’s possible that the new unit test doesn’t actually trigger the bug, in which case it won’t tell you whether you really fixed the problem.

— location: 3243 ^ref-13733

Design patterns represent an alternative to design: rather than designing a new mechanism from scratch, just apply a well-known design pattern. For the most part, this is good: design patterns arose because they solve common problems, and because they are generally agreed to provide clean solutions. If a design pattern works well in a particular situation, it will probably be hard for you to come up with a different approach that is better.

— location: 3250 ^ref-4598

• Author: John K. Ousterhout
• ASIN: B09B8LFKQL
• ISBN: 1732102228
• Reference: https://www.amazon.com/dp/B09B8LFKQL