継続的デリバリーのソフトウェア工学

著 : David Farley

訳 : 長尾高弘

解説 : 榊原彰

原著 : Modern Software Engineering : Doing What Works to Build Better Software Faster

https://m.media-amazon.com/images/I/51TviYFYuML.jpg

Amazon : https://amzn.to/3OC8SvM

本書は、現代のソフトウェアエンジニアリングについて論じる本

目新しい概念は出てこないが、以下の 2 つが着眼点として優れている

これまでにもあった概念を整理し、意識の持ちようも含めて体系立てている

学びを基礎に置いたプロセスと、複雑さの管理のための要点

ソフトウェアエンジニアリングにおける学びのための 5 つの行動様式

ソフトウェアエンジニアリングにおける複雑さ管理のための 5 要素

2 章工学とは何か

製造工学 (生産工学) と設計工学の混同がある

物理的なものの製造は困難だが、デジタルでは製造コストは無視できる

我々がソフトウェアで作るモデルは実行できる

他の工学分野よりも、現実世界での評価がやりやすい

Real Software Engineering

ソフトウェアエンジニアリングは、純粋に設計工学

「エンジニアリング」 (工学) の定義

工芸だと再現性がない

人間の能力頼みだと、人間の能力の範囲に制限される

精度とスケーラビリティ

標準化、精度の高い計測

ソフトウェアクラフトマンシップは重要だが、それだけでは十分ではない

スキルや創造性、イノベーションは工芸のみにあるわけではなく、設計工学でも中心的な役割

工学では、理論よりも証拠に基づいて決定を下してから、考えが機能するか検証する

完全に予測可能なプロセスではない

直面するトレードオフを理解することは工学的な意思決定のなかで超重要

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

効果的な計測ができていないために間違った考えを捨てられない

アジャイルの世界では、ソフトウェア開発チームやプロジェクトのパフォーマンス計測は不可能だと考えられてきた

『Lean と DevOps の科学 Accelerate』で興味深いモデルが提案されている

2つの属性に基づいたパフォーマンス評価

安定性

スループット

ソフトウェアデリバリの 4 つのキーメトリクス

スピードと品質には密接な相関関係

nobuoka.icon 質とスピードやん

ソフトウェアエンジニアリングの基本概念

2 つのカテゴリ

プロセス、あるいは哲学的なアプローチ

テクニック、または設計

2 つの最重要スキル

学びのエキスパート

実用科学的な問題解決アプローチ

ソフトウェアエンジニアリングにおける学びのための 5 つの行動様式

複雑さ管理のエキスパート

並行処理と結合 (カップリング) の本質的な難しさ

これらは IT システムだけでなく社会システムについても同様

ソフトウェアエンジニアリングにおける複雑さ管理のための 5 要素

2 部学びの最適化

4 章反復的な作業

イテレーション

参考 : アジャイルとウォーターフォール

反復的な作業の実践的な利点

自動化に焦点

小さい単位で考えるため、モジュラー性や関心の分離をより真剣に考えられる

完成までにどれだけの時間がかかるかどう考える？

意味のある完成の尺度はユーザーに価値を届けられたかどうか

非常に主観的

アイデアを最小限のコストで試すこと

計画への誘惑はまずい誘惑

漸進的な計画と実施により、変化に反応、適応できる

反復的に作業するには？

小さな単位で仕事をする

イテレーション (スプリント)、継続的インテグレーション、テスト駆動開発

5 章フィードバック

フィードバックがなければ学びの機会はない

フィードバックがあれば、意思決定の証拠を明確化できる

ほうきバランスの例

様々なレベルでのフィードバック

コーディング → テスト駆動開発など

インテグレーション → 継続的インテグレーション

設計 → テスト駆動開発は設計へもフィードバックを与える

テスト可能なソフトウェアは、ソフトウェアエンジニアリングにおける複雑さ管理のための 5 要素を満たすもの

アーキテクチャ

継続的デリバリーは高品質なフィードバックを必要とする

システムのテスト可能性とデプロイ可能性

マイクロサービスでもモノリスでも、継続的デリバリーにより質を高められる

フィードバックの早さ

左シフトと言ったりフェイルファストと言ったり

製品設計へのフィードバック

プロダクトのアイデアから本番システムに価値を届けるまでの間にフィードバックループを閉じるのが継続的デリバリーの真価

組織と文化に対するフィードバック

成功や進捗の度合いをどう測るか？

成功の指標がない中でも、役に立つフィードバックを得る 2 つのアプローチ

プロセスやツールよりも、個人と対話を

主観的ではあるが、重要

ソフトウェアデリバリの 4 つのキーメトリクス

これが完璧というわけではないが、大きな前進

6 章漸進主義

漸進主義が、モジュラーな設計の応用に直接つながる

モジュラー性とコンポーネント化を活用

新しいことを学んだときに書き換えられるコードを書くことが目的

複雑なシステムを作るには、反復的な作業と漸進的な作業のどちらも必要

反復的 (イテラティブ) と漸進的 (インクリメンタル)

モジュラー性が重要

分離、切断がメリットのひとつ

技術的にも重要だし、組織的にもチームが独立できる

組織と文化の転換にも漸進的なアプローチが取れる

漸進主義のためのツール

より抽象度が低いもの

コード変更が与える影響を最小化するには？

システムを独立性の高い部品に分解する

ポートアンドアダプターパターン

確かヘキサゴナルアーキテクチャのことのはず

フィードバックのスピードと質を上げる

継続的インテグレーションと継続的デリバリー

7 章経験主義

経験主義

現実から集めた情報を元に、実験で検証できる理論を組み立てる

8 章実験主義

実験主義

他の工学分野と比べて、コンピュータは実験しやすい

様々な実験形態のなかでも、自動テストは群を抜いて柔軟

テスト駆動開発 (TDD)、受け入れテスト駆動開発 (ATDD) あるいは振る舞い駆動開発 (BDD)

これらの技術で開発されたソフトウェアは、顕著にバグが少なくなる

https://bit.ly/2LFixzS

https://bit.ly/2LDh3q3

https://bit.ly/3MurTgF

3 部複雑さ管理の最適化

9 章モジュラー性

モジュラー性は複雑化を防ぐために必要な第一のツール

設計概念としてのモジュラー性はフラクタルなもの

テスト可能性は重要

Kent Beck の『エクストリームプログラミング (オーム社)』

工芸から工学に進むために、テスト駆動開発という能力増幅器が重要

コンピュータシステムが決定論的になれない根本原因は並行処理

サービスは境界を表している

REST API

デプロイパイプラインには、リリース可能性を構成するすべての要素が含まれなければならない

独立してデプロイ可能であるべし

ソフトウェア開発を最もスケーラブルにするのは開発の分散化

チーム間、各チームの出力間の結合と依存を取り除く

モジュラーなソフトウェアだけでなく、モジュラーな組織が必要

10 章凝集度

凝集度

書きやすさではなく、人が読みやすいコードを書く

11 章関心の分離

関心事の分離 (関心の分離) が筆者にとって最も重要な設計原則

特定の形での関心事の分離は、本質的な複雑さと付随的な複雑さを分離できる

ポートアンドアダプターパターンやヘキサゴナルアーキテクチャと呼ばれるもので関心事の分離を進められる

いつ使うか？ → サービスやモジュールの境界の変換レイヤが話題になっているとき

コンテキスト境界を超えるかどうか

アダプターは API 全体を処理する必要

例えば送られてきたバイナリストリームが規約に沿っていない場合にも壊れないようにする必要

12 章情報隠蔽と抽象化

情報隠蔽と抽象化

これができていないコードベースは巨大な泥団子 (大きな泥だんご) と言われたりする

「上司が〇〇 (リファクタリングだったり自動テストを書くことだったり) させてくれない」というのは言い訳でしかない

それらはプロの仕事の基本的なこと、注意義務

スピードと品質はトレードオフではない

『Lean と DevOps の科学 Accelerate』参照

既存コードを書き換えることは良いことであり、合理的であるというマインドセットを持つこと

チームのソフトウェアの半分の寿命で品質を測るという考え方

オーバーエンジニアリングの懸念

実利主義、懐疑主義が重要

フューチャープルーフにしたいという思いでそうなることもある

YAGNI

リグレッションテスト (退行テスト) の完全な自動化で対応

プレーンテキストという抽象化

漏れのある抽象化

問題ドメインの各部の関係を描くにはイベントストーミングなどが役立つ

13 章カップリングの管理

カップリング (結合度) は複雑さ管理において重要な概念

カップリングの影響

開発のスケーリング : カップリングがあるとスケールしづらい

開発カップリングを切断する必要があるが、コストがかかる

どう対応する？

継続的インテグレーション

マイクロサービス

カップリングのナイガードモデル

5 つに分類

抽象化やデカップリングにはコストがかかるので、しすぎないことが大切

疎結合と関心事の分離の違い

例えば注文の処理と格納の 2 つのサービスは、関心事の分離はよくできているが、密結合

DRY 原則は単純化し過ぎ

重複を避けるためにカップリングしてしまう

プロセス境界は非同期で扱うべき

非同期プログラミングにはメリットがある

プログラミング言語への翻訳は機械でもできる

カップリングが影響を与え始めると難しくなる

コードだけの問題ではない

組織のカップリングが問題

『継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』は、このカップリングを効率よく管理する戦略を説明

チーム間のカップリングを管理するための戦略

調整か分散の 2 つの戦略

調整の場合、共有コードベースとシステム全体の継続的デリバリーのデプロイパイプライン

分散はマイクロサービスのアプローチ

間接的なコストとして設計コストがかかる

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

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

ソフトウェア開発とは？

テストは必須 → 効率よく効果的にテストするには？

人の手によるフィードバックは遅すぎる

コードを書くときに学びたいことは 4 種類

正しい問題を解決しようとしているか？

ソリューションが期待通りに動作するか？

仕事の品質が高いかどうか？

効率よく仕事を進められているか？

テストするならコードをテストしやすくするべき ( テスト可能性)

関心事の分離と依存注入が役に立つ

計測点をたくさん作るようにシステムを作る

デプロイ可能性

デプロイパイプライン

合理的な時間内に開発の方向性を左右するフィードバックを得るにはスピードが重要

フィードバックを得るためにかかる時間の削減に力を注ぐこと

フィードバックサイクルの短縮のための反復的実験的なアプローチは、アジャイル理論、リーン理論、継続的デリバリーと DevOps のすべてに対する適応度関数のように機能する

→ ソフトウェア開発におけるスピードの重要性

変数の管理

継続的デリバリー

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

本書に出てくる概念は互いに密接に関連しあっている

モジュラー性、凝集度、関心事の分離は、フィードバック収集能力を高め、結果として実験を促進する

ジャン・ボッシュの「BAPO 対 OBAP」

継続的デリバリーと DevOps

#書籍 #文献