Zenn
🚚

読書感想文@継続的デリバリーのソフトウェア工学

2024/09/23に公開
TDD
CI/CD
読書感想文
tech

はじめに

こちらの本の感想を書いていきます

https://amzn.asia/d/7hzzxEV

これっておすすめ？

個人的には、「TDD（テスト駆動開発）がなぜ必要か」を納得するのに役に立ちました。
タイトルからはまるでCI・CDについてガッツリ学べるような本に思えますが、そんなことはありません。どちらかというと「なぜCI・CDを運用することが大事なのか」を学ぶことができます。

個人的に学びになった3つのこと

こちらの本では、ソフトウェア工学に関わっている私たちに必要なことをは以下だと言っています。

私たちは学びのエキスパート兼複雑さ管理のエキスパートになる必要がある

そして、それぞれのエキスパートを支えるテクニックを5種類ずつ紹介しています。具体的には以下の通りです。

  • 学びのエキスパート
    • 反復的な作業
    • フィードバック
    • 漸進主義
    • 実験主義
    • 経験主義
  • 複雑さ管理のエキスパート
    • モジュラー性
    • 凝集度
    • 関心の分離
    • 抽象化
    • 疎結合

どれもなんとなく聞いたことがあるようなワードですね。それがなぜ必要なのかを説明していますが、ここでは私が特に学べた3つをピックアップします。

フィードバック(第5章)

学びのエキスパートになるための一つのテクニックとして**「フィードバック」**が紹介されています。
学びとは経験や失敗から知識を得ることですが、そもそも経験や失敗を認知しなければ学びはありません。経験や失敗を認知するためにはフィードバックを受ける仕組みが必要です。
そしてフィードバックは「質の高い」「頻度が高い」ものであることがよりよい学びの秘訣です。
この二つを満たすためには、システム開発の粒度の細かいものから大きいものまでをフィードバックがされる仕組みがあるとより良いです。

筆者がベストプラクティスとしてよく挙げていたのは、TDDとCIによる自動化です。
TDDをすることで自動でフィードバックがもらえる仕組みができるのはもちろんのこと、プロダクトとしての以下の5つを強制的に担保することができます。

  • モジュラー性
  • 凝集度
  • 関心の分離
  • 抽象化
  • 疎結合

この章だけでもTDDがアジャイルでの開発に向いていることがよく分かりましたが、逆に言うと途中からプロジェクトにTDDを導入することの難しさも感じました。
最初からやっていればいいですが、途中から5つを強制的に担保するとなるとアーキテクチャレベルでの変更が必要になり難易度が高くなりそうです。

漸進主義（第6章)

学びのエキスパートになるために紹介されている他のテクニックが**「漸進主義」**です。

漸進主義は一気に全てではなく、少しずつ大きくしていくという形の価値の構築を手段とした思想です。
よく反復的と漸進的が対比して以下のように解説されますが、漸進的なメリットとしてフィーチャーがそれぞれ独立して開発を行うことができるのが挙がります。

sample
引用：https://rihoublog.com/2020/06/07/イテレーティブ開発とインクリメンタル開発の違/

そして漸進主義は他のテクニックと密に繋がっています。フィードバックや実験主義、関心の分離がありますが、最も注目すべきはモジュラー性です。

想像に難しくないように、モジュラー性を持っていないプロダクトを漸進的に開発するのはほぼ不可能です。ロケットを一枚岩のように作るのではなく、「出発するためのエンジン」「帰るためのエンジン」「宇宙で過ごすためのドック」のように分離しないと、少しづつ大きくしていくプロダクト開発はできません。またこのような開発は結果的に組織も細かいチームに分離され、経済的にもメリットが大きいです。

そして筆者は漸進主義を実現するにはTDDが有効だという話をしています。テストで各ステップが保証されることでより漸進的な開発がしやすくなります。

当たり前で直感的に理解していたことがほかのテクニックとの関係性から説明されると、ここまで納得できるのかと個人的に感動しました。（TDD教の1歩目を踏み出した気がしました……）

関心の分離(第11章)

複雑さ管理のエキスパートになるために紹介されているテクニックの一つが**「関心の分離」**です。

関心の分離は、縦の関係（抽象度）と横の関係（コンテキスト）をそれぞれを分離することをさしています。
たとえば、アーキテクチャ的な分離は縦の関係での分離に入ります。ドメイン層とプレゼンテーション層をすることで、ドメイン層はビジネスロジックやドメインモデルの作成に集中でき、プレゼンテーション層は画面表示に集中することができます。またそれによって、コードの影響範囲が狭まり、コードの可読性が向上します。
また、ユーザーに関する操作と商品に関する操作を分けるのは、横の関係での分離に入ります。逆にユーザーと商品の操作を一つにしてしまうと、ユーザーデータのバグがあった場合その原因が、商品の操作の際かユーザー操作の際かがすぐにわからなくなってしまいます。

上記で分かる通り、これも漸進主義と同様に他のテクニックと結びついています。関心の分離を進めることでモジュラー性、凝集度、抽象化が進み、結果としてカップリングが効果的な最小限に引き下げられます。

そしてTDDは関心の分離も推進されます。関心の分離がされていないコードはテストが書きにくいため、自然と関心の分離がされます。

...やっぱりTDDはいいのかな...？

さいごに

いままで学んできたエンジニアワードに新たな理由づけがされたような体験でした。そして筆者がTDD好きなことがよく分かりました笑

ぜひみなさん読んでみてください。

Discussion