既存のWebアプリケーションをリファクタリングする方法は？

私は最近、多くのことを読んだり考えたりしており、Web開発戦略を再考する必要があるかもしれないという結論に達しました。私は多くのオンザフライプログラミングを行っており、2年間でPHP Webアプリケーションに取り組んできました。小さなツールとして始まったかもしれないものが、かなり大きなプロジェクトになりました。しかし、私と私の前任者からの大量のレガシーコードがあり、当時は意味があったかもしれないコードスニペットですが、今は、実際の形でのこのコードの有用性に疑問を投げかけています。さらに、ユニットテストやテスト駆動開発のようなものは、ごく最近まで私の範囲にはありませんでした。

では、Webアプリケーションのリファクタリングにはどのように取り組みますか？私が探すべきものは何で、その順番は？ブラウザゲームと機能するウェブアプリはどうですか？ではアプローチに違いはありますか？

あらゆる種類のレガシーコードにアプローチする方法とほぼ同じです。テスト可能な部分を見つけ、そのテストを記述してリファクタリングします。

すぐにテストできる部分が見つからない場合は、テストスイートのセーフティハーネスなしでテストできるようにする必要があります。

ブラウザーにレンダリングしないコード（「インフラストラクチャー」コード、モデル、データベースに関連するもの）は、開始するのに適した場所です。

編集：UIテスト：私がここでほとんど経験がないという警告で、私の友人はこれを行います：彼はHTML生成コードの一部を実行します。次に、彼は自分のコードをハッキングし、新しく生成されたコードを古いバージョンと比較します（diffを使用します。完全に自動化されていません）。HTMLの変更は、リファクタリングが機能しなくなったことを意味します。

これについては、Michael Feathersによる「レガシーコードを効果的に使用する」というすばらしい本があります。それに直面しよう、私たちは皆レガシーコードを持っています。

主なことは、作成している新しいコードをテストすることです。他のコードに触れなければならないので、それらをテストする機会も得られます。それは長く遅いプロセスですが、体系的にそれを進めれば、時間の経過とともに製品全体を本当に改善できます。

• はい-WebアプリケーションはWebサイトとは異なります

別々に扱います。ドキュメントのコレクションであるサイトの一部がある場合（匿名ユーザーとログインしたユーザーのどちらにとっても同じように見えます）、それを構成する最良の方法は、動的に異なるページを提供するWebアプリとは大きく異なります各ユーザーに。サイトのこれら2つの部分を2つのアプリ/コンポーネントに分割し、それぞれに異なる方法で取り組みます。

• バージョン管理の使用を開始する

コードがバージョン管理下になったら、「万一に備えて」以前に保持していた不要なコードをすべて実行して、自信を持って削除できます。バージョン管理なしでどのように生き残ったかはわかりません。

• 無限を減らす

4つの異なるURLがすべて同じリソースを指している場合、問題ははるかに大きくなります。無限の量のURLを処理することになります。できるだけ早く、URL正規化ポリシーを設定してください。これが完了すると、URLに意味的な意味を付け始めることができ、resource-to-urlから逆ルックアップを実行できるようになります。これにより、「ウェブインプリント」をサイトの「リソース」から分離できます。

「URLの正規化形式を教えてください」と自問する必要があります。これが固定されたら、次に、サイトの50,0000以上のURLを2,000に減らすことができます。これは、頭の中で理解し、管理するのがはるかに簡単です。

参照：http : //www.sugarrae.com/be-a-normalizer-a-c14n-exterminator/

• 「あなたが望むもの」ではなく、「何であるか」をモデル化することから始めます

最初からベストプラクティスを念頭に置いて設計されていないレガシーサイトを片付けている場合、「混乱」から「理想的なデザイン」にジャンプするのは魅力的です。私はあなたが少なくとも2つのステップでそれをする必要があると信じています：「混乱」->「よくモデル化されたレガシーコード」->「機能が追加された理想的な新しいコード」。機能の追加を停止します。汚物を固定するか、腐敗防止層の背後にカプセル化することに集中してください。そうして初めて、デザインをより良いものに変えることができます。

参照：http : //www.joelonsoftware.com/articles/fog0000000069.html

参照：http : //www.laputan.org/mud/

• テストすることをお勧めします。

テストスイート/フレームワークを作成し、テストの追加を開始します。しかし、いくつかのレガシーコードをテストすることは非常にトリッキーです。だから、あまりにもこだわらないでください。そこにフレームワークがあれば、少しずつテストを追加できます。

参照：http : //www.simpletest.org/en/web_tester_documentation.html

• あなたの信念に勇気を持っています

ソフトウェア開発のベストプラクティスに関する文献のほとんどは、デスクトップ中心/エンタープライズアプリ中心です。あなたのサイトが混乱している間、あなたはこれらの本を読み、それらから滲み出る知恵に畏敬の念を抱くことができます。ただし、このベストプラクティスのほとんどは、Web / SEOが重要になる前に蓄積されてきたことを忘れないでください。POEAやGofなどの古典的な本で言及されている以上に、現代のWebについてはたくさん知っています。自分から学ぶべきことはたくさんありますが、自分の経験や知識を完全に捨てないでください。

私は続けることができました。しかし、これらは、古いレガシーサイトをピカピカの新しいサイトにリファクタリングするときに私が選んだいくつかのことです。

何かを行う前に、プロジェクトをソース管理することをお勧めします。このようにして、変更をロールバックしたり、別のブランチで大きな変更を行ったり、マイルストーンにタグを付けたりできます。

次に、変更するコードのテストを記述します。すべてをテストするために、一度にすべてを実行する必要はありません。あなたがすぐに取り組むことを計画しているものだけです。理論によると、十分な時間が与えられれば、ほとんどのコードベースはテストでカバーされます。一部のリファクタリングは、テストなしで「安全」に実行できることに注意してください。これらは、前述のレガシーコードブックに記載されており、他の場所でも疑いの余地はありません。

コードのセクションのテストを実施したら、コードを変更します。テストに合格する限り、必要なことは何でもしてください。

従来のコードでも、追加や変更を行うとTDDを実行できます。まず、予想される変更についてテストを記述し、それらが失敗することを確認してから、変更を加えます。

ここでは、いくつかのツールが役立つ場合があります。NDependは、高度に結合されたコードやその他のにおいを指摘できます。NCoverはコードカバレッジレベルを追跡します。FxCopは、コンパイラーが行うことを超えて、本質的にコードの正当性チェッカーです。これらはすべて、実際のサイズのプロジェクト、特にレガシーの種類に便利なツールです。

結局、それは多段階のプロセスです。一度にすべてを実行しようとせず、一度に少しずつ実行してください。

私を怒らせるほど醜いのであれば、私が全部を削除して、代わりのドロップを書くのは醜いほどです。

多くの場合、これを行うには同じ時間かかります。それは、そこに座って、組織化されていない、文書化されていない混乱の周りをつま先で動かして、穏やかに愛撫する場合と同じです。