Guzzle 4+
にアップグレードする方法はありません。バージョン3にバックエンドがあり、それをあまりにも長く高価にやり直しています。」 そして、WordPressからの最良の議論：「ほとんどのユーザーは5.1で共有ホスティングに座っているか、MVCを知らないため、完全なOOPに到達することはできません。」
ナンセンス。
レガシーコードは大きなNOです
おそらくこれは議論の余地のある結論かもしれませんが、現代のシステムにはレガシーコードの場所はないと確信しています。 あなたが熊手を研ぎ始め、松明に火をつける前に、私はいくつかの言葉を言います。 つまり、古い機能をサポートする理由はささいなものではなく、一部の人々がまだそれを使用しているという理由だけで、古いバージョンに遡って更新を追加します。 これらの人々の大半がそうであっても-そうしないでください。
明確にするために：長期サポート契約が終了するまで、以前のバージョンのエラーを修正します、はい。 バージョン
X
、バージョン
X-1
でリリースできる新しい機能を追加して、
X-1
ユーザーを怒らせないようにします。 同様に、バージョンXに
X-1
コードを追加することは、それが「便利になる」という理由だけで、許容できないと見なされるべきです。 それでも
X-1
料金を請求し、その上にアップグレードを構築する場合、非常に悪いビジネスプランになります。
しかし、私は誰がそのようなナンセンスを運ぶのですか？ たくさんの利害関係者と支援を伴う大規模なプロジェクトをサポートしたことはありません。 どれくらい時間がかかり、どのように機能するかは重要ではありません。潜在的に100倍安全で、1000倍速く動作する可能性があるからです。 そうでもない。 私の最大の子供は、ZF1に洗練されたバックエンドを備えた大手出版社のサイトでした。
ZF1
でプロジェクトを作成したことがある場合、このフレームワークは松葉杖とアンチパターンの渦であることがわかります。 アプリケーションがトラフィックの増加による劣化の兆候を示し始めたとき、私はアプリケーションの最も頻繁に使用される部分のフロントエンドを再構築し、ajaxおよびAPI呼び出しを完全に処理しました。 負荷が急激に低下したため、アプリケーションの他のすべての部分を
Zend Framework 2
に転送するのに十分な時間を
Zend Framework 2
。 同様のことをした人は、これが松葉杖とアンチパターンの同じ混合物であるが、わずかに密度が低いことを知っています。
大きな変化とリファクタリングは、有能な人々が彼らの背後にいる場合にのみ起こりうると言っています。 しっかりとしたアジャイル集会とブレーンストーミングセッションのみを行うのであれば、5年間LTS契約を交わしても愚かな見方をすることはできません。
たとえあなたが無料やオープンソースの仕事をしているとしても、もちろんX-1ユーザーの互換性を壊さないでください。 グローバルバージョンを使用して古いバージョンを開発し、それらを支持すると、下位互換性が失われる可能性があります。 1つだけを学ぶ-彼らは適応するか、死ぬ必要があります。
それでも、なぜ現代のシステムからレガシーコードを追放する必要があるのでしょうか？
無限のLTSの呪い
「できる限りすべてをサポートする」アプローチに加入すると、底なしの穴に埋もれ、数年後に製品を4種類のバージョンをサポートすることを余儀なくされたときに自分自身を見ると、壁に頭をぶつけますユーザーV1およびV2が拒否されても、拒否されませんでした。 視聴者を維持するために、開発者はしばしば自分の能力を超えて、大量のレガシーコードのくびきの下で正義を行っていません。 同じ理由で、WordPressは現在の状態になりました。 古いバージョンに連鎖させないでください。
これらのユーザーは重荷なので、いくらお金を払っても破壊されなければなりません。 彼らに動いて前進する機会を与えてください、彼らが有能であれば、彼らはあなたに追いつくでしょう。 そうでない場合、彼らはそれだけの価値はありません。
古いバージョンのサポートが長すぎると、自分にWPの呪いをかけます。 古いバージョンは脆弱であり、それらのサポートはバグを修正するためにより多くの努力と努力を必要とします。 これらの時間を費やして、新しいバージョンを作成し、ユーザーの移行を支援する開発者を雇います。
あなたは疎外され、上級ユーザーに悪影響を及ぼします
前回、
CMS
をインストールしたときに絶望的なレガシーコードに出くわしましたが、これは
Vagrant
環境で非常に難しいタスクであることが判明しました-誰もが（
Vagrant
の作成者も）広く知られている
symlink
の問題だけでなく、多くは
CMS
古いバージョンを残すため、 いくつかのモジュール/プラグインはまだアップデートをリリースしていません。 モジュールの更新がないため、なぜカーネルを更新するのですか？ 準備ができていないのに、なぜ物事を急ぐのですか？
レガシーコードを新しいバージョンのままにすると、動作するように見えるフランケンシュタインのモンスターになりますが、それは悪いものであり、潜在的な可能性がある新しいコードは、継承されたコードベースの混乱により開発できません。 このアプローチにより、90年代のどこかで立ち往生している開発会社の作業が容易になりますが、同時に、上級ユーザーが製品を使用するのが難しくなります。 テクノロジーに遅れをとって絶望的に遅れている群衆のために下された決定により、あなたは多くのお金を持ち込むことができる上級ユーザーを疎外し、悪影響を及ぼします。
それがどのように起こるかご存知です。レガシーブラウザーの機能をサポートするのに時間がかかりすぎ、その結果、これらの機能を使用するユーザーもいません。 ライブラリまたはコンテンツ管理システムのユーザーにも同じことが当てはまります-古い
CMS
気にしない人は、新しいバージョンで何をしているのか気にしないので、本当に必要以上に古いバージョンの過剰なサポートを心配する必要はありません。
失敗は時々成功の前兆となる
もちろん、これは単に不可能な場合もあり、そのような例外は非常にまれで価値のあるトレーニング資料です。 バージョン管理の興味深いケースの1つは、2番目と3番目のPythonです。 Pythonは驚くべき言語であり、ほとんど何でもできます。 しかし、それはあなたの目的のために特別に構築された言語と同じようには機能しません。これは万能の言語の共通の欠点です-彼らは何かを非常にうまく行うことができますが、彼らと仕事をするオプションはありません申し分なく。 Python 3が登場すると、互換性を損なういくつかの機能が導入され、第2バージョンのユーザーは簡単に切り替えられなくなりました。
「Py3パッケージではまだ十分ではありません」や「Py2にはこれをすべて書き直すにはあまりにも多くのコードがあります」などの言い訳のほとんどは、「必要なものを移植する」と「貧しいプログラマー、彼らはコードを書くことを余儀なくされています」それに応じて。 私は同意しますが 、いくつかの議論がありましたが、それらは原則として、もともと間違って設計されたプロジェクトを例として採用し、その結果、それらのばかばかしいほど大きなサイズになりました。
実際、今ではPy2とPy3の対立はすでに亀裂になっており、その両側にはプログラマーがいます。 しかし、多くの人は、Python 4が登場するまでに、バージョン3+への切り替えを非常に拒否した人々がPy2のままであり、非互換性がさらに大きくなるという事実を考えていません。 その時までに、彼らはすでに別の言語を習得し、現在の言語の変更に抵抗することはできなかったでしょう。 一方、障害を「大胆に」破ってコードを3+に書き直した人は、ためらうことなく、将来のバージョンの最新機能をすべて受け取ります。
後方互換性は事実上十分な遅延コンパートメントをスクラップし、新世代の開発者にPythonを準備しました。 私の意見では、これは大成功です。 プログラミングは、他の多くの人生の分野と同様に、依然として適者生存に基づいており、新しいテクノロジーを適切に使用できない場合は、邪魔にならないようにしてください。
アプリケーションとライブラリ/パッケージ
アプリケーションとライブラリの対立についての質問もあります。 つまり、フレームワークの新しいリリースを受け取ったときなど、「期限切れしない」ルールをアプリケーションに適用できる場合、ライブラリにも適用する必要がありますか？
はい
X+1
バンプを受け取ったライブラリは、進行するパスを明確にたどる必要があります。ライブラリのバージョンが公開された時点から、後者のバグ修正のみがサポートされます。
このようなライブラリを使用するアプリケーションは、APIに依存しているため、より困難な状況にあり、変更される可能性があります。 合理的なアプローチは、移行を開始する前に、安定性に関するコミュニティからのフィードバックを待つことです。 移行期間中、ライブラリ/フレームワークの古いバージョンと新しいバージョンの両方を使用したままにすることができ、必要なすべての部分をアップグレードした後、古いバージョンを削除する必要があります。 長くはかかりませんよね？
十分な大きさのアプリケーションがありません
「しかし、ブルーノ、いくつかのアプリケーションは巨大であり、それらを書き換えるのに数ヶ月かかるでしょう」とあなたは言います。 「ZF1からZF2への移行は1年の仕事です！」 アップグレードに同様の条件が必要な、十分な大きさのWebアプリケーションはありません。 さらに進んで、実際にはSymfonyやZendに匹敵するほどの大きさのWebアプリケーションは存在しないと言います。
もちろん、これらのフレームワークのいずれにも当てはまらないと言ったのは、非常にプロフェッショナルなコードからの超複雑なカバですが、タスクの分離の概念に従って、サービスをカプセル化し、アプリケーションをAPI修正すれば、フロントエンドをバックエンドとは別に書くことができます、アプリケーションのサイズや人気に関係なく、現在のコードに対する多くの障害から解放されます-理論家ではなく、チームにプログラマがいる場合。 知っている構造やアルゴリズムの数に関係なく、主なことは、移行中にそれらを十分に効果的に使用する方法を知ることです。
更新スキーム
更新する最良の方法は何ですか？ ソフトウェアアップデートには、アプリケーション/ライブラリの人気に関係なく開発者が順守する必要がある許容可能なオプションが1つだけあります。
- 新しいバージョンの新しいブランチを作成する
- 古いバージョン/ブランチを非推奨としてマークする
- 古いバージョンをさらにどれだけサポートするかを公に宣言する
- 古いバージョンのすべてのユーザーに警告する
- 新しいブランチ、古いブランチのみに新機能を実装する-バグ修正
- 古いバージョンのライフタイムが期限切れになったら、すべての終了を打ち切ります。 修正しないでください。助言しないでください。通常、ドキュメントから古いバージョンの言及を削除してください。 彼女を殺します。
この手順を完了した後、トラブルを継承することはありません。
この道をたどるプロジェクトの1つがGuzzleです。 彼は3+バージョンと4+を持ち、最新の生活を送り、常に進歩のピークにいることを望んでいます。
おわりに
Web開発者として、新機能やメジャーバージョンのアップグレードに関しては、レガシーコードを捨てるべきだと確信しています。 2か月以上前にリリースされたバージョンのコードを使用する大規模なプロジェクトがある場合、 特に使用する製品がビジネスにとって重要な場合は、すべてのアクティビティを停止し、新しいバージョンで書き直す必要があります。 移行を完了するのに2か月以上を必要とするほど大きなアプリケーションは世界にありません。もしあれば、ゼロから書き直す必要があります-Webはいつも思っていたよりずっと簡単です。
どう思いますか？ レガシーコードを無期限に保存する必要がありますか？ 特定のバージョンの数は？ 全部じゃないの？ サードパーティプロジェクトのレガシーコードについてどう思いますか？ 開発者は、使用するライブラリのレガシーの問題を心配する必要がありますか？ この記事は間違っていますか？ この投稿で、私はこれについて議論を始めたかったのです。結局のところ、問題や経験に関する私の見解は私の見解にすぎません。 以下のコメントで教えてください。