私は現在、ロジックとデータ アクセスの両方が GUI クラスに存在するコードで作業しています。もちろん、私はこの状況を改善したいと思っています。
現在の構造は基本的に次のとおりです。
最終的な目標は、DDD のような構造を実現することです。
では、どのように問題に取り組みますか?
「ビッグバン」は絶対にやらないでください。他のすべてが失敗したとき、それはリスクが高く、必死の手段であるため、ほとんどの場合、それはあなたの顔に吹き付けられます。
分割統治法：これはうまく機能します...あなたの世界に2つの側面しかない場合。実際のソフトウェアでは、同時に非常に多くの面を征服する必要があり、白黒のファンタジーに住む余裕はめったにありません。
私は私のキャリアのほとんどで「Strangling」のようなものを使用していると思います。古いコードを徐々に光沢のある新しいコードにモーフィングします。これが私のレシピです：
どこかから始めましょう。どこでも構いません。コードが実際にどのように動作するかを確認するために、いくつかの単体テストを記述します。自分が思っていることを実行する頻度と実行しない頻度を調べます。IDEを使用してコードをリファクタリングし、テストできるようにします。
初日の後、このモンスターを分解するのに適切な場所から始めたかどうかを推測します。もしそうなら、続けてください。そうでない場合は、新しい場所を見つけて最初からやり直してください。
この戦略の利点：小さなステップで機能するため、リスクを抑制し、何かが壊れた場合、先週作業していたコードに含まれている必要がある場合に使用できます。
短所：「結び目」がはじけるまで進行が非常に遅いように見え、突然、すべてが魔法のように所定の位置に収まり始めるため、非常に時間がかかり、イライラするでしょう。
「Strangler Application」という言葉は聞いたことがありませんでした。気に入っています。可能であれば、これは常に優れたアプローチであり、リスクを最小限に抑え、非常に実用的であり、大きな建物を少しずつ削っていきます.
私の経験ではそれがうまくいかないのは、合理的に重要な変更がすぐに必要な場合です。変更には少しのリファクタリング (または多くのハッキング) が必要です。そのような状況では、必要な変更が大きな泥の塊の中心にあり、汚れる以外に選択肢がないことに気付くことがよくありました。主要なリファクタリングが最良の選択肢でした。
そのような場合、私は分割統治法を採用します。私が常に目指している最初の目標は、テスト容易性です。それができれば、残りのすべてがはるかに簡単になります。実際、これは私が大きな泥の塊から離れてリファクタリングする主な要因の 1 つです。この種のコードはほとんどテスト不可能であることが多く、UI の入力と出力の例があることを願っていますが、それさえないこともあります。 .
そのため、すべてが UI にまとめられているコードに直面した場合、私は通常、個別の機能単位をクラスとメソッドに分解してから、コードのそれらの部分をドメインまたはサービス レイヤーにプッシュすることから始めます。少しずつ行うことで、何かが壊れる可能性が大幅に減少し、問題が発生したときに壊れたコードがどこにあったかを特定しやすくなります。
すべての変更の最後に利用可能なテスト ケースを実行し、何らかのベースラインを満たしていることを確認します。
適切な単体テストを書いていれば、問題の規模を縮小することができます。適切な単体テストを使用するか、少なくともまともなコードを作成できる適切なフレームワークを使用して、ストラングラー アプローチを採用することがすぐに実用的になることがわかりました。単体テストでは、機能の一部を徐々に置き換えることがはるかに実用的になります。
この種の問題を攻撃するのに有望と思われる「ミカドメソッド」に出くわしました。
http://mikadomethod.wordpress.com/
Øredev2010のMikadoメソッドについての話もあります。
http://oredev.org/2010/sessions/large-scale-refactorings-using-the-mikado-method
ビッグバン / 大きな再設計 / SW の書き直し ... またはその他の名前は、生きている SW では機能しません。理由は次のとおりです。
既存の SW を (おそらく) 同じリソースでサポートする必要があります。
おそらく、書き換える必要はありません。古いコードには、すべての要件が埋め込まれています。すべてのソフトウェア ドメインとすべての要件を知っているエンジニアはいません。
書き換えには時間がかかります。この期間の終わりには、既存の SW が、この期間に必要だったものをサポートするように変更されていることがわかります。新しい SW は実際にはオリジナルから分割され、マージが必要になります (これにも時間がかかります)。
私にとって、それは状況に依存します。
非常に小さなプロジェクトの場合は、最初から書き直したくなるでしょう...しかし、それほど贅沢なことはあまりありません。
それが失敗した場合、私はそれを少しずつ削り取りに行きます。単体テストを作成して既存の機能を検証し、TDDをゆっくりと使用してコードをエレガントで適切に設計されたシステムに変換します。このプロセスにかかる時間にもよりますが、おそらく上記のStranglerApplicationのように見え始めます。
更新されたシステムが古いシステムと同じことを行うことを確認する簡単な方法がないため、BigBangは非常に危険です。
分割統治法はBigBangよりもリスクが少ないです...しかし、そのシステムが十分に大きい場合、BigBangと同じくらい問題になる可能性があります。
必要に応じていつでもバグを修正して展開できるように、常に動作状態を維持する必要があるかどうかによって異なります。その場合、Devide and Conquer が適切なソリューションになります。新しいコードに取り組んでいる間に古いコードを維持できる場合 (そして、両方のコードベースにバグ修正を適用するための規律がある場合) は、書き直す方が良い解決策になる可能性があります。
リファクタリングによって、機能を変更せずにコードを改善することを意味する場合、自動回帰テストのベースラインを作成することから始めます。これを支援するツールはたくさんあります。私はTestComleteを使用していますが、安価な代替品があります。
リグレッション テストのベースラインを確立したら、個人的には分割統治法を採用します。これは、私の経験では成功する可能性が最も高いためです。テストのベースラインができたら、どのアプローチを選択するかはそれほど重要ではありません。
全面的な書き換えはオプションですか? 私の経験では、多くの場合、既存の混乱を一掃するよりも、ゼロから書き直す方が効率的です。既存のコードの一部を引き続きコールドに保持しますが、新しいコンテキストで行います。また、GUI とデータベースがある場合は、それらについても同じことが言えます。ゼロから書き直して、使えるものを持っていきましょう。
クリーンな新しいアーキテクチャから始めて、コードの古い部分をこの新しいアーキテクチャに少しずつ移動し、新しいアーチに合うようにリファクタリングするのは良いオプションです。関数を移動するときのボトムアップアプローチが良いと思います。