SOLID原則vs YAGNI
SOLIDの原則はいつYAGNIになりますか？
プログラマーとして、複雑さ、保守性、構築時間などの間、常にトレードオフを行います。とりわけ、選択を行うための最も賢い2つのガイドラインは、私の頭の中でSOLID=原則とYAGNIです。それが必要ない場合は、構築せず、きれいにしてください。
たとえば、 SOLIDのダイムキャストシリーズ を見ると、かなり単純なプログラムとして始まり、かなり複雑なプログラムになっていることがわかります（はい、複雑さは、ビホルダー）、しかしそれでも私は不思議に思います：いつSOLID原則は不要なものに変わるのですか？すべての確実な原則は、後の段階で変更を加えることを可能にする作業方法です。しかし、解決する問題がかなり単純なもので、使い捨てのアプリケーションである場合はどうなりますか？または、SOLID原則は常に適用されるものですか？
コメントで尋ねられたように：
スクリーンキャストに基づいてアプローチを判断することは常に困難です。なぜなら、デモ用に選択された問題は通常非常に小さいため、SOLIDのような原則を適用すると、ソリューションが完全に過剰設計されているようにすぐに見えるためです。
SOLID=原則はほとんど常に有用です。いったんそれらに習熟すると、それらを使用することは意図的に考える必要があるもののようには見えなくなります。それは自然なことです。多くの使い捨ての単発アプリがそれ以上になるのを見て、私は今あなたが知っているだけではないので、私は何かを捨てるつもりだと言って恐れています。
私が通常採用するアプローチは、特定のタスク用のシンプルなアプリを作成している場合、機能する数行のコードを優先して、大がかりな原則を忘れることがあります。さらに変更を加えるためにそのアプリに戻ってきた場合は、時間をかけてそれを変更しますSOLID（少なくともある程度、原則の100％の適用はめったにないので実現可能）。
大きなアプリでは、小さなものから始め、プログラムが進化するにつれて、SOLIDの原則を可能な限り適用します。この方法では、最後の列挙型まで全体を前もって設計しようとはしません。それは、私にとって、YAGNIとSOLIDが共存するスイートスポットです。
何よりもまず手元にある問題について考えてください。 YAGNIまたはSOLIDの原則を盲目的に適用すると、後で自分を傷つける可能性があります。私たち全員が理解できることは、すべての問題に適合する「1つの」設計アプローチがないということです。 「ワンサイズですべてに合う」と宣伝されている帽子を販売店が販売しているときにその証拠を見ることができますが、それはあなたの頭に合いません。大きすぎるか小さすぎる。
代わりに、SOLIDが対処しようとしている原則と問題、およびYAGNIが対処しようとしている原則と問題を理解することをお勧めします。アプリケーションのアーキテクチャとその他のアーキテクチャは、開発プロセス全体に関係しています。場合によっては重複することもありますが、それらは明らかに異なる問題です。
YAGNI（You Ai n't Gonna Need It [古風なアメリカの頭字語]）は、鋼鉄製の鉄筋コンクリート基礎を橋に追加する開発者の時間を節約することに関係しています。大丈夫。 1マイル幅の川にまたがり、いくつかのトラクタートレーラーをサポートする必要がある場合は、もちろん、追加の基礎工事が必要になります。本質的に、YAGNIはcurrentのニーズに合わせて全体像と設計を検討するように指示しています。これは、お客様がまだ特定していない潜在的なニーズの数を予測しているため、複雑すぎるものを作成する問題に対処しています。
SOLIDは、ブリッジの部品が適切に組み合わされ、長期にわたって維持できるようにする方法に関心を持っています。 SOLIDの原則は、木製の橋と鉄筋コンクリート橋に適用できます。
要するに、これら2つの概念は必ずしも互いに矛盾しているわけではありません。あなたが彼らがそうであると信じている状況に遭遇したとき、それは全体像を見る時間です。結論に応じて、SOLIDの原則の一部を廃止するか、または本当に必要であると判断するかもしれません。
使い捨てアプリケーションの場合、SOLIDの原則は必要ありません。それ以外の場合は常に必要です。
SOLIDとYAGNIは対立していません。優れたクラス設計により、アプリケーションの保守が容易になります。 YAGNIは、実際に必要な場合を除き、Sunの下ですべてを実行できるこの構成可能なモンスターにアプリケーションの機能を追加するべきではないと述べています。
それは、明確に定義された境界を持つ自動車クラス（SOLID）と、顧客が要求する前に自己修復する能力を持つ自動車クラス（YAGNI）の違いです。
アインシュタインに起因する引用があります（おそらく 実際のバリエーション ）：
「すべてを可能な限りシンプルにする必要がありますが、シンプルにする必要はありません。」
SOLID対YAGNIのトレードオフに直面したとき、それは多かれ少なかれ私が採用するアプローチです。プログラムが「スローアウェイ」コードであるかどうかわからないため、代わりにそれらを適用してください。したがって、 、機能する汚れの層を追加し、それをよりきれいなインターフェイスに磨きます...そして、適切なエントロピーのレベルに収束するまで繰り返します。
与えられた問題に対してプログラムを設計する方法はたくさんあります。 SOLIDは優れた設計の特性を特定するための試みです。SOLIDを適切に使用すると、プログラムの推論と修正が容易になるはずです。
YAGNIとKISSは、機能範囲に関係しています。より多くの種類の問題を解決するプログラムは、より複雑で抽象的なものです。その一般性が必要ない場合は、コードの作成に時間と労力を費やしています。それは理解と維持が困難ですが、付加価値はありません。
うまく設計されたプログラムは、必ずしも必要な機能だけに焦点を当てているわけではありません。必要な機能のみに焦点を当てたプログラムは、必ずしもうまく設計されているとは限りません。意思決定空間での2つの直交軸のみのトレードオフはありません。理想的なプログラムはモジュール式であり、本質的な機能のみを備えています。
あなたはYAGNIを始めるべきだと思います、そして必要があるときはいつでもそれをSOLIDifyしてください。
SOLIDがあるので、新しいクラスを追加するときに、リファクタリングする必要はありません。たとえば、実装を切り替えるだけです）、私の意見では、コードを単純に記述します。そして、あなたが何かを変更しているのを見つけたとき-SOLIDで変更してください（つまり、恐れられたリファクタリングSOLIDはあなたを救うはずです-それはそうではありませんt始めたばかりのときはとても悪い）。
とにかく（最初に）仕事をしなければならないので、時間を無駄にすることはありません。コードが必要なところはどこでも、きちんと整頓されています。
SOLIDの遅延評価と呼べると思います。