C# よくある問題

ソフトウェア開発におけるYAGNIの原則：抽象化や汎用コードは本当に必要か？

[[academy-video-youtube({"vid"："_Al7qI4vMt0", "start_time"："0", "title"："抽象化や汎用コードは本当に必要なのか？ (YAGNI)"、"作成者": "デレク・コマーティン"、"長さ": "7 分 06 秒"})]]

ペースの速いソフトウェア開発の世界では、開発者はしばしば、将来に向けてアプリケーションを構築することで、将来性を確保しようと努めます。しかし、CodeOpinion.comの Derek Comartin 氏が洞察に満ちたビデオ"Do You Really Need That Abstraction or Generic Code?"で警告しているように、投機的なニーズのために構築すると、不必要な複雑さが生じ、貴重なリソースが無駄になることがよくあります。

この記事では、デレックによるYAGNIの原則の実践的な説明を、実世界の例や開発者の経験を用いて説明し、日々のコーディングでYAGNIをよりよく理解し、適用できるようにします。クリーンコード、アジャイルソフトウェア開発、あるいは単に不要な機能を避けたいなど、デレクの解説は、地に足のついた道筋を示してくれます。

YAGNIとは何ですか? 必要のないものは作らない

この議論の核となるのは、エクストリーム・プログラミングとリーンソフトウェア開発の重要な概念である"You Aren't Gonna Need It"の略である"YAGNI原則"です。デレクが説明するように、YAGNIは開発者に対し、将来必要になると思われる機能や特徴を実装するのではなく、現在の要件に集中するよう伝えています。

Derekがニュアンスを付け加えます：投機的なコードを書くことは避けるべきですが、後で適応できないような手錠もかけたくありません。課題は、役に立つかもしれない機能に時間を費やすことを避けつつ、変更を受け入れることです。これは、アジャイルソフトウェアやソフトウェアエンジニアリングに共通するジレンマです。

彼は、YAGNIのよくある2つの誤用について説明する：

1.機能計画 - 将来の要件を予測し、今すぐ構築を開始します。

2.コードの抽象化 - 既存のコードを早期に一般化または抽象化し、必要となる可能性のある他の機能を推測しています。

どちらの場合も、その結果、無駄な努力、複雑さの追加、機能の追加といった、優れた実践やKISSの原則（Keep It Simple, Stupid）とは正反対のことが起こります。

実際の例：出荷通知システム

説明のために、デレクは、荷物が配達されるとユーザーにSMSを送信する出荷管理システムを例にしています。システムはTwilioを使用しており、この機能は、配信イベントを処理し、連絡先情報を取得し、メッセージを送信することで機能します。

このわかりやすいコード開発プロセスは、現在の要件に対応しています。シンプルで、テスト可能で、価値を提供するものです。しかし、そこで疑問が生じます：将来的にSMSプロバイダーを変更したい場合はどうすればよいのでしょうか？

ここで、多くの開発者がYAGNIの原則を誤って使用しています。彼らは、別の実装が後で来るかもしれないので、今すぐSMSのロジックを抽象化する必要があると想定しています。そこで、ISmsServiceのようなインターフェイスを作成します。

抽象化：存在しないかもしれない未来のために構築していますか?

Derekは、この初期の抽象化に挑戦しています。実装が1つしかなく、プロバイダーを切り替える現在の要件がないのであれば、なぜ抽象化するのでしょうか？あなたは、実現しないかもしれない将来のニーズにおいて、生活を容易にするために不必要な複雑さを追加しています。

彼はさらに、ソフトウェア・エンジニアリングのコストを説明する。最終的に2つ目のプロバイダを追加したとき、インターフェイスがTwilio特有のニーズ（電話番号の "from "ロジックのような）に密結合しすぎていることに気づきます。突然、抽象化が仇となります。このように、限られた知識の上に構築された抽象化は、しばしばバグを引き起こし、リファクタリングを複雑にします。

ここで重要なのは、時間を節約するのではなく、文脈が不十分なために間違ったものを作っているということです。

早すぎるジェネリック化：開発者の罠

コンピュータサイエンスのプロジェクトで最もよく見られるYAGNI違反のひとつは、必要以上に汎用的なものを作ろうとすることです。デレクは、SMSと電子メールによる通知を1つの汎用的な通知システムにグループ化した別の例を通して、このことを説明しています。

これを行うには、開発者は、NotificationType（SMSまたは電子メール）、ユニバーサルアドレスフィールドを定義し、両方を処理する単一のサービスを作成することができます。しかし、この過度に抽象的な設計は、結局ロジックを複雑にし、壊れやすく保守が難しい条件付きコードパスを作成することになります。

これは典型的なフィーチャークリープであり、リーンソフトウェア開発と堅実な原則を無視した特徴です。アジャイルソフトウェア開発プロセスでは赤信号です。

変更よりも拡張を優先する

デレクは、過剰なエンジニアリングではなく、最もシンプルなソリューションアプローチを提案しています。後にメール通知をサポートする必要が生じた場合は、その機能を個別に実装すればよいのです。

イベント駆動アーキテクチャを使用して、各イベントは、複数の独立したハンドラをトリガすることができます。例えば、SMS用のハンドラとEメール用のハンドラがあります。他方に影響を与えることなく、後で一方を削除することができます。この方法はシンプルさを推進し、変更要件をサポートし、関心の分離を尊重することを促進します—これらはすべてアジャイルとテスト駆動開発のベストプラクティスに整合しています。

過剰な設計ではなく、拡張可能なシステムを構築することで、あらゆる可能性のある未来を予測することなく、柔軟性を維持することができます。これが、不必要な複雑さを避け、適応性を維持する方法です。

YAGNIに違反することの本当の代償

デレクは、不必要な機能を構築することの本当のコストを強調します：

使わないものを作るのに費やす時間
すぐに価値を提供しない複雑さ
未使用または過剰に構築されたコードを維持しなければならなくなった開発者の所有コストの増加
過剰なエンジニアリングによるバグやエラーの可能性

これは、アジャイルソフトウェア開発のもう1つの基本原則である、"後で価値を提供するのではなく、今すぐ価値を提供することに集中する"と一致しています。

彼は、経験豊富な開発者は、将来のニーズについて自分の直感を信じるという間違いを犯しがちだが、それは間違っていると指摘する。経験を積んでいても、数カ月後にシステムが必要とするものを予測することは、多くの場合、負けるゲームです。

最後に思うこと：文脈が重要で、シンプルさが勝つ

デレクは最後に、設計原則や抽象化に反対しているわけではないことを明らかにした。実際、彼は進化できるシステムを構築することを信条としています。しかし、間違いは、現在の正当な理由なしに物事を実装すること、つまり本質的にYAGNIに違反することである。

彼は開発者に、"今価値のあるコードを書き、機能を実装する"ことを奨励している。現在のユーザーを犠牲にして将来の要件を追い求めることは避けましょう。クリーンコードにこだわり、投機的な構造に閉じ込めることなく変更をサポートする設計戦略を支持してください。

また、多くのプロジェクトでよくある"将来のために作ったのに必要なかった"というような、開発者自身のYAGNIホラーストーリーを共有するよう求めている。

結論開発プロセスにYAGNIを適用する

YAGNIの原則は、開発者のツールボックスの中で最も価値のあるツールの1つです。アジャイル、リーン、KISSの哲学に沿い、必要なものだけを作り、それ以上のものは作らないことを思い出させます。 Derek Comartin氏のビデオでは、実際のコードや開発プロセスの例を通して、この考え方を分解し、YAGNIを効果的に適用する方法について明確な指針を示しています。

抽象化レイヤー、汎用クラス、追加機能を追加したくなったときは、立ち止まって自問してください：