固い原則とヤグニ

ソリッド原則はいつYAGNIになりますか？

プログラマとして、複雑さ、保守性、構築時間などの間で常にトレードオフを行います。とりわけ、選択を行うための最も賢明なガイドラインの2つは、SOLID原則とYAGNIです。必要ない場合; ビルドせず、クリーンに保ちます。

たとえば、SOLIDのダイムキャストシリーズを見ると、かなり単純なプログラムとして始まり、非常に複雑なプログラムになります（最後にはい複雑さも見る人の目にあります）。私は不思議に思う：いつ固い原則はあなたが必要としない何かに変わるのか？すべての堅固な原則は、後の段階で使用して変更を加えることを可能にする作業方法です。しかし、解決すべき問題が非常に単純で、使い捨てのアプリケーションである場合はどうでしょうか？または、SOLID原則は常に適用されるものですか？

コメントで尋ねられたように：

• 固い原則
• ヤグニ

スクリーンキャストに基づいてアプローチを判断することは常に困難です。デモ用に選択される問題は通常非常に小さいため、SOLIDのような原則を適用すると、ソリューションが完全に過剰設計されているように見えるためです。

SOLIDの原則は、ほとんどの場合に役立ちます。それらに習熟したら、それらを使用することは、あなたが慎重に考えなければならない何かのように思えません。ただ自然になります。使い捨ての使い捨てアプリの多くがそれ以上になるのを見てきたので、あなたは知らないので、何かを捨てるつもりだと言うのが怖いです。

私が通常とるアプローチは、特定のタスク用のシンプルなアプリを作成している場合、機能する数行のコードを優先して、ビッグネームの原則を時々放棄することです。そのアプリに戻ってさらに変更を加えようとしていることがわかった場合は、（少なくともある程度は、原則を100％適用することはめったにできないので）少し時間をかけてそれを修正します。

より大きなアプリでは、私は小さなものから始め、プログラムが進化するにつれて、可能な限りソリッド原則を適用します。このように、最後の列挙型まですべてを前もって設計しようとはしません。それは、私にとって、YAGNIとSOLIDが共存するスイートスポットです。

何よりもまず手元の問題について考えてください。YAGNIまたはSOLIDの原則を盲目的に適用すると、後で自分自身を傷つける可能性があります。私たち全員が理解できることを願っていますが、すべての問題に適合する「1つ」の設計アプローチはないということです。店が「1つのサイズがすべてに合う」と宣伝されている帽子を販売しているが、頭に合わないという証拠を見ることができます。大きすぎるか小さすぎます。

代わりに、SOLIDが対処しようとしている原則と問題を理解することをお勧めします。YAGNIが取り組もうとしている原則と問題も同様です。1つはアプリケーションのアーキテクチャに関係し、もう1つは開発プロセス全体に関係していることがわかります。重複する場合もありますが、それらは明らかに異なる問題です。

YAGNI（You Ai n't Gonna Need It [古風なアメリカの頭字語]）は、より単純な木製の橋がうまくいく場合にのみ3フィート幅の小川にまたがることを目的とした橋に鉄骨鉄筋コンクリート基礎を追加する開発者の時間の節約に関係していますいいよ 幅1マイルの川にまたがり、いくつかのトラクタートレーラーをサポートする必要がある場合、もちろん、追加の基礎工事が必要になります。本質的に、YAGNIは現在のニーズに合わせて、より大きな全体像とデザインを見るように言っています。顧客がまだ特定していない多くの潜在的なニーズを予想しているため、複雑になりすぎるという問題に対処しています。

SOLIDは、ブリッジの各部分が適切に適合し、長期にわたって維持できるようにする方法に関心があります。木製の橋と鉄骨鉄筋コンクリート橋にSOLIDの原則を適用できます。

要するに、これらの2つの概念は必ずしも互いに矛盾しているわけではありません。自分がそうであると信じている状況に出くわしたら、全体像を見てみましょう。結論に応じて、SOLID原則の一部を廃止するか、本当に必要だと判断するかもしれません。

使い捨てのアプリケーションである場合、固い原則は必要ありません。それ以外の場合は常に必要です。

SOLIDとYAGNIは対立しません。優れたクラス設計により、アプリケーションの保守が容易になります。YAGNIは、実際に必要な場合を除き、アプリケーションをこの太陽の下ですべてを実行できる構成可能な怪物にする機能を追加すべきではないと述べています。

それは、明確に定義された境界（SOLID）を持つCarクラスと、顧客が要求する前に自己修復する能力（YAGNI）を持つCarクラスの違いです。

常に適用されるものはありません！建築宇宙飛行士に怖がらせないでください！重要なことは、これらの原則がどのような問題に対処しようとしているのかを理解することで、それらを適用することについて十分な情報に基づいた決定を下せるようにすることです。

最近、私はいつ単一責任原則を使用すべきかを理解しようとしていました（ここに私が思いついたものがあります）。

お役に立てれば！

アインシュタインに起因する引用があります（おそらく実際の引用のバリエーション）：

「すべてをできるだけシンプルにする必要がありますが、シンプルにする必要はありません。」

そして、それは多かれ少なかれ、SOLIDとYAGNIのトレードオフに直面したときに取るアプローチです。プログラムを「捨てる」コードかどうかわからないので、代わりに適用します。したがって、機能する汚れの層を追加してから、よりきれいなインターフェイスに磨きます...そしてエントロピーの適切なレベルに収束するまで繰り返します。うまくいけば。

特定の問題に対してプログラムを設計する方法はたくさんあります。SOLIDは、優れたデザインの特性を特定する試みです。SOLIDを適切に使用すると、プログラムの推論や変更が容易になります。

YAGNIとKISSは機能の範囲に関心があります。より多くの種類の問題を解決するプログラムは、より複雑で抽象的なものです。その一般性が必要ない場合は、理解と保守が難しくなりますが付加価値のないコードの作成に時間と労力を費やしました。

適切に設計されたプログラムは、必ずしも必要な機能のみに焦点を当てているとは限りません。必要な機能のみに焦点を当てたプログラムは、必ずしも適切に設計されているとは限りません。トレードオフはなく、意思決定空間には2つの直交軸があります。理想的なプログラムはモジュール式であり、重要な機能のみを備えています。

YAGNIを起動して、必要があるときはいつでもSAGIDifyする必要があると思います。

私が意味するのはSOLIDがあるので、新しいクラスを追加するとき、リファクタリングする必要はなく、単に実装を切り替えます（たとえば）、私の意見では、コードを簡単に書いて、あなたが変更していることがわかったらもの-SOLIDで変更します（つまり、SOLIDのリファクタリングの恐れがあなたを救うはずです-始めたばかりのときはそれほど悪くありません）。

とにかく（最初は）作業をしなければならないので、時間を無駄にしません。必要な場所ならどこでもコードはきれいで整頓されています。

SOLIDの遅延評価と呼ぶことができると思います。