レガシアプリケーションでコヒーレントアーキテクチャを開始する

私は、Asp.Netベースの大規模なWebサイトを担当しています。現在、これはWebアプリケーション（Webアプリケーションではない）、一部のWindowsサービス、および多数のクラスライブラリです。

データレイヤーは、LLBLGEN とLinq To LLBGenの混合、およびリファクタリングされていないレガシーインラインSQLのインスタンスを使用します。

マネージャータイプの実装がいくつかありますが、多くの場合、アプリケーションはスマートUIアンチパターンを示します（つまり、クラスの背後にあるコードのビジネスロジックが多すぎる）

サイトのトラフィックはかなり高く、パフォーマンスは良好ですが、開発能力を約10人のチームにまで拡大しており、既存のミドルウェアの上に包括的な階層化設計が必要であることがますます明らかになっています。

私の質問はどこから始めればいいですか？私たちには10年のコード（ASP Classicのものを移行したものもあります）、さまざまなアプローチ、スタイルがあります。

コードベース全体のリファクタリングは現実的ではなく、おそらく望ましくありません

私はこれが新しい状況ではないことを知っています、この問題にどのようにアプローチするかに関して有用なアイデアや概念はありますか？

私も同様の状況で仕事をしてきましたが、次のアドバイスをすることができます。

1. 技術的な負債を減らす必要があります。今。どうして？技術的な負債は金融負債のようなものだからです。あなたはそれに関心を払うでしょう。
2. コードベース全体をリファクタリングするのは現実的ではないので、自問してください：何が​​それを妨げているのでしょうか？仕事が多すぎますか？どうして？
3. 時間内に技術的負債を削減する計画を作成します。たとえば、ルールを「チームが触れるすべてのコードを新しい標準に修正/リファクタリングする必要がある」として設定します。通常：ユニットテストを作成し、コードを正しいレイヤーに移動する必要があります。これにより、途方もなく高価で低価値の「リファクタリング」プロジェクトに頼ることなく、多くのコードを修正できます。
4. がらくたを包みます。デカップリングは、リファクタリングと優れたアーキテクチャの鍵です。コードベースを何らかの方法でパーティション分割できる場合は、小さなビットをリファクタリングできます。
5. テクノロジーの負債をこれ以上増やさないでください。テクノロジーの負債をこれ以上増やさないでください。テクノロジーの負債をこれ以上増やさないでください。しない...

コードベース全体をリファクタリングすることは望ましくありません。リファクタリングは、その開発をよりスムーズにするために、新しい開発に先立って行うことです。コードベース内のすべてのコードを変更する予定がない場合、リファクタリングは時間の非効率的な使用を証明します。

Sklivvzの言うことに加えて、いくつかのアドバイス：

1. コードを頻繁に変更するセクションと頻繁に変更しないセクションに分けます。頻繁に変更されるセクションのみを新しいアーキテクチャに完全に組み込む必要があります。可能な限り少ない変更を使用して、変更頻度の低いコードを新しいアーキテクチャに統合します（または、それを回避できる場合は変更しません）。完全な書き換えの誘惑に抵抗してください。それはあなたがそれから得るより多くの費用がかかります。たとえいものであっても、既存のコードが機能することを評価してください。

2. リファクタリングの目標が何であるかを調べてください。コンテンツをサイトに簡単に取り込むことができますか？多くのバグがあり、ユーザーが知覚する品質を改善したいですか？代わりに、機能の開発時間を短縮したいですか？それとも、主に優れたUXが必要ですか？アーキテクチャは、設定した目標を達成するためにコードを簡単にリファクタリングできるようにする必要があります。リファクタリングの主な受益者はユーザー/顧客/ビジネスであることを忘れないでください。よりクリーンなコードはそれ自体が目標ではなく、目的を達成するための方法であり、目的はユーザーに関係しています。

3. できるだけ多くの参照アーキテクチャを見つけて、それらをコピーすることを恐れないでください。車輪を再発明しないでください。他の誰かがあなたのようなサイトに適したアーキテクチャを持っているなら、彼らから学びましょう。

4. 物事の人事管理について考えてください。私自身の移行プロジェクトで最も難しかったのは、人々に新しい方法を習得させ、それに固執させることでした。参照実装と、チームの全員（新旧両方）にアーキテクチャを教える方法が必要になります。変更に対する抵抗を減らすには、決定を下す前にチームの全員に意見を求めてください。新しいデザインが実際に開発者の個人的な観点から物事を改善することを確認してください、そして、彼らが彼らの深さから感じられるほど大きな飛躍ではありません。

古いコードベースに対処しようとしたときに私が見た最も重要なことは、あなたが狙っているものを変え続けないことです。つまり、目的のアーキテクチャを把握してから、その計画にこだわるのです！私の最後の立場にあった大きな問題の1つは、コードベースが時間とともにどのように見えるべきかについてのいくつかの異なるアイデアを持っていたことでした。新しいアイデアが試行されるたびに、コードの一部は変換され、一部は変換されず、他の誰かが「より良い」アイデアを持っていました。それは時間とともにますます一貫性がなくなり、最終的に廃棄されました。

レガシーソフトウェアのリエンジニアリングに関する本当に素晴らしい無料の本/ pdfがあります：http : //scg.unibe.ch/download/oorp/

タイトルにはオブジェクト指向と書かれていますが、ほとんどのアイデアはどのソフトウェアにも当てはまります。どこから始めればよいか、再構築中にシステムのさまざまな部分をどのように扱うか、そしてこれらのトピックの多くについて説明します。

一貫性のあるアーキテクチャがない場合は、管理者が問題を理解していないためです。コーディングするだけです。新しいコードを記述するときに、新しい優れたアーキテクチャを導入する必要があります。

本当に深刻なバグが発生し始めた場合にのみ再設計する必要があります。それを拡張する必要があり、拡張できない場合、または要件に一致しない場合のみです。

私は基本的に、あなたのマネージャーが実際に気にしている問題だけを気にかけているのであって、あなたの知識があれば気にする問題ではないと言っています。

再構築を経営陣に販売できる場合は、テストから始めてください。彼らがテストに投資したくない場合、あなたの努力はあなたを困らせるだけです。