私が取り組んでいるプロジェクト（約80K LOC）があり、何も壊さないように注意している限り、リリース前にほぼ1か月の贅沢なリファクタリングと機能追加の時間があります。そうは言っても、保守性を向上させるために何ができるでしょうか。このプロジェクトでは単体テストが実施されておらず、これに単体テストを追加する予定はありませんが、それが共通のコンセンサスである場合は、検討します。
ソフトウェアの保守性と品質を向上させるために、私が探し、改訂またはリファクタリングを検討する必要がある重要なことは何ですか？
編集：ユニットテストが必要であることが明らかになりました。これは私が実際に行ったことではありません。ユニットテストを初めて使用する開発者にとって、（できればVS2008のユニットテストフレームワークを介して）優れたリソースは何ですか？
このプロジェクトには単体テストがありませんでした。これに単体テストを追加する予定はありませんが、共通のコンセンサスである場合は検討します.
率直に言って、保守性を向上させることが目標である場合、単体テストに代わるものはありません。
これがステップ 1 になります。問題は、単体テストを行わないと、リファクタリング プロセス中に何かが「壊れた」かどうかを知る方法がないことです。
単体テストは、リファクタリングに関する安全層を提供します。リファクタリングによって動作が変わらないことを確認する方法がない場合、快適なリファクタリング、特に大規模なリファクタリングを行うことは困難です。
マイナーなリファクタリング (理解を深めるための小さな名前の変更など) を行うことはできますが、大規模なリファクタリングや、長期的な保守性を向上させるための設計スタイルのリファクタリングは、自分自身を保護するのに役立つテストを設計および記述した後に行う必要があります。
考慮すべき重要な点は、コードをリファクタリングする理由です。その質問に答えれば、答えの半分はすでに得られています。
リファクタリングの非常に一般的な理由である、保守性を向上させたいとおっしゃいました。それを目標として、私が具体的に目標とするいくつかのことを以下に示します。
1) 重複するコードを削除します。とにかく、ほとんどのプログラマーはこれを回避しようとしますが、大規模なプロジェクト (特に大規模なチームを持つプロジェクト) では、いずれにしても蓄積する傾向があります。これは、リファクタリングの簡単なターゲットです。
2) シンプルさを目標にします。各関数/メソッド/クラスは明確に定義されていますか? それを見て、それが何をしているのか正確に理解できますか? そうでない場合は、リファクタリングの対象として適しています。良い例は、多くのことを行う (または多くの副作用を持つ) モジュールです。それらを論理的にグループ化された機能の小さなモジュールに分割することを検討してください。
3) 変数/クラス/関数名。それらは明確ですか？必ずしも長くする必要はありませんが、変数が何のためにあるのか、関数が何をするのかを正確にあなた(またはコードを保守している人) に明確に示す必要があります。不明な点がある場合は、名前を変更することを検討してください。
4) 呼び出されないコードはありますか? 後で使うと思うならやめたほうがいいかもしれません。そうでなければ、それはメンテナーにとってただのニシンです。それを取り除くことを検討する価値があります。
5) パフォーマンスの向上。アルゴリズムを完全に書き直す時間がある場合とない場合があります (最高のパフォーマンス向上)。ただし、これは簡単なことを確認する良い機会です。C++ の例として、クラスを const 参照または値渡しとして渡していますか? 前者は、それを回避できる場合 (95% の確率で) はるかに効率的です。
リファクタリング頑張ってください！
[編集] また、コードが正しいままであることを確認するために、リファクタリングの前に単体テストを作成することをお勧めします。
このサイトのCode Smellsに関するwiki 記事を見てみましょう。始めるのに最適な場所です。
堅実なテストで十分にカバーされたプロジェクトを用意する (両方の単体テスト、モック &c を使用して非常に高速に実行されるため、常に実行できるようになります。また、統合テストは、実際には実際のデータベースとやり取りすることはほとんどありません)。保守性への鍵: プロジェクトをあらゆる目的 (機能、バグの除去、パフォーマンス、移植など) で簡単に保守できるようにするためにできる最も重要なことの 1 つです。強力なテスト スイートを使用すると、後で試してみたい特定の変更の正確性に自信が持てます。さらに、十分にテストできるようにリファクタリングされたコード (高度なモジュール化、依存性注入など) も本質的により柔軟になり、メンテナンス可能。
このような状況での最善の進め方についての完全で非常に実用的なガイドとして、Feathers の「レガシー コードを効果的に使用する」(私が指している PDF と同じタイトルと著者による本の両方) を強くお勧めします。
将来変更される可能性のある場所を見つけて、より柔軟にします。