Book review: A Philosophy of Software Design

German Escobar - Oct 31 '23 - - Dev Community

This book is about complexity in software and how avoid it. I think the ideas are reasonable and match my experience in general. For example, I do believe that:

  • A good test suite is crucial for a maintainable software.
  • Naming things right and comments are really important, it helps a lot when you are reading software (which is most of the time)
  • A variable with a wider scope should have a name that is more expressive that one with a narrower scope (and usually will be longer for this reason).
  • High cohesion (things that are related should be close together) and low coupling (minimize dependencies between modules) matter a lot.
  • Code should look like it has been written by the same person. Using formatters and linters help us somewhat with this.
  • Knowing about design patters help us having a common vocabulary and understand code easily.
  • TDD is great for bugs but not so much for software design IMO.
  • Having at least two possible design options before writing code is a good practice.
  • Writing comments or how you intend to use the software before writing it is also a good practice.

I would also add the following:

  • The flow of the code should go on one direction through the layers. For example, controllers call services and services interact with the DB. Controllers never call the DB directly nor they call each other.
  • Every line of code is a liability, the best code is the one you don’t write. In this regard every line you add will increase complexity. Once you grasp this, it changes the way you write code.
  • The same can be said about libraries. You should be really careful with the libraries you add, you will have to update them and update your code accordingly every time they change. Sometimes it is better to duplicate the functionality to avoid the dependency.
  • Every external system adds complexity (e.g. having to work on a browser environment adds a ton of complexity, using a Database adds complexity, and so on).

Complexity is not something you should avoid, but you should definitely try to minimize.

I would have appreciated if the author had discussed what Software Design is, and what is the difference with Software Architecture.

In my opinion Software Design is about how to structure your code, while Software Architecture is about the system in general: what are the main components and how they are going to communicate between each other (e.g we’ll have a SPA with a GraphQL API and a Relational Database, etc.), which architecture are we going to use: monolith, micro services or serverless, what kind of pipeline are we going to use to process from devices, etc.

. . . . . .
Terabox Video Player