少し扱いにくいシステムで開発しています。これは99％文書化されておらず、ベストプラクティスに準拠しておらず、理解するのがかなり困難です（グローバル変数、50行にまたがる方法、評価の乱用など）。残念ながら、私はコードベースにかなり慣れていないので、機能を追加する必要があります。
そこには再利用できるコードがあると思いますが、締め切りに間に合わせる必要があり、救済に費やした時間が最後に急いでしまうのではないかと心配しています。長期的には何が良いですか？私の一部は可能な限り再利用したいと思っていますが、別の部分では、重複のリスクを冒して、新しい機能を最初から作成することに集中する必要があると述べています（既存のコードでより多くの時間を費やすときにリファクタリングする計画があります） ？私は後者に傾いていますが、いくつかの意見を聞きたかったのです。
ありがとう！
http://www.joelonsoftware.com/articles/fog0000000069.html
http://discuss.joelonsoftware.com/default.asp?design.4.469415.13
http://www.joelonsoftware.com/articles/fog0000000007.html
http://www.paulgraham.com/hp.html
そうは言っても、クリーンアップする小さなセクションがある場合は、通常は問題ありません。しばらく作業を進めれば、戦略的でローカライズされた書き換えが最も効果的で危険性が最も低い場所をよりよく理解できるようになります。
本番コードベースでは、新しいものを公開するよりも、クライアントの現状を維持することが重要であることを忘れないでください。上司があなたに怒鳴るのを止めることはできません。ただし、バグが原因で代替製品に切り替えた回数と、他の方法で機能する製品では必要な拡張機能が十分に高速でなかったために切り替えた回数を自問してください。
私はあなたの本能に行きます：あなたが知っている方法でそれを書いてください。TDD、それがあなたのアプローチなら。とにかく、あなたの新しいものが適度に十分にテストカバーされていることを確認するようにしてください（そしてもちろん、現在そこにあるものよりも混乱が少ないです）。
将来的には、リファクタリングを行ったり、重複した機能を見つけたり、保持するメソッドとクラスを選択したりする機会が実際に得られる可能性があります。そのような場合、あなたはあなた自身が飼育係であることに気付くでしょう。
そしてもちろん、「道のり」が決して来ない可能性は十分にあります。少なくとも、新しいものは機能し、読みやすく、再利用可能です。これは、（説明したように）既存のコードベースの関数を追跡して再利用するよりも良い状況です。
レガシーコードを効果的に使用するを読むことで、経験していることすべてを克服できます。締め切りが迫っているとおっしゃっていましたが、急いでコアコードベースを完全に理解していないと、いくつかの悪影響が生じる可能性があります。
また、時間の許す限りリファクタリングを計画しているとのことです。私は何度もそう言ってきましたが、ほとんどの場合、その時は決して来ないことをお伝えしておきます。初めて正しく実行し、次の開発者のために、または後で新しい機能を追加するときに、自分自身を支持してください。
私たちは私のビジネスでこれと同じボートに乗っています。フェーズ1はうまくいった方向に進みましたが、理想的ではありませんでした。フェーズ2は、ビジネスモデルとロジックを変更しました.....このフェーズはオフショアでしたが、会社が構築することを選択したフレームワークを実際に理解していれば、それ自体は問題にはなりませんでした。したがって、ここでは、このような不十分に記述されたコードベースで作業する必要があることを嘆きながら、フェーズ3を終了しようとしています（フェーズ2の混乱を元に戻し、意図したとおりにフレームワークを適切に使用します）。重大な課題がありました。2つのjavascriptフレームワーク、不格好なレガシーUI、ジャンクコード、およびフレームワークのメジャーアップデートを使用して、現在のバージョンを廃止し、新しいバージョンに移行することをほぼ不可能にしました。
これが私たちが選択したことです....それはあなたの状況にとって理想的ではないかもしれません。まず、製品開発担当副社長は2週間かかり、データベース構造を完全に再検討しました。彼は、適切で効率的なDB構造に対応するために、必要に応じて既存のコードを変更するようにプログラミングスタッフを再利用しました。その（苦痛な）ステップが完了したら、2週間の休憩を取って、新機能を進歩させました。次に、UIを完全にリファクタリングするという職務を中断し、1つのJavascriptフレームワークの使用を取り消して、1つの共通プラットフォーム（コンセプト、ヒント、ひどいオフショア会社...）を使用できるようにしました。最新の効率的な最新のUI要素の効果的な使用。製品のベータ版が終了するまで、80％〜20％のタスクを組み合わせ、最終的な要件を80％達成し、コードを20％リファクタリングし、レガシーの混乱をクリーンアップします。各従業員には、「クリーンアップ」またはより効率的な作業を担当する領域が与えられています。プロセスの文書化も委任されたタスクであり、各従業員の1週間の労働時間に必要な割合です。
私たちのプロセスを成功させる秘訣は、フェーズ3が完了する前でもフェーズ4に目を向けることだと思います。新しいコードは最大の効率と互換性で構築されているため、この古いプラットフォームから移行する場合は、最小限の変更で済みます。私は（コードだけでなく）プロセスを区分化する方法を実験しているので、理論的には、適切なタイミングでプロセスを個別に新しいフレームワークに移動できます。私たちの将来の計画は紙に書かれており、要件リストが進化し、最良のツールを見つけるための研究が進行中です。最も重要なことは、チームリーダーは物事を正しく効率的に行うための執着者であるため、正しく行われなかった現在または将来のことは何も進みません。
前進するために後退する必要があることを経営陣に正当化するのは難しいです。あなたの会社の将来全体が、私たちがそうであったようにベータ版で立ち往生している製品に依存している場合、それはさらに困難です。私はそれを燃料効率の良い機器にもっとお金をかけることと比較します....それは今より多くの費用がかかるでしょう、しかし最終的にそれは莫大な経済的見返りを得るでしょう。この状況で成功する秘訣は、製品を素晴らしいものにするために時間を費やしている間、スタンドアロンで「十分に良い」製品の中央値を見つけることだと思います。その中央値を満たすための戦略を開発することは、ビジネスユニットに忍耐強く挑戦し、最終的には成功したときにあなたをヒーローにします。強力な計画を立て、その計画を伝え、他の人とうまく遊んで、あなたの尻尾を切り落とします。すぐに、あなたは
追加するこの小さな機能について心配する必要はありません。素早く汚いことをしてください。
チームがソースコードのリファクタリングを計画している場合は、管理者のサポートがあることを確認してください。現在直面している問題について経営陣に知らせてください。現在のコードベースはベストプラクティスに従っていません。アプリケーションが構造化されていないほど、機能の追加に時間がかかります。新しい機能の構築にはほとんどの時間がかかりませんが、すべての状況で期待どおりに動作することを確認し、何かがfoobarになったときに問題を修正することも貴重な時間を要します。
アプリケーションをリファクタリングする場合は、アプリケーションの一部をより適切に実装するために、すぐに利用できるソリューションを選択した場合のメリットについて考えてください。
私はしばらく続けることができました。アプリケーションの完全な再構築が2ステップ戻ることもありますが、4または5ステップ進むこともあります。