28

私たちが取り組んでいるプロジェクトのいくつかは、jQuery 1.4.2 以前に根ざしており、最新リリースのパフォーマンス エッジ (またはシンタックス シュガー) の欠如、廃止されたメソッドを使用することの屈辱、不快感の中間のどこかにあります。アクティブにメンテナンスされているライブラリの 3 年以上前のバージョンをデプロイすると、アップグレードが差し迫っています。

スムーズなロールアウトを確実にするために採用/再訪問できる、コミュニティで人気のあるいくつかのプラクティスは何ですか? 将来のアップグレードのために SDLC にどのように統合するのが最適でしょうか? jQuery などのライブラリの合理的なアップグレード スケジュールはどれくらいですか?

4

6 に答える 6

13

あなたの3つの質問に実際に答えるために、私が行った、または少なくとも推奨するいくつかのことを次に示します。

アップグレードをスムーズに展開するためのベスト プラクティス

  • テストがあります。これらは、JS および/またはブラウザー テストの単体テストにすることができます。これらは、少なくともプロジェクト内で使用される最も一般的で最も複雑な機能をカバーする必要があります。テストがない場合は、書きます。テストを書きたくない場合は、考え直してください。本当にテストを書きたくない場合は、少なくとも誰かが手動で実行できるユースケースのリストを用意してください。
  • アップグレードの前に、すべてのテストに合格することを確認してください。
  • 現在使用しているバージョンから最新リリースまでのすべての (メジャー) バージョンのリリース ノートをお読みください。API ドキュメントの削除済みおよび非推奨のカテゴリも参照してください。コードで jQuery UI を使用している場合は、インタースティシャル バージョンのリリース ノートとアップグレード ガイドも参照してください。これを行うとき、コードベースで変更する必要がある可能性があることを書き留めます (おそらく を頻繁に使用しますgrep)。
  • プロジェクトの現在の jQuery バージョンが 1.6.4 以上の場合は、jQuery Migrate プラグインを使用して、必要な作業をさらに評価することも検討してください。
  • アップグレードの対象とするバージョンを決定するには、そこに到達するために必要な作業、特定のバージョンの jQuery を必要とするサードパーティ ライブラリをプロジェクトで使用しているかどうか、あなただけが考慮できるその他の要因などに基づいて決定します。
  • チームと会って、コードベースに行う変更のリストを確認し、それに応じて作業を分割/割り当てます。おそらく、スクリプトやその他のツールを作成して支援してください。持っている場合は、チームのコーディング スタイル ガイド / ベスト プラクティス ドキュメントも更新する必要があるかもしれません。可能かつ望ましい場合は、ワンショット (推奨) またはローリング アップデート リリースを決定します。適切なリリース戦略を考えてください。(必要に応じて簡単にロールバックできるように、コードベースへの別の無関係な大きな変更の一部としてアップグレードをリリースしないことをお勧めします。)
  • アップグレード プロセス全体を通して、継続的にテストを実行します。手動でテストする場合は、ブラウザ コンソールで新しいエラーを常に監視してください。予期しないエラーをカバーする新しいテストを作成します。
  • すべてのテストに合格したら、どのようにロールアウトするかを決定します。それがサイトである場合、すべてのユーザーを一度に、または一度に一定の割合でなどです。ライブラリやその他のプロジェクトでは、ベータ版/ブリーディング エッジをリリースする可能性があります。より野心的なユーザーに実際にテストしてもらうことができるバージョンです。
  • 行ったことをすべて文書化して、次回の作業が簡単になるようにします。
  • [利益。]

アップグレードを通常のワークフローに統合する方法

  • 再び、テスト。それらがあることを確認してください。それらが適切で、維持され、コードベースとユースケースの大部分をカバーしていることを確認してください。これらのテストの実行を自動化するための継続的な統合セットアップを強くお勧めします。
  • チームにコーディング スタイル ガイドまたは標準を作成し、それに従うことに同意してもらうことを検討してください。これにより、今後、非推奨の関数呼び出しや構成を簡単に検索できるようになります。これは、誰もが同様のコーディング パターンに従うためです。スクリプト、コミット フック、静的解析ユーティリティなどのツールは、適切なコーディング スタイルを適用したり、不適切なコーディング スタイルを検出したりするのに役立ちます (チームによって異なります)。
  • 調査し、 NPMやbowerなどのパッケージ マネージャーを使用して、jQuery のバージョンとそれに依存する可能性のある他のサード パーティ ライブラリを管理することを決定します。(独自の JS コードを維持し、上記とほぼ同じプロセスを実行する必要があります。)
  • 繰り返しますが、バージョン 1.6.4 を過ぎたら、Migrate プラグインがアップグレード ワークフローの一部であることを確認してください。
  • 最初の大規模なアップグレード プロセスで何がうまくいったか、何がうまくいかなかったかを評価し、これから現在のワークフローで最もうまくいく一般的なプロセスを抽出します。新しいバージョンがリリースされるたびにアップグレードする予定があるかどうかに関係なく、一般的な開発のベスト プラクティスとして維持したい継続的なメンテナンス タスクと習慣があります。

合理的なアップグレード スケジュール

これは基本的に、CBA/リスク管理に関する質問です。いくつかのことを比較検討する必要があります:

  • 同じメジャー バージョン内に破壊的な API の変更があってはならないため、通常、リファクタリングを必要とせず、最小限の労力で最新のマイナー バージョンにアップグレードできるはずです。これは、すべてがロールアウトに十分であると判断する前に、プロジェクトで実行できる適切なテストがあり、維持されていることを前提としています。
  • メジャー バージョンのアップグレードには、より多くの調査、リファクタリング、およびテストが必要です。調査ステップの後、アップグレードの費用便益分析を行う必要があります。
  • これは大した問題ではないかもしれませんが、プロジェクトのいずれかが多数のユーザーを持つ Web サイトである場合、すべてのユーザーが次にサイトにアクセスしたときに、変更されたすべての JS ファイルを基本的にダウンロードしなければならなくなると、どのくらいのコストがかかりますか? (おそらくブラウザにまだキャッシュされている古いバージョンに固執する代わりに)?
  • アップグレードの決定は、常に主観的なものでなければなりません。マイナーであろうとメジャーであろうと、アップグレードする価値があるかどうかを毎回正当化する必要があります。常にリリース ノートをお読みください。あなたやあなたのユーザーが現在経験している問題に関連するセキュリティの脆弱性やバグを修正しますか? プロジェクトのパフォーマンスが大幅に向上しますか (後で検証するために必ずベンチマークを用意してください)。これまで使用していたコーディング パターンが大幅に簡素化され、コードをよりクリーンかつ簡単に記述できるようになりましたか? この新しいバージョンに依存する、使用したいサードパーティ ライブラリはありますか? 古いライブラリに依存している、既に使用しているサードパーティのライブラリはありますか?バージョン？(そうであれば、これらのライブラリは新しいバージョンで動作するようにすぐにアップグレードされる可能性がありますか?) テストと QA プロセスで、アップグレードに十分な量の開発リソースが必要であり、大きなリグレッションが発生しないという自信がありますか? 最終的に jQuery を別のものに切り替えることを考えていましたか? 等。

もちろん、これは私のアドバイスです。その中にはいくつかの繰り返しのテーマがあり、それらが明確であることを願っています. いずれにせよ、誰かがこれを役に立てば幸いです！

于 2013-03-19T18:15:27.407 に答える
12

あなたは常に時代遅れになります。最新バージョンへの更新が完了すると、数か月後に新しいバージョンがリリースされます。

開発、テスト、およびバグ修正に数時間/数日/数週間を費やし、ユーザー向けの機能が壊れる可能性がある場合を除き、イベント ハンドラーを宣言する最新の方法を使用するためだけに更新するべきではありません。それはあなたを傷つけません。そして通常、これは危険な行為です。これは、開発チームのコストにつながります。あなたはすでにこれを知っています。リファクタリングは、特にプロジェクトに明らかなリスクがない場合は、一般にマネージャにとって正当化するのが困難です。そして、すでに機能しているコードに新しい jQuery を組み込むことで違いが生じるかどうかを確認するために、自分の考えを再確認する必要があります。

現在、既存のサイトで新しいページの作成に取り組んでいる場合、それらの領域に新しいバージョンを含めることができます。しかし、これには結果があります。あなたとあなたのチームは、サイトの新しい部分を開発するだけでなく、古い部分を使用している部分も維持する必要があると仮定しましょう。誰もが、コードを書いている特定のバージョンの jQuery に注意する必要があります。

では、締めくくりに、こんなことを言いたいと思います。プロジェクトが遅れたり、jQuery のバージョンが古いために技術的にブロックされたりする正当なリスクがない限り、すでに機能しているものを壊すことで問題が発生し、すべてを作成するためだけに余分な時間を費やす必要があります。以前と同じように機能します。

とにかく、このアプローチは、「新しいセクション」を古いものから分離し、新しい領域で最新のライブラリを使用できるという意味ではありません。

于 2013-03-11T03:31:18.890 に答える
6

これは調べる価値があります: https://github.com/jquery/jquery-migrate/#readme

このプラグインは、jQuery で廃止され、バージョン 1.9 で削除された API または機能を検出して復元するために使用できます。プラグインが生成するメッセージの詳細については、警告ページを参照して ください。jQuery 1.9 で行われた変更の詳細については、アップグレード ガイドとブログ投稿を参照してください。

于 2013-03-11T03:16:26.770 に答える
1

Twitter の担当者は、この問題を非常にうまく解決しました。

http://github.com/twitter/bower

ブリキに書かれていることを実行します-これはWeb用のパッケージマネージャーです（JQueryなどのJSファイルを最新に保つことも含まれます）

于 2013-03-19T17:04:10.283 に答える
0

この時代では、ソフトウェアバージョンの安定性について予測することはできません。ソフトウェアとサービスのバージョンが1年か2年後にリリースされる数年前。しかし、現時点では、サービスのバージョンは急速かつ頻繁に更新されています。

したがって、サービスでサービスを使用している場合は、アジャイル開発を使用する必要があります。この開発方法により、新しい要件を簡単に変更したり、必要な方法を自分に合わせて変更したりできます。

また、長期のサービスバージョンには適していないため、減価償却方法は使用しないでください。また、他のサービスを利用している独自のサービス機能のライブラリの利用サービスのライブラリを作成し、新しいバージョンに合わせて簡単に変更できるようにします。

例：メソッド名があるように、。update_var();のような他のサービスの別のメソッドを呼び出してい$a = newlib::check_update();ます。次に、ライブラリを作成することにより、機能のメインライブラリと関連するサービスのコアライブラリを変更する必要があります。

于 2013-03-19T04:41:02.857 に答える
0

開発ツリーを最新の状態に保つために、使用することをお勧めしますsrc="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js"(デバッグを容易にする完全な非縮小バージョン)。

次に、公開するときに、ヘッダーコメントにある特定の縮小バージョンに置き換えるだけです（現在http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js）これより良いクライアント側のキャッシュを許可し、他の誰かの帯域幅を使用できるというボーナスがあります.

マイナー バージョン リリースのバグ修正を自動的に取得することよりもキャッシュが重要でない場合は、次のようにメジャー バージョンとマイナー バージョンのみを使用できます。 /jquery.min.js (注: Google にはまだ 1.9 シリーズがありませんが、1.8 シリーズは 1.8.3 までです) これらはバグ修正リリースのために定期的に更新されるため、バージョン固有のようにキャッシュされませんリリース

于 2013-03-19T04:07:48.050 に答える