著 : David Farley

訳 : 長尾高弘

解説 : 榊原彰

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

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

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

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

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

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

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

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

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

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

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

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

工芸だと再現性がない

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

精度とスケーラビリティ

標準化、精度の高い計測

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

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

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

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

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

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

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

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

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

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

質とスピードやん

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

2 つのカテゴリ

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

テクニック、または設計

2 つの最重要スキル

学びのエキスパート

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

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

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

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

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

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

自動化に焦点

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

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

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

非常に主観的

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

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

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

反復的に作業するには？

小さな単位で仕事をする

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

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

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

ほうきバランスの例

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

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

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

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

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

アーキテクチャ

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

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

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

フィードバックの早さ

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

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

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

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

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

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

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

主観的ではあるが、重要

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

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

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

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

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

モジュラー性が重要

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

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

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

漸進主義のためのツール

フィードバックと実験主義

モジュラー性と関心の分離

より抽象度が低いもの

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

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

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

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

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

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

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

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

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

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

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

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

テスト可能性は重要

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

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

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

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

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

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

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

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

依存注入 (依存性注入)

人間システムのモジュラー性も重要

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

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

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

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

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

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

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

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

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

12 章 情報隠蔽と抽象化

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

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

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

『Lean と DevOps の科学 Accelerate』 参照

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

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

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

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

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

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

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

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

13 章 カップリングの管理

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

カップリングの影響

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

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

どう対応する？

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

5 つに分類

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

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

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

DRY 原則は単純化し過ぎ

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

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

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

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

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

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

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

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

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

調整か分散の 2 つの戦略

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

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

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

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

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

ソフトウェア開発とは？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#書籍 #文献