プロジェクトで使用するオープンソースフレームワークの変化にどのように対処しますか？

それは私の個人的な癖かもしれませんが、私は生きているプロジェクトのコードを最新の状態に保つことが好きです-彼らが使用するライブラリー/フレームワークを含みます。その一部は、完全にパッチが適用され、最新の状態になっている場合、Webアプリの方がより安全であると考えていることです。その一部は、私の部分的な強迫性のほんの一部です。

過去7か月間で、ソフトウェアの大幅な書き換えを行いました。遅くて本質的に製品として死んでいたXarayaフレームワークを削除し、Cake PHPに変換しました。（私たちがCakeを選んだ理由は、ソフトウェアを非常に迅速に書き直す機会があり、Xarayaを十分にパフォーマンスを向上させてしばらくの間価値があるためです。）

SimpleTestを使用して単体テストを実装し、すべてのファイルおよびデータベースの命名規則などに従いました。

Cakeは2.0に更新されています。そして、アップグレードのための実行可能な移行パスがないようです。ファイルの命名規則は根本的に変更され、PHPUnitに代わってSimpleTestが廃止されました。

なんらかの変換ツールがない限り、Cakeを更新してレガシーコードを徐々に改善して新しいCakeフレームワークのメリットを享受することは不可能であるため、これはほぼ1.3ブランチに留まることを強制します。 。そのため、いつものように、Subversionリポジトリに古いフレームワークが作成され、必要に応じてパッチを適用します。

そして、これが毎回私を魅了するものです。そのため、多くのオープンソース製品は、それらに基づくプロジェクトを最新の状態に保つのに十分なほど簡単ではありません。開発者が新しい光沢のあるおもちゃで遊び始めると、いくつかの重要なパッチが古いブランチに適用されますが、彼らの焦点のほとんどは新しいコードベースに置かれます。

使用しているオープンソースプロジェクトの急激な変化にどのように対処しますか？また、オープンソース製品を開発している場合、新しいバージョンを開発する際にアップグレードパスを念頭に置いていますか？

この問題はオープンソースに固有のものではありません。商業プロジェクトでも同じ問題が発生します。たぶんそれ以上かもしれませんが、ソースがないので、会社がサポートをやめても自分で維持できます。

エンドユーザータイプのオープンソースプロジェクトは、アップグレードサイクルが速く、古いバージョンはサポートをすぐに失います。一方、ユーザーがコーディングに多大な労力を費やすように設計されたプロジェクトは、メジャーアップグレード後に古いブランチのサポートサイクルが長くなる傾向があります。最初にコードが安定して成熟するのを待ってから、独自のコードを移行して徹底的にテストするのに十分な時間。

最新かつ最高のものを求める誘惑に抵抗するのは難しいかもしれませんが、ソフトウェアには安定性と新機能の間に根本的なトレードオフがあることを認識してください。あなたは他を犠牲にすることなしに一つを持つことはできません。これがバグ修正ブランチが存在する理由であり、スペクトルのどの側がニーズに最も合うかを選択できます。

この問題は、コードをモジュール化することで対処しました。

私たちの主要なWebサイトは約8年前に作成されましたが、幸運にも、Spring Frameworkの初期の貢献者の1人が作成できたので、非常によく構築された基盤でした。しかし、残念なことに、この開発者が方向性についての議論の後、Springをフォークすることを決めたので、このコードベースは、Spring 1.1.4（またはそのヴィンテージの何か）のメンテナンスされていないフォークにスタックしています。

Springの新しいバージョンに移行するようにコードを書き直そうとしましたが、それは非常に困難であることがわかりました。したがって、私たちのソリューションは、Spring 3.x、Hibernate 3.6などの最新のフレームワークを使用して、完全に別のアプリケーションのモジュールとしてサイトの新機能の構築を開始することでした。

これで、2つのWebアプリケーションが同じベースURLで実行され、Apacheのmod_proxyモジュールを使用して、各パスを適切なアプリケーションに割り当てます。たとえば、「/ members」は古いアプリケーションに移動し、「/ directories」は新しいアプリケーションに移動します。ただし、サイトの訪問者は、別のアプリケーションを使用していることを理解できません。ユーザーにはまったく同じに見えます。

2つのアプリケーションは通信する必要があります。たとえば、メンバーが（新しいアプリケーションを使用して）サイトにログインするときに、古いアプリケーションにそれらが現在ログインしていることを通知する必要があります。これは、 localhost。2つのアプリ間で必要な統合の量は最小限であることが判明しました。

この作業を行う上で重要なことは、共有アセットを識別してパッケージ化することでした。したがって、すべての静的テキスト、グラフィック、スタイルシート、Javascript、およびテンプレートは、元のアプリケーションから、新しいアプリケーションと古いアプリケーションの両方が使用する別の（3番目の）プロジェクトに移動されました。これにより、両方のWebアプリケーションが完全に独立していても、外観と動作が同じになることが保証されます。

最終的に完全に不要になるまで、元のアプリケーションをどんどん置き換えていくと思います。この手法の良い点は、一連の小さな低リスクの変更によってゆっくりと実行できることです。新しいシステムへの大規模でリスクのある突然の切り替えの必要はありません。

私はいつもそれをするわけではありません。多くのオープンソースプロジェクトでは、以前のメジャーリリース用にアクティブなメンテナンスブランチが維持されています。時々それらはそのバージョンを維持する必要がある人々によって維持されます。多くのプロジェクトは、メジャーリリースの準備ができるまでメジャーリリースのままです。

そして、これが毎回私を魅了するものです。

毎回？あなたは著しく悪い選択をしているに違いありません。それが起こらなかった一つの例があるに違いない。

開発者が新しい光沢のあるおもちゃで遊んだとき

それはヒントです。オープンソースプロジェクトを使用するときは、光沢のある新しいおもちゃを避けてください。リリース1.0は避けてください。

使用しているオープンソースプロジェクトの急激な変化にどのように対処しますか？

ステップ1.非常に慎重にオープンソースプロジェクトを選択します。常に2つ以上の競合するプロジェクトを比較します。

ステップ2. 2つの競合するプロジェクトを比較するときは、提供されている「必須の」機能と、それらが両方ともどのようにそれに取り組むかを理解するようにしてください。特定のAPIを早めに「やり取り」しないでください。

ステップ3.「遅延バインディング」と「ルーズカップリング」の設計原則を採用します。オープンソースプロジェクトの変更から隔離するようにしてください。

ステップ4.オープンソースプロジェクトと「独自のローリング」との間でコストとメリットの比較を明示的に行う。たまに、独自のソリューションを作成する方が、オープンソースソリューションに対処するよりも優れている場合があります。

ファイル名の変更はそれほど難しくありません。はい、それは大きくて醜いスクリプトです。はい、変換中に数週間実行する必要があります。しかし、それは有限のコストです。

毎回発生する場合は、より適切な対処方法を開発してください。現実の世界についてのあなたの観察はそれが常に起こりそうであるということなので、現実の世界が変化することを望んでも実際にはあまり役に立たないでしょう。あなたは変化でいくつかのハードウォンの経験を持っています。それを活用してください。それを感染症のように考えて、あなた自身の免疫反応を発達させてください。