ちゃなべの備忘録

ほぼ備忘録です。

継続的デリバリーのソフトウェア工学 を読んでみて【備忘録】

はじめに

これは「継続的デリバリーのソフトウェア工学」を読みながら記した備忘録です。

第1部

第1章イントロダクション

学びのエキスパート兼複雑さ管理のエキスパートになれ。

学びのエキスパートになるには、5つが大事。

  • 反復的な作業
  • フィードバック
  • 漸進主義
  • 実験主義
  • 経験主義

複雑さ管理のエキスパートになるには、5つが大事

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

ソフトウェア開発の舵取りに必要なツールの5要素

  • テスト可能性
  • デプロイ可能性
  • スピード
  • 変数の管理
  • 継続的デリバリー

第2章 工学とは何か

ソフトウェアを作る為に考慮することと、 建築物を作る為に考慮することは異なる。

建築物は本質的な設計以外に気にしないといけないこと(土地、予算、材料、輸送)が多いが、ソフトウェアは設計以外を気にするコストが無視できるほど小さい。

工学の定義 「工学とは、実践的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことである。」

第3章 工学的アプローチの基礎

ソフトウェアの生産性を計測する時、「安定性」 と「スループット」の2属性に着目すると良い。

安定性の指標は

  • 変更失敗率: 変更によってプロセスの特定の地点でエラーが発生した割合
  • エラー修復時間: プロセスの特定の位置で起きたエラーから修復までにかかった時間

スループットの指標は

  • リードタイム: 「アイデア」を「動作するソフトウェア」に変える1行の変更にどれだけの時間がかかっているか。開発プロセスの効率性の指標。
  • デプロイ頻度: 変更はどれくらいの頻度で本番環境にデプロイされているか。変更ベースの指標。

第2部

第4章 反復的な作業

学びは基本、イテレーション(繰り返しで、目標に少しづつ近づく)でおこなう。

ウォーターフォールは、 - 時間とともに変更のコストが大きくなる - 一番最初に全ての計画が建てるはずという考え

アジャイルは - 変更コストが時間を追っても一定にするために努力する→リリースを何度も行う - 一番最初に全ての計画は建つはずがないという考え

第5章 フィードバック

「評価を評価元になる主体に伝達すること」がフィードバックであり、それがあれば意思決定のエビデンスを明確化できます

フィードバックを効率的に回すためには、 フィーチャーブランチ(FB)によって作業分担し、マージの担保を継続的インテグレーション(CI)によって担保する。

設計に対するフィードバックはTDDを非常に高く評価します。TDDを使うことで、以下の5つを強制的に担保できるからです。

  • モジュラー性
  • 関心の分離
  • 凝集度の高さ
  • 情報隠蔽(抽象化)
  • 適度なカップリング

アーキテクチャに対するフィードバックはテスト可能性とデプロイ可能性を追求し続けたら自ずとよいアーキテクチャになってる不思議。

失敗は早くしろ。

組織として、目標に向かっているかどうかを判断するための軸として適応度関数を定義するのは大事だが、「安定性」と「スループット」は結構ベストよ。

第6章 漸進主義

漸進的な設計はモジュラーな設計の応用なので、あとで様々なコンポーネントが交換可能

ロケット全部を一気に作るんじゃなくて、「出発するためのエンジン」「帰るためのエンジン」「宇宙で過ごすためのドック」とかで分離することで、作成・検証の工数を下げた。
↑これは分離の重要性が直感的にめっちゃわかる。

漸進主義(モジュラー設計の応用)をすると、チームは独立して開発を進めることができる。そのためには「開発するシステムを独立性高く分解する」か「継続的インテグレーションによって変更のFBのスピードと品質をあげる」かです。

ポートアンドアダプターがとても良いぞ。インターフェースと実装を分離しよう。

第7章 経験主義

事実を積み上げて語ろう、これはバグ修正も実装自体にも言える。

第8章 実験主義的であること

客観的な指標で物事を語ろう。

大事なのは

  • フィードバック
    • フィードバックのスピードをあげるだけで、改善の効率が上がり、ものは良くなる
  • 仮説
    • 仮説をたて、実験し、差分を計測し、改善する。仮説は実験の第1歩。
  • 計測
    • 計測の値に人のバイアスはないか、計測している値は取りたい値なのか、など考慮が必要
  • 変数の管理
    • 考えなくていいことは、自動化して考えなくてもいいようにしよう。じゃないと考慮しないといけないことが多くなる。

そういった意味でTDDはガチでおすすめ。実験主義的に開発を進められる。

第3部 複雑さ管理の最適化

第9章 モジュラー性

モジュラー性はどれだけ独立に分離がされているかです

モジュラーの切り分け方はソフトウェア開発のスキルそのもの、この優劣が玄人を分ける。

TDDをするためにはモジュラー性は必須

モジュラーの繋ぎ目(シーム)は何が良いかちゃんと考えて。

第10章 凝集度

凝集度は、依存度が高いコードをどれだけ同じ場所にまとめられるかです。とある場所のコードを変えた時に別の場所でコードを変えるようなことにならないように。

しかし、ただ同じファイルや同じ関数にまとめたからと言って凝集度が高いわけではない。構造的に(フォルダシステムみたいに階層的に)まとめる必要がある。詳細度が異なるものを並列にまとめたくないねってお話。

第11章 関心の分離

抽象度が同一のものをまとめても、「凝集度が上がる」というらしい?

関心の分離 = 抽象度が同一のものをまとめたときに、サービス全体の方針といま書いているモジュールの責務を考え、何を入れるか入れないかを考える

ポートアンドアダプターは、サービスレベルだと「ヘキサゴナルアーキテクチャ」とも言う

個人的な理解として、 「関心の分離」は言葉通りの意識を持つことであり、それによって様々な恩恵がある。

縦の関係(抽象度)と横の関係(コンテキスト)それぞれ分離すること大事

第12章 情報隠蔽と抽象化

抽象化や情報隠蔽を進めることで、モジュール間のカップリングを防ぎ、コードの読解容易性を上げ、その結果として変更容易性をあげることに直結する

YAGNIのメリットは変更容易性をあげることです。「将来的に必要になるであろう機能」を作った人がその機能を消すことを嫌がる現象を減らすことができます。

「抽象化の漏れ」は細部がまだ完全に抽象化されていない状況のことであり、大体2種類の原因がある。
一つは細部の情報が必須なために絶対に抽象化の漏れが避けられない場合。
もう一つが設計の破綻に対処するための時間・エネルギー・想像力が足りないために残ってしまう場合。

抽象化は解決したい問題と状況によって最適が異なる。

イベントストーミングとは↓

qiita.com

第13章 カップリングの管理

カップリングはモジュール同士の依存の度合い、密接に繋がっているのかの尺度

独立してデプロイできることが、マイクロサービスで1番難しいけど意味があること そしてそれはサービスのスケーラビリティにつながる

疎結合と関心の分離は異なる概念

第4部 ソフトウェア工学を支えるツール

第14章 工学分野のためのツール

いままで学んだことを活かしてテストを書こうね。

デプロイの速さとテストは大事だよ。

第15章 現代のソフトウェアエンジニア

プロダクトを作る上で2つの流れがあるが、OBAP(Organization→Business→Architecture→Process)の順番に決めずに、BAPO(Business→Architecture→Process→Organization)の順番に決めたほうが本質に向かってます。