将来のプルーフコード
私が働いている場所では、開発者は常に「将来のためにこれを追加しました」または「いつか欲しいと思うので、これを行うのは良い考えだ」と言っています。彼らが将来の変化を予測しようとすることに積極的に取り組んでいるのは素晴らしいことだと思いますが、それは不必要であり、必要とされないかもしれない、したがって非生産的なコードを書くリスクがあると思わずにはいられません（また、一部の開発者は何かを試したいだけだと思いますそれのために新しい）。優れた、整理されたコードを記述しただけでは、将来の証明の引数は無効ですか？
まず第一に、明確にする必要があるいくつかの事柄があります：
- 今後の証明はnotを追加することです。
- 簡単に既存の機能を損なうことなくコード/機能を追加できることを将来的に保証することです。
つまり、「将来性のある」コードを書くことは、コードが疎結合の方法で、十分に抽象的に書かれていることを保証しているだけでなく、抽象化レベルを完全に隠さないコードでもあるので、常により低い抽象化レベルに進む方法があります必要であれば。
将来の証明コードの記述はそれ自体が芸術であり、SOLIDコンポーネントのバージョン管理、懸念事項の分離、階層化、機能の抽象化のための実践と密接に結び付いています。将来の証明にはnothingがあります。事前に機能を追加することで行いますが、既存のコード/ライブラリの優れた設計を通じて、将来的に機能を非破壊の方法で追加できるようにします。
私の2c
長期間使用しないコードは記述しないでください。それはその時点でのニーズに適合しない可能性が高いため、役に立たないでしょう（定義上、まだそれはわかっていません）。
予期しない問題状況に対してコードを堅牢にし、正常な回復またはフェイルファストを可能にしますが、将来の使用のためにコードを記述しないでください。
これを確実にする良い方法は、テスト駆動の設計と開発を使用することです。テストケースは、仕様とユースケースから派生しています。すべてのコードはテストに合格する必要があります。不要なコードは記述しないでください。このようにすることで、必要かどうかを簡単に判断できます。
コードの作成将来の証明とコードの作成将来必要になる場合は2つの非常に異なるものであることを理解することが重要です。前者は優れたアプリケーションにとって非常に重要であり、それよりも小さいものは通常、適切なコーディング方法ではありません。
私にとって、コードの将来の証明は、進化するテクノロジーとやり取りできるようにコードを書くことです。これにはコードのモジュール化が含まれるため、アプリケーションの各部分は、アプリケーション全体の言語やテクノロジーとは無関係に相互作用できます。この良い例は、XMLまたはJSONを使用して、アプリケーションの異なる部分の間でデータを渡すことです。テクノロジーが進化しても、常にXMLおよびJSONを読み取ることができる可能性は非常に高くなります。
上記と同様に、SOAPまたはREST APIを介してアプリケーションの一部を公開すると、APIは同様のことを実現します。テクノロジーが進化しても、必ずしも新しいテクノロジーは引き続き古いテクノロジーと通信できるため、アプリケーションのすべての部分を書き直してください。
コードが必要な場合に備えて、コードのテストはほとんどまたはまったくない可能性が高いため、非常に危険だと思います。
したがって、必ずコードの将来を保証します（NASAは引き続きFortranを使用して宇宙船を送ります）が、「念のため」コードを記述しないでください。
実稼働環境でコードを有効にした回数を考えて、「2年前に書いた神に感謝します！」と考えました。
コードは簡単に変更/拡張できる必要があります。すぐに必要ではないコードを追加しないでください。これは、非常に誤ったセキュリティの感覚を与え、変化する要件の世界で開発/テストリソースを浪費します。
他の多くの回答は、ある種の大きな設計問題に対処するか、かなり抽象的なものです。将来何が起こるかという観点から考える場合、コードを助ける将来性があるための明確なテクニックを定義できます。
主に、将来誰かがコードに機能を追加しようとしたり、コードを別の場所で再利用しようとしたりすることを第一に考えます。また、コードの機能を修正しようとする場合もあります。明らかに、優れたクリーンなコードを用意することが必要な開始点ですが、実行できる特定のテクニックもあります。
防御的プログラミング：現在のアプリケーションが実際に必要とするものを超えて入力チェックを実行します。 APIを呼び出すときは常に、それらの入力が予期したものであることを確認してください。将来的には、新しいバージョンのコードが混在するようになるため、エラーとAPIの戻りの範囲は、現在のものから変更されます。
未定義の動作を排除：多くのコードには、どこからともなく進化する動作があります。入力の特定の組み合わせにより、特定の出力が得られますが、実際には意図されていませんでした。今や必然的に誰かがその振る舞いに依存するでしょうが、それが定義されていないので誰もそれについて知りません。将来的に動作を変更しようとする人は、意図せずに物事を壊してしまいます。ここで安全性チェックを使用して、コードの未定義の使用をすべて削除/ブロックしてください。
自動テストスイート：ユニットテストの必要性について書かれたボリュームを見つけることができると思います。ただし、将来のプルーフについては、これは誰かがコードをリファクタリングできるようにするための重要なポイントです。クリーンなコードを維持するにはリファクタリングが不可欠ですが、適切なテストスイートがない場合、安全にリファクタリングすることはできません。
分離と分離：カプセル化と適切なモジュール化は優れた設計原則ですが、それを超える必要があります。ライブラリ、API、または製品を使用する必要があることがよくありますが、これらには将来の問題がある可能性があります。おそらく品質の問題、ライセンスの問題、または著者による継続的な開発が原因です。これらの場合、あなたとこのコードの間にレイヤーを配置するために余分な時間がかかります。 APIを必要なものだけにスライスすることで、カップリングが非常に低くなり、将来の交換が容易になります。
変更、追加を正しく実装しやすくするという意味で、優れた、クリーンで、よく整理されたコードis将来性があります。
「Future Proof」はせいぜい「疎結合設計」を意味します。人々が「将来の証拠」と言うとき、人々の80％は「柔軟」を意味します。時々彼らはそれを試してクールに聞こえるように言う。しかし、少なくとも彼らは時間通りに機能する何かを提供しています。
最悪の場合、「将来の証拠」は無意味です。時間の20％は、単に何かを提供するのではなく、代替テクノロジーの研究に時間を浪費する言い訳です。彼らは何も提供していません（または彼らが提供しているものは当面の問題には複雑すぎます）。
2つのEdgeケースがあります。
確実な先見。 1つは実際にcan未来を正確に予測します。この場合、この強力な見通しをコードの将来の証明に適用してください。より良い、絶え間ない見通しを適用して市場動向を予測し、早期に引退してコーディングを停止する.
1つは未来を「動かす」ことです。つまり、現在導入されているものを書き直す必要がある将来の展開に対応できる新しいテクノロジーがいくつかあります。それは、このクールな未来のものを最初に配備しないのは奇妙です。
プロジェクト "B"が "A"の即時の書き換えにつながることを認識して、プロジェクト "A"を提供する必要があります。この場合のみ、将来の証明「A」ができる可能性があります。
[〜＃〜] yagni [〜＃〜]= あなたはそれを必要としないだろう 。
あなたの本能は正しいです。彼らのコードは不必要で、メンテナンスとテストの負担を追加し、具体的なビジネス価値のないものに時間を浪費します。
関連項目： 金メッキ 。
質問のタイトルを無視して、「誰かがいつかそれを欲するかもしれないので、物を置く」ことについての主要な点を固執します...
答えはいいえだ。決して。今日必要のないコードのステッチを記述しないでください。理由は次のとおりです。
- プログラムは必要以上に複雑になりました。
- この機能が必要になることはないので、時間を無駄にしています。
- 将来誰かがそれを要求した場合、機能の要件はどうなるかわかりません。したがって、それを理解して、とにかく変更する必要があります。
最初のポイントが最も重要だと思います。さまざまな顧客向けの汎用コードで悩まされているシステムや、不要な機能が満載の機能を満載したシステムを使用したことがある場合は、機能のために機能を維持または拡張するためにどれだけ余分な時間と労力がかかるかがわかります。それ。だから絶対に避けてください。