本当の見通し
まあ、私は下位互換性のサポートが悪いターゲットだと言っているつもりはありません。 多くの場合、これにより誰にとっても簡単になります。 うーん、多分いつもではない。 短期的には、下位互換性は大したことではありませんが、誰もがその恩恵を受けます。 各変更は小さく、比較する対象が少ないため、メンターにとっては簡単です。 更新の苦痛が少ないため、ユーザーにとっては簡単です。
推論の欠陥
下位互換性の問題は、リリースごとに大量のジャンクが追加されることです。 時間が経つにつれて、これによりプロジェクトの開発が停止し、新しいアイデアを実装するときにクリーンなコードを維持することがより困難になります。 これにより、石器時代のプロジェクトを保持するアンカーが作成されます。
これは、技術的負債の増大の問題です。 考えてみてください。 プロジェクトの最初のバージョンでAPIの設計を間違えた場合、この間違いは多くのバージョンを悩ませます。 あなたはただこの借金を取り、それを完済することはできません。 そして、これは真空中の球状の馬ではありません*。 PHPの文字列と配列の関数を見てください。 それらのパラメーターがこの順序で示されているのはなぜですか？ それらを変更すると、下位互換性がもたらされるためです！
先見性
後方互換性の主な問題はイデオロギーです-書かれたものはすべて最初は正しいと考えられています。 すべてが最初から完璧であれば、互換性のサポートは簡単です。 理論的に。 しかし、実際にはそうではありません。 他のことと同じように、私たちは初めてすべてを正しく行うことはありません。
それが新しいコンセプトを紹介したい理由です。 なぜ、下位互換性を気にするのではなく、上位互換性を提供するのか。
翻訳の互換性
コンセプトの基本：
現在作成しているコードの将来のニーズを予測し、後で下位互換性を心配しないように十分に柔軟に書きます。
これは高貴な目標です...不適切ですか？
まあ、そうでもない。 完全に機能するためにコードは必要ありません-そのタスクを実行するために必要です。 より良い間違いをして最初は間違ったことをしますが、将来このコードが必要なすべてのタスクを解決し、将来のニーズを満たすことを最初に想像するよりも簡単です。
動作中
私はこのイデオロギーを一年中守ります。 パスワード用のAPIを開発したとき、このアプローチが使用されました。 それが、
$cost
と
$salt
代わりに
$cost
$options
パラメータがある理由です。 私は将来の変更を予測し、このためにAPIを適合させようとしました。 うまくできましたか？ 将来この質問に答えることができます。 しかし、下位互換性のイデオロギーに従った場合よりもはるかに良くなったと思います（それに応じて、自分がやりたいことは何でもできると思います）。
function password_hash($password, $algo, array $options = array())
TL / DR
次回、変更を提案し、下位互換性を検討するのではなく、将来のニーズに合わせてこれをどのように実装できるかを考えます。 下位互換性の障害を防ぐ最善の方法は、それらを最初に計画することです。 私は後方互換性を無視すると言っているわけではありませんが、未来に焦点を合わせ、過去を適切な場所に置く方が良いです。
未来は私たちが影響を与えることができるものです。 間違いはすでに行われています。過去にあります。 それらを永遠に引きずらないでください...
*オリジナル：そして、これは理論的な問題すらありません
この翻訳には明らかに多くの欠陥が含まれています。私は言語を学んでいるだけです。PMのエラーを指摘してくれてありがとう、ありがとう。