維持する必要がある古いコードベースがあり、それが現在の標準に明らかに準拠していないとします。標準への準拠を確保しながら、コードベースの下位互換性を維持するための取り組みをどのように分散しますか? あなたにとって何が重要ですか？
2 に答える
4
私の職場では、コードを改善するという理由だけで物事をリファクタリングする時間はありません。顧客からのバグまたは機能要求がなければなりません。
そのルールを考慮して、私は次のことを行います。
私がリファクタリングするとき：
古いプロジェクトに変更を加える必要がある場合は、変更する部分をクリーンアップ、リファクタリング、または書き直します。
最初に変更を加えるには常にコードを理解する必要があるため、それが他の変更を加えるのに最適な時期です。
また、これは、変更と既存のコードに対して、欠落している単体テストを追加する良い機会です。
私は常に最初にリファクタリングを行ってから変更を加えるので、変更によって何も壊れていないという確信が持てるようになります。
優先事項:
最もリファクタリングが必要なコード部分には、多くの場合、最も多くのバグが含まれています。また、お客様が関心を持たない部分についてのバグ報告や機能要求もありません。したがって、この方法では優先順位付けが自動的に行われます。
悪い設計を回避する:
これについてはたくさんの本があると思いますが、私が最も役に立ったのは次のとおりです。
私はファサードを構築します:
- 既存の悪いコードを「隔離」する新しい優れたデザインのファサード。これは、新しいコードを作成する必要があり、時間の制約により変更できない既存の構造化されていないコードを再利用する必要がある場合に使用します。
- 新しい良いコードを隠す元の悪いデザインのファサード。既存のコードで使用される新しいコードを作成する必要がある場合は、これを使用します。
これらのファサードの主な目的は、良いコードと悪いコードを分けて、依存関係とカスケード効果を制限することです。
于 2009-02-20T07:58:12.230 に答える
1
モジュールを使用する必要があるため、モジュールを修正する時間を考慮に入れました。合理的な企業では、事前のリライト/リファクタリングは成功しませんが、ある程度クリーンアップせずに粗悪なコードベースを維持することは、ほぼ間違いなく悪夢になるでしょう。
于 2009-02-20T07:45:04.163 に答える