将来の校正コード

私が仕事をしている開発者は、「将来のためにこれを追加しました」または「いつか欲しいと思うので、これを行うのは良い考えだと思う」といつも言っています。彼らが将来の変化を予測しようと積極的に取り組んでいるのは素晴らしいことだと思いますが、それは不必要であり、決して必要ではないかもしれないので非生産的なコードを書くリスクがあると考えるのは仕方がありませんそれのために新しい）。適切で整理されたコードを書くだけでは、将来の校正の議論は無効ですか？

まず第一に、説明が必要なことがいくつかあります。

• 将来の校正では、追加は行われません。
• 将来の校正により、既存の機能を損なうことなくコード/機能を簡単に追加できるようになります。

これは、「将来性のある」コードを記述することで、コードが疎結合の方法で十分に抽象的に記述されることを保証しますが、抽象レベルを完全に隠さないコードでもあるため、常に下位抽象レベルに移動する方法があります必要ならば。

将来の証明コードを書くこと自体が芸術であり、コンポーネントのバージョン管理、懸念の分離、階層化、機能の抽象化のためのSOLIDプラクティスと密接に結びついています。将来の校正はありません、何もなく、あなたが将来的に機能を追加できることを確認することで、事前に機能を追加して行うために非破断既存のコード/ライブラリの優れた設計により、方法。

私の2c

長期間使用されないコードを書かないでください。おそらく、その時点でのニーズに合わない可能性が高いため、役に立たないでしょう（定義上、まだわかりません）。

予期しない問題の状況に対してコードを堅牢にし、グレースフルリカバリまたはフェイルファーストを可能にしますが、将来の使用に備えてコードを記述しないでください。

それを確実にする良い方法は、テスト駆動の設計と開発を使用することです。テストケースは、仕様とユースケースから派生します。すべてのコードがテストに合格する必要があります。不要なコードは記述しないでください。このようにすることで、必要かどうかを簡単に判断できます。

コードを将来的に保証することと、将来必要になった場合にコードを書くことは、まったく異なる2つのことであることに気付くことが重要です。前者は優れたアプリケーションにとって重要であり、通常は少ない方が良いコーディング慣行ではありません。

• 私にとって、コードを将来的に校正することは、進化するテクノロジーとやり取りできるようにコードを書くことです。これにはコードのモジュール化が含まれるため、アプリケーションの各部分は、アプリケーション全体の言語や技術とは独立して対話できます。この良い例は、XMLまたはJSONを使用して、アプリケーションの異なる部分間でデータを渡すことです。テクノロジーがどのように進化しても、XMLとJSONを常に読み取ることができる可能性が非常に高くなります。

• 上記と同様に、SOAPまたはREST APIを介してアプリケーションの一部を公開すると、同様のことが実現します。どんな技術が進化しても、新しい技術は古いものと通信できるので、必ずしもアプリケーションのすべての部分を書き直す必要はありません。

• 必要な場合にコードを書くという点では、コードにテストがほとんどまたはまったくない可能性が高いため、非常に危険だと思います。

ですから、どうしてもコードの将来性を保証してください（NASAはまだFortranを使用して宇宙船を送ります）が、「万が一に備えて」コードを書いてはいけません。

実稼働環境でコードを有効にして、「2年前に書いてくれてありがとう！」と思った回数を考えてください。

コードは簡単に変更/拡張可能でなければなりません。すぐに必要ではないコードを追加しないでください。これは、非常に誤ったセキュリティ感覚を与え、要件が変化する世界で開発/テストリソースを無駄にします。

他の多くの答えは、ある種のより大きな設計問題に対処するか、むしろ抽象的なものです。将来何が起こるかを考える場合、コードの将来性を保証するのに役立ついくつかの明確な手法を定義できます。

主に、将来誰かがコードに機能を追加しようとするか、コードを他の場所で再利用しようとすると考えます。また、コードの機能を修正しようとする場合もあります。明らかに、きれいなコードを用意することが出発点として必要ですが、実行できる特定の手法もいくつかあります。

防御的プログラミング：現在のアプリケーションが実際に必要とするものを超えて入力チェックを行います。APIを呼び出すときはいつでも、その入力が予期したものであることを必ず確認してください。将来、人々は新しいバージョンのコードを一緒に混ぜることになるので、エラーの範囲とAPIの戻り値は現在のものから変わるでしょう。

未定義の動作を排除する：多くのコードには、どこからともなく進化する動作があります。入力の特定の組み合わせは、実際には誰も意図していない特定の出力につながりますが、そのようになります。必然的に誰かがその振る舞いに依存するようになりますが、定義されていないので誰もそれについて知りません。将来、振る舞いを変えようとする人は、うっかり物を壊してしまいます。今すぐ安全チェックを使用して、コードの未定義の使用をすべて削除/ブロックしてください。

自動テストスイート：ユニットテストの必要性について書かれたボリュームを見つけることができると確信しています。ただし、将来の校正に関しては、これは誰かがコードをリファクタリングできるようにするための重要なポイントです。リファクタリングはクリーンなコードを維持するために不可欠ですが、テストの優れたスイートがない場合、安全にリファクタリングすることはできません。

分離と分離：カプセル化と適切なモジュール化は優れた設計原則ですが、それを超える必要があります。ライブラリ、API、または製品を使用する必要があることがよくありますが、これらには疑わしい未来があります。品質の問題、ライセンスの問題、または著者による継続的な開発が原因である可能性があります。これらの場合、ユーザーとこのコードの間にレイヤーを配置するのに余分な時間がかかります。必要なものだけにAPIをスライスして、カップリングを非常に低くして、将来の交換を容易にします。

適切で整理された適切なコードは、変更や追加を正しく実装しやすくするという意味で、将来にわたって使用できます。

「将来の証明」とは、せいぜい「疎結合設計」を意味します。80％の人が「将来の証拠」と言うとき、「柔軟」を意味します。時々彼らはそれを言ってクールに聞こえるようにします。しかし、少なくとも彼らは時間通りに機能する何かを提供しています。

最悪の場合、「将来の証明」は無意味です。20％の時間、それは単に何かを提供するのではなく、代替技術を研究する時間を無駄にする言い訳です。彼らは何も提供していません（または、彼らが提供しているものは目前の問題に対して複雑すぎます）。

2つのエッジケースがあります。

1. 確実な先見性。実際にできること将来を正確に予測するます。この場合、この強力な先見の明を将来のコードの証明に適用してください。さらに、市場の動向を予測し、早期に廃止してコーディングを停止するために、確実な先見性を適用してください。

2. 1つは、未来の「運転」です。つまり、現在提供されているものの書き直しを必要とする、将来展開する準備ができた新しいテクノロジーがあります。最初にこのクールな未来のものを展開していないのは奇妙です。

   プロジェクト「B」が「A」の即時書き換えにつながることを知って、プロジェクト「A」を提供する必要があります。この場合のみ、将来の証明「A」が可能になる場合があります。

ヤグニ = 君は必要じゃない。

あなたの本能は正しいです：それらのコードは余分であり、メンテナンスとテストの負担を追加し、具体的なビジネス価値を持たないものに時間を浪費します。

参照：ゴールドメッキを。

質問のタイトルを無視し、「誰かがいつかそれを望むかもしれないので、物を入れること」についての主要なポイントを固執します...

答えはいいえだ。決して。今日必要のないコードを書いてはいけません。その理由は次のとおりです。

1. このプログラムは、必要以上に複雑になっています。
2. この機能は必要ないかもしれないので、時間を無駄にしました。
3. 将来誰かがそれを要求した場合、その機能の要件がどうなるかはわかりません。したがって、とにかくそれを把握して修正する必要があります。

最初の点が最も重要だと思います。さまざまな顧客向けの汎用コードでいっぱいのシステムを使用したことがある場合、または必要のない機能を大量に使用している場合、機能の維持または拡張にどれだけの余分な時間と労力がかかるかがわかります。それ。したがって、すべてのコストを避けてください。