2

私は約 3500 ファイルのコードベースを持つプロジェクトに取り組んでおり、実際にはそれより数百少ないと思われます。このプロジェクトは PHP で作成されており、非常に厄介です。この場合、ドキュメントが理解しにくく、OOP と手続き型プログラミングが混在し、依存関係が不明確であり、初心者プログラマーが必要とするすべてのシステムを作成した人を意味します。

正直なところ、彼らが成し遂げたことは印象的です。しかし、新機能のデバッグと追加は本当に面倒です。

ここで、プロジェクト全体をリファクタリングするか、完全に書き直すかの適切な基準は何かを質問します。すべてが相互に依存しているため、システムの一部を書き直すことはおそらく不可能です。

4

3 に答える 3

0

アプリケーションがすでに動作していて、大きな不具合がない場合は、すべてをゼロから書き直すには常にコストがかかるため、ほとんどのアプリケーションをそのままにしておきます。

おそらく、重複したコードがオブジェクト/関数を作成している場合は、ファイル/行の量を減らして、すべてを可能な限り集中化することを検討する必要があります。これは、最終的なメンテナンスに非常に役立ち、長い時間を必要としません。特に初心者が言うように書かれていれば、「間違ったアプローチ」を簡単に見つけて改善することができます。

于 2012-12-11T12:24:35.010 に答える
0

基本的な基準はおそらく時間(=お金)でしょう。
何かが大きい場合、見積もりは常に困難です。それを最小のチャンクに分割します。

視点に注意してください。あなたの好みのスタイルによってバイアスがかかるため、あなたの見積もりはおそらく以前のプログラマーの見積もりとは異なるでしょう。おそらく、以前のプログラマーを雇ってコードを「修正」する方がよいでしょう。

いずれにせよ、適切に記述され、維持しやすいアプリを呼び出すための最小要件を述べ、これについて上司やチームと話し合い、可能な限り最小のスプリントに分割し、それらすべてに必要な時間を見積もる必要があります。

書き直した方が ROI が全体的に向上することを上司に納得させることができた場合は、書き直してください。そうでなければ、「新しいスタイル」を学びましょう。書き換えの時間、またはそれを行うための空き時間のためにビジネスを停止する快適さがある場合は、幸運です. コードがテスト可能である場合、または少なくともいくつかの単体テストがある場合は、さらに幸運です。これが不可能な場合は、機能テストを実装して、少なくとも両方のケース (リファクタリングまたは書き直し) を支援する必要があります。

私たちの誰もがおそらく、リファクタリングよりもゼロから書き直すことを好むことに注意してください。次に、この書き直したものを書き直します...

したがって、すでにテストがあるか、テストを簡単に実装できると仮定すると、リファクタリングは常に良い選択です。

于 2012-12-11T15:09:04.990 に答える