概要
「継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣」を読みました。
前提
目的
主な目的は以下です。
- CI/CD の基本的な概念を学びたかった
- t_wada さんがツイッターで紹介していたので気になった
前提知識
- 業務で CI は導入できているが、個人的に詳しいわけではない
読了時間
3 時間程度で読み切りました。後述しますが、「複雑さ管理の最適化」は設計の内容でした。そこまで難しい部分に触れていなかったので読み飛ばしました。加えて、最初の書いたことを何度も繰り返しいうパターンが多いので読み飛ばしやすかったです。
感想
一貫して CI/CD によるシフトシフト（本書では、フェイルファスト）の重要性とそれを達成するための手法（工学、フィードバック、設計、など）を論理的に紹介していました。 CI/CD が「何を目指すか」と「どのような手段があるのか」のざっくりとした内容を学ぶには十分すぎるほどの内容で、目的である「CI/CD の基本的な概念を学ぶ」を達成しました。 印象的だったのは、よく言われる工学的観点と反復的なフィードバックだけでなく、複雑さを回避するための設計についても踏み込んでいたことです。 そもそも設計が複雑じゃなければ、継続的デリバリーによる反復も容易になることから、具体的な設計原則について踏み込んで解説していました。
気になったことは、良い意味と悪い意味の両方で繰り返し同じことを主張していることです。
特に設計の話では、結局論点が TDD になります。間違っているとは思いませんが、なんども似たような話になるので、読み飛ばしました。
またエビデンスを提示していない部分で、作者の思想が強く現れている部分も多く、その点に関しては納得できない人も多いと思いました。
例えば、以下の一文には疑問が残りました。インタフェースによって DI 可能になったコードに対して、フェイクオブジェクトを作成してテストをおこなった説明に対する補足です。
実際のテストでは、自分でこのようなコードを書くのではなく、モッキングライブラリーを使うべきです。ここで FakeEngine を示したのは、行っていることを明確にするためです。
自分は、localhost で完結するテストにおいてモッキングライブラリーを使わなくて済むのにわざわざ利用するのは、仕様変更に対して弱くなり、脆いテストになると考えています。 「Google のソフトウェアエンジニアリング」において、この経験則が語られており、自分は同意しています。 localhost 以外とやりとりする場合は可能な限り本物（特に DB）を用意して、難しい場合（例えば、他 API との連携）のみ使っても良いと考えています。 そのためインタフェースから自作のスタブかフェイクを用意するべきだと思いました。 もちろん、これについて様々な議論があると考えています。 まとめると、「Lean と DevOps の科学」ほど、エビデンスが存在するのか不明な点があるので、疑問に思った部分は切り分けて考えた方が良い印象です。
次に関連で勉強すること
引き続き、CI/CD 関連の書籍を読みます。 「継続的デリバリーのソフトウェア工学」の著者が共著である、「継続的デリバリー」を優先して読みます。
- 「継続的デリバリー」を読む
- CI/CD について調査する
まとめ
あまり難しい言葉を使わずに論理的に CI/CD の重要性を説明していました。 そのため、導入としては良い本だと思いました。 CI/CD に加えて関連する考え方についても説明してもらえます。 一部、「工学」という割にはエビデンスよりも作者の思想を主張する部分があるので、「Lean と DevOps の科学」レベルのエビデンスを求めるには期待に答えられない可能性があります。 そのため、ある程度の分別を持って読んだ方が良いと思いました。
