巨大なコード ベース (18000 以上の Java クラス) の特定の部分をリファクタリングします。目標は、下位層を独立したライブラリとして抽出し、現在このコード ベースの複製を使用している他のプロジェクトで再利用できるようにすることです。特に 1 つの部分は、ビジネス ロジックから独立したフレームワークにリファクタリングすることに関心があります。最終的には、コードにクリーンなアーキテクチャ レイヤーを持たせたいと考えています。
Structure 101 for Java というツールを使用してコードを調べたところ、下位層が上位層を参照しているアーキテクチャ上の階層化の問題が多数 (!) 見つかりました。
単にコードをいじり始めるのではなく、この問題に対処するための合理的な戦略を考え出そうとします。どのような点に留意する必要がありますか?
せめて小さな一歩を踏み出そうと考えています。単体テストを用意することも考えていますが、何もないので作成する必要があります。
これについて何か考えはありますか？
また、Michael Feathers による Working with legacy code もご覧ください。
これを容易にするために導入できる最も重要なことの 1 つは、リファクタリングまたは個別のモジュールへのプルアウト後もすべてが機能することを確認するためのテストだと思います。これに加えて、何かをチェックインしたときにテストを実行する継続的インテグレーション システムを導入します。
18,000 のクラスは、本当に「膨大な」終焉に向かっています。これにより、ビルド/コンパイル時間や、IDE を起動したときにコンピューターから煙が出るなど、明確な問題が発生します。
私の最初の仮定は、これだけ多くのクラスがあるため、共通の機能の重複が多く、未使用のクラスやサブシステムさえある可能性があるということです。何かが大きくなると、開発者がシステム全体を知らないか、それらの Util 関数がどこにあるかを知らない可能性がますます高くなり、新しいものを書く方が簡単だと思うので、私はこれを期待しています. 削除する冗長性を探すと、簡素化に役立ちます。
冗長性のもう1つの考えられる原因は、無駄に深いクラス階層、または無意味なインターフェースの山です（例-私が働いている場所には、約50クラスのディレクトリがあり、ほとんどが1000行を超えています（私のものではなく、私のものではありません！）これらの実装のそれぞれ独自のメソッド スケルトンにすぎないインターフェイス. これらのインターフェイスの他の実装はありません. 50 個すべてを問題なく削除できます)。また、OO を発見したばかりで、OO に熱心に取り組んでいる開発者もいます。ご存知のとおり、5 つの抽象クラスと 3 つのインターフェイスのチェーンを拡張する単一の具体的な実装です。
それに伴い、コードのサブセクション (最大でも数百クラス) をサブプロジェクトに移動し、それをメイン プロジェクトに jar としてリンクします。その後、全体を理解できるという合理的な希望を持って、少し安心してそれに取り組むことができます-これには心理的な側面もあります-自分が働いていると感じている場合、良い仕事をするインセンティブは少なくなります.完全に理解している独自のクリーンなサブプロジェクトに取り組んでいる場合よりも、巨大で理解できない混乱のあるものに取り組んでいます。
まず第一に、幸運を祈ります。あなたはそれを必要とするでしょう。これは潜在的にあなたが遭遇した巨大な仕事です。それは私にはとてもなじみ深いように聞こえます。私は過去に同様のことに取り組んできました。
考えるべきことが1つあります。リファクタリングを開始する前に、広範なテストフレームワークを導入することを強く検討したいと思います。その理由は次のとおりです。優れた単体テストと回帰テストを使用すると、既存の機能を壊すことについてあまり心配することなく、変更を加えることができます。（とはいえ、常に懸念がありますが...）
つまり、機能の個別の「垂直」スライスを切り取って、それらの個別のユニットテストと統合テストを作成できるかどうかを確認します。それが終わったら、私は飛び込んでリファクタリングの作業を開始します。最初は非常に小さいかもしれませんが、機能の垂直スライスを分離してから、統合と単体テストコードを作成するプロセスだけで、既存のコードベースで多くの経験を積むことができます。そして、あなたが最初にそれを少し良くすることに成功したなら、あなたはそれだけ進んでいます。
それが終わったら、リファクタリングする機能の潜在的に大きなブロックを調べ始めます。リファクタリングする機能のクリーンなブロックを取得できない場合は、小さなチャンクを調べ始めます。抽出、単体テスト、リファクタリングを行うための小さな（場合によっては非常に小さな）コードのチャンクを見つけることができれば、前進しています。これは時々非常に非常に遅い進行のように見えるかもしれません、そしてあなたが本当に大きなプロジェクトを持っているなら、それはそうなるでしょう、しかしあなたはへこみを作るでしょう。
ただし、一般的には、最初にテストを実施して、期待される機能を確認することを検討してください。これらのテストが実施されると、物事を壊していないという自信を持って（完全な自信ではありませんが、何もないよりはましです）リファクタリングできます。小さなことから始めて、既存のコードベースから自分自身を明らかにする技術に基づいて構築します。長いスローグですが、最終的にはそこに到達し、コードベースの方が適しています。
私の頭の中で：
次に、これらのアプリケーション間の依存関係を特定します。下部にあるアプリケーション（他のすべてのアプリケーションで使用されている）は、通常、技術的なフレームワークまたはライブラリです。
重要なランタイムプロセスとその出力を特定するために、シナリオテストを作成します（単体テストではなく、この段階では「ローカライズ」されすぎています）。シナリオテストは統合に重点を置いており、非回帰テストにも使用できます。
現在の本番環境を準備し、現在のバグを認定します。これは、リファクタリングを開始するときに並列実行が必要であり（同じ機能が引き続き機能していることを確認するため）、並列実行に100％の互換性を持たせたくないためです（これは、バグを正常に再現したことを意味します！）
さまざまな（そして潜在的には並列の）リファクタリング作業を表すさまざまなブランチを管理するために、適切なマージワークフローを作成してください。
クラスのグループを抽出して独立したライブラリに変換する場合は、グループのメンバーを決定し、それらをまとまりのある全体に変換して、外界との相互作用を制限します。依存関係を可能な限り減らします。完了したら、そのグループを引き出してライブラリに変換し、ライブラリを接続し直して、新しいグループを開始します。がらくたをきれいにすればするほど、残っているものを理解しやすくなります。
依存関係ツリーをできるだけフラットにするようにしてください。
これを行う良い方法の 1 つは、反転した依存関係を使用することです。他のコードはインターフェイス/サービスに依存できますが、そのサービスのプロバイダーには依存できません。これは私たちを大いに助けてくれました。
ほんの少しの考え：
私の考えでは、テスト インフラストラクチャをセットアップした後、テスト コードの共通機能から抽象化を行うことができれば、テスト ケース用のコード生成ツールを作成できます。静的コード分析ツールは、視覚化ツール以外のアドオンになる可能性があります。すみません、それはアイデアです。ツールの名前すら言えません。
私は、取り組んでいるコード ベースと同様の立場にあります。Swing UI とビジネス ロジックの間の非常に緊密な統合。リファクタリングは繊細で時間のかかるプロジェクトです。
Martin Fowler のRefactoringを強くお勧めします。これは、私が発見した最も重要なツールの 1 つであり、これは、くだらないコード ベースでの作業に対する私のアプローチを改善するのに役立ちました。彼は、コードをリファクタリングするための論理的で簡単なプロセスを概説しています。これを何度も行った人から読むと役立ちます。