Skip to content

Book Review Series - Clean Software

Source

『Clean Software』 | Robert C. Martin / Lee Yong-won, Kim Jung-min, Jung Ji-ho (trans.) | Jpub | May 15, 2017

One-line review

I recommend this book to developers who are starting to design for the first time.

Agile Design

Smells of Design

You can tell that software needs to be redesigned if you feel the following things about the software:

  • Rigidity: When it is difficult to distinguish components that can be reused in other systems
  • Fragility: When changing the system requires a lot of changes to other parts of the system
  • Immobility: When changing the system breaks parts that have nothing to do with the concept
  • Viscosity: When it is difficult to maintain the design when changes occur and it is difficult to do the right thing
  • Needless Complexity: When the design contains something that is not needed at the current point
  • Needless Repetition: When the design contains repetitive structures that can be integrated into a single abstract concept
  • Opacity: When it is difficult to understand and does not express the intention well

Principles

Single Responsibility Principle (SRP)

  • A class should only be modified for one reason
  • Use Facade or Proxy patterns to separate responsibilities

Open Closed Principle (OCP)

  • Classes should be open to extension and closed to modification

Liskov Substitution Principle (LSP)

  • Subclasses should be substitutable for base classes

Interface Segregation Principle (ISP)

  • Do not call the methods of the class directly, but create and use your own interface

Dependency Inversion Principle (DIP)

  • Upper/lower relationship, implementation should depend on abstraction, and abstraction should not depend on implementation

Test Code

How to make clean test code? Three things are needed. Readability, readability, readability. Perhaps readability is more important for test code than for actual code. To improve readability in test code, as with any code, clarity, simplicity, and rich expressiveness are needed. Test code should express a lot with minimal expression.

Using the convention of given-when-then makes the test code easier to read. But unfortunately, separating the tests creates a lot of duplicate code. So the best rule is "minimize the number of assert statements per concept" and "test only one concept per test function".

F.I.R.S.T.

  • Fast: Tests should be fast.
  • Independent: Each test should not depend on each other.
  • Repeatable: Tests should be repeatable in any environment.
  • Self-Validating: Tests are either success or failure.
  • Timely: Tests should be written in a timely manner.