保守容易性
from 手を動かしてわかるクリーンアーキテクチャ
LT;DR
変更が容易である（保守性 が高い）ことを、本書では『保守容易性』と呼ぶ
保守容易性は 非機能要件 の 1 つである
保守容易性は 機能要件 や その他の非機能要件よりも重要である
保守容易性は 開発者満足度 を向上させる
開発者満足度は 生産性 と相互作用する
開発者満足度の向上は 離職率 の低下させる
問題の解決策が複数ある場合、一般的に保守容易性が一番向上する手段を常に選択すれば良い
https://scrapbox.io/files/66bb5b76862c22001d3d0a55.png
もちろん例外はある
保守容易性を維持するには、アーキテクチャ を構築し、そのアーキテクチャを維持することが重要
アーキテクチャ は開発者満足度や生産性の向上、意思決定、離職率の低下に間接的に影響を与える
hr.icon
保守容易性とは？
コードに対する 変更容易性 のこと
保守性 が高いかどうか radish-miyazaki.icon
https://quality.arc42.org/qualities/maintainability
非機能要件 の 1 つであり、その中でも以下の理由から最重要である
ソフトウェアの保守容易性が高いとは、変更が容易であることを意味する
変更が容易であれば、柔軟性 が高く、モジュール化 もしやすくなっている可能性が高い
セキュリティ の強化や 信頼性 の向上、スケールアップ、パフォーマンス 向上など、他の非機能要件にもつながる
もちろん機能追加もしやすいので、機能要件 にもつながる radish-miyazaki.icon
保守容易性によって実装可能になる機能
以下の理由から、機能要件を満たすことよりも『保守容易性』のほうが重要である
ソフトウェア開発で一番重要なのは、ユーザに価値（機能）を提供することである
しかし、保守容易性が低いと機能を追加するのに多くのコストと時間がかかる
https://blog.logrocket.com/wp-content/uploads/2022/12/technical-debt-graph.jpg
開発者とそれ以外のメンバとの 軋轢 も生まれやすくなる
コミュニケーションコスト の肥大化にもつながる
そのため、保守容易性には 投資 する価値が十分にある
三方良し の状態に持っていく
チームメンバ全員で、投資の マインドセット を持ち合わせる radish-miyazaki.icon
Working Code Isn't Enough#6580125875d04f0000c5dad4
Strategic Programming の採用
「保守性が低いにも関わらず、成功しているソフトウェアも存在する」という反論
Tactical Programming によるアプローチ
Working Code Isn't Enough#6580214f75d04f00006dd776 とほとんど一緒のこと radish-miyazaki.icon
このようなソフトウェアは、以下の 2 つの条件のどちらかを満たしている
1. ソフトウェアとしての寿命が尽きかけており、変更がほとんど発生しない
2. 金銭的に裕福な組織が所有するソフトウェアであり、問題の解決に対してお金を払うことへの抵抗が無い
「BDUF を行うべき」ということではないが、事前にある程度の設計は必要
アーキテクチャ を選出し、ソフトウェアの構築が間違った方向にいかないようにする
本書では ヘキサゴナルアーキテクチャ を用いて Clean Architecture にする
warning.icon もちろん 銀の弾丸 ではないため、すべてのソフトウェアに適しているわけではない
保守容易性によって向上する開発者満足度
保守容易性が高いと、開発者満足度（developer joy）が向上する
https://scrapbox.io/files/66bb52451eb44e001c5c5e27.png
開発者満足度
開発者が今の環境に満足しているか（本来の能力を発揮できる環境か）を指す
SPACE フレームワーク の S: Satisfaction and well-being（満足度および健全性）
開発者体験（developer experience）や 開発者有効性（developer enablement）としても知られている
開発者満足度は 生産性 と相互に作用する
満足度 → 生産性: 開発者が幸福であれば、より優れた仕事をするようになる
生産性 → 満足度: 開発者が自身の仕事に誇りを持てるのであれば、より満足度を得られるようになる
https://scrapbox.io/files/66bb5230d49c49001cca372d.png
開発者満足度は 離職率 の低下にもつながる
https://scrapbox.io/files/66bb4beb327389001c66f0ca.png
保守容易性によって結果が変わる意思決定
ある問題を解決する選択肢が複数ある場合、過去に用いた パターン や 原則 を慣習的に適用して選択しがち
パターン や 原則
DRY
依存性の注入
Builder パターン
これらのパターンのほとんどは 保守性 を向上させる効果がある
開発者が毎日行っている判断には、意識せずとも保守性容易性が関わっている
今まで経験したことが無い場合であっても、同じように 保守容易性が一番向上する手段を選択 すればよい
https://scrapbox.io/files/66bb533214f81a001d445be7.png
https://scrapbox.io/files/66bb5b76862c22001d3d0a55.png
https://www.youtube.com/watch?v=QvK3Pxmwcyc
もちろん、他の一般的な原則と同様、保守容易性が向上しない手段が最善のケースもある
保守容易性の維持
改善したコードが、本当に保守性を上げているのか知るにはどうしたらよい？
保守/容易性を維持するにはどうしたらよい？
A. アーキテクチャ を構築し、そのアーキテクチャを維持する
優れたアーキテクチャは、どのようにコードを書くのか簡単に把握できるようになっている
そして、そのようなコードは機能の追加・修正を簡単に行えるようになっている
∵ 各 コンポーネント 間の 依存関係 が明確になっており、複雑になることがない
優れたアーキテクチャは開発者満足度や生産性の向上、離職率の現象、意思決定に間接的に影響を与える
https://scrapbox.io/files/66bb53eb79c083001db0a536.png