eno314のアウトプットリポジトリ

技術書の読書ログや動画、記事等の閲覧ログを書き溜めていきます

「Clean Code アジャイルソフトウェア達人の技」読書ログ 第12章

12章 創発

要約

この章に書いてあることは、筆者達が数十年の間に経験してきたことの結晶

  • この章の規則や手法に従うことで、優れた原則・パターンに即した作業を行うことを可能とし、促進する

4つの単純な規則に従えば、優れた「単純」な設計を生み出すことができる

  • 4つの規則は以下
    1. 全テストを実行する
    2. 重複がない
    3. プログラマの意図が表現されている
    4. クラスとメソッドを最小化する
  • この規則は重要な順に並んでいる

全てのテストを実行可能とすることが、よい設計のベースとなる

  • この規則以外の3つはリファクタリングであって、テストがあって初めて継続的に出来るようになる
    • テストがあることで、元の機能を壊してしまうかもしれない、というリファクタリングの恐怖・不安を取り除くことができる
  • システムをテスト可能にすること自体が良い設計へと促す
    • クラス1つ1つが小さく、単一機能を実装するような設計になる
    • クラス同士の結び付きが最小限になるような技法を活用するようになる

「優れた設計のシステムにおける最大の敵は重複」

  • 重複は「余計な作業」「余分な危険」「不必要な複雑さ」をもたらす
  • どんなに小さくても共通部分を抽出することが、 SRP違反に気付くきっかけにもなるので、設計の改善へと繫る

システムの動作が理解できるような、表現に富んだシステムにする

  • システムの動作を理解可能とすることが、変更の際に不具合を混入してしまう可能性を下げる
  • 表現豊かであるために最も重要なことは「試す」こと
    • コードが動くようになって終わりとしない
    • 次に読む人にとってコードがわかりやすくなるように想像力を働かせる
  • 意図を表現するためのTIPS
    • 良い命名 : クラスや関数の名前でその責務が分かる
    • 関数とクラスを小さく保つ : 小さい方が理解が容易
    • 標準の用語を用いる : 一般的に知られている用語であれば、他の開発者も理解しやすい
    • 適切に記述された単体テスト : テストの第一の目的は使用例の文書化。

他の3つの規則を守った上で、システム全体を小さくする

  • 「我々の目的は、システム全体を小さくしつつ、関数とクラスも小さくするということ」
    • 他の規則は行き過ぎてしまうと、クラスやメソッドがあまりに多くできあがってしまう
    • 非現実的で実現不可能なルールは作らない(全てのクラスにインタフェースの作成を強要する等)
  • とはいえ、他の3つの規則よりは、優先順位はもっと低い

感想

今までの章の総まとめのような内容で、良い振り返りになったと思う。最後の規則で、規則を守ることばかりに目がいかないように、現実的なものを作ろうと言っているのが印象的だった。

単体テストの目的が、使用例の文章化というのは、なるほどと思った。これは意識してテストケースを書いたりテストケースの名前を付けるようにしたいと思う。

4つの規則がケント・ベックの「エクストリームプログラミング」から来ているらしいが、自分も読んだことがあるんだけど、どの章にこのことが書いてあるのかわからなくてちょっとモヤモヤする。。