ruby-on-rails - 大きなコードのリファクタリング: 新しいプロジェクトを作成するか、パッケージごとにパッケージをリファクタリングします

Question

私たちは Rails 2.3 プロジェクトに取り組んでいる小さなチームです。簡単な説明: このプロジェクトには現在

プロジェクトは約 15 個の「モジュール」(Rails モジュールではありません) に分割され、各モジュールは他のモジュールと通信します。このプロジェクトは数年前から存在しており、Rails の専門家ではなく、複数の人々によって改善および維持されてきました。

現在の主な問題は、コードのいくつかの部分が保守しにくく、最適化されておらず、十分な「思慮分別」がないことです (いたるところにハッキングがあります)。CSS ファイルはほとんど読めません。

私たちのチームは、このプロジェクトのリファクタリングについて考えています。いくつかの解決策があります：

新しいプロジェクトをゼロから作成し、機能を 1 つずつ含めます。このソリューションの利点は、プロジェクトのすべての側面があり、コード設計についてより適切な決定を下せることです。もう 1 つの利点は、Rails 3 に更新できることです。この方法の欠如は、新しい機能を含める必要があるときに、2 つのプロジェクトを並行して維持する必要があることです。
モジュールごとに既存のコードを更新します。このソリューションの利点は、維持するプロジェクトが 1 つだけであることです。しかし、いくつかの欠点があります...古いモジュールから新しいモジュールに移動するにはどうすればよいですか? 新しいクラス名と古いクラス名の間をどのように処理するのですか? 古いコードがどこで使用されていて、削除する必要があるかを知る方法は?...などなど。

このような大規模なリファクタリングをすでに行っている人はいますか?

これについてフィードバックを経験した人はいますか?

誰かが他の解決策を持っていますか?

読んでくれてありがとう！

score 3 · Accepted Answer

ここでの答えは、あなたがどれだけ自律性を持っているか、そしてリファクタリングにどれだけの時間を割けるかにかかっています。この規模のプロジェクトでは、ほぼ確実に、すべての作業を中断して 100% の時間を次の作業に費やすことはできません。掃除ROR 3 移行 (咳咳、移行!)。

私の仮定が正しければ、私のアドバイスは、2 番目の方法 (既存のコードを更新するなど) を使用して小さなチャンクでこれに取り組むことです。あなたが概説したことに加えて、他にもいくつかのことをお勧めします。

コードの一部をリファクタリングする前にテストを記述します。これは、問題を引き起こしていないことを確信するのに役立ちます (ヘルプを強調します...もちろん、いくつかの破損は可能です)。
可能であれば、モジュールを個別の独立した gem に分割することを検討してください。これにより、外部依存関係を追跡し、45 個の外部 gem がすべてどこで使用されているかを把握できます。また、テストの範囲を制限するのにも役立ちます。

率直に言って、2 番目の方法は、他のビジネスニーズに同時に対応しながらコードベースを改善できるため、開発者としての仕事にとってはるかに安全です。リファクタリングの一部が遅すぎる場合は、コードベースの残りの部分はそのままであるため、停止して別の場所で再開することもできます。

score 2 · Accepted Answer

リファクタリングは大変な作業であり、長い時間と多くの検討が必要です。

まったく新しいプロジェクトと比較すると、問題は、作業中のプロジェクトを維持する必要があり、おそらくいくつかのバグ修正や機能要求をサポートする必要があることです。

一方で、解決しようとしている問題についての理解が深まり、既存のソフトウェアを事実上の「機能仕様」として使用できるようになります。

各相互依存関係をリストすることにより、「モジュール」間のインターフェースを識別します。
必要に応じてこれらの「インターフェース」をクリーンアップします
各モジュールの入力と出力をテストする単体テストを記述してインターフェイスを形式化する
ドロップイン置換として完全に新しいモジュールを作成します。ゼロから設計し、ここで Ruby のアップグレードを行います。新しいモジュールが古いモジュールと同じテストに合格することを確認してください。
必要に応じて (暫定的な解決策として) さまざまな互換性のないセクションをラップして、それらを連携させます。これは遅いかもしれませんが、一時しのぎです。

幸運を。

2 に答える 2