私は最近、大きなコードベースを継承し、それを読まなければなりません。問題は、私は通常、プロジェクトを開始する開発者でした。その結果、私はコードを読んだ経験があまりありません。
たくさんのコードを読まなければならないことに対する私の反応は、まあ、それを書き直すことです。しかし、私は自分自身を迅速にスピードアップし、既存のシステムの上に構築する必要があります。
他の人は、コードベースを吸収するために学んだテクニックを持っていますか？この時点で、私はコードを読んでいます。UModelを使用してUML図を生成してみました。それらは非常に大きいのできれいに印刷されません。ズームインすると、すべての関係を見ることができなくなります。
他の人はこの問題にどのように対処しましたか？
うわー-私は文字通りコードを読んでポッドキャストを聴き終えたところです!!!
これを聞くことをお勧めします。私が過激で、あなたが試すことができる何かであるかもしれないということでなされた1つの興味深い点（私は私が行くことを知っています！）。ソースコードベース全体をダウンロードします。コードの編集とリファクタリングを開始してから...そのバージョンを破棄してください!!! 締め切りに伴うすべての要求を踏まえると、これを行うことはほとんどの開発者には起こらないだろうと思います。
私は自分の仕事であなたと同じような立場にあり、次のことが私のために働いていることがわかりました。-既存のコードにテストケースを書く。テストケースを作成できるようにするには、cdeベースを理解できる必要があります。-利用可能な場合は、製品のライフサイクルを通じて文書化されたバグ/問題を調べ、それらがどのように解決されたかを確認します。-コードの一部をリファクタリングしてみてください-おそらくそれを壊すでしょうが、それはそれを捨ててやり直すことができます。コードをより小さな問題に分解することで、より良い理解が得られます
ただし、リファクタリング時に大幅な変更を加える必要はありません。コードを読んで何かを理解したら、変数またはメソッド名の名前を変更して、解決しようとしている問題をより適切に反映できるようにします。
ああ、できれば、MichaelC.Feathersによる「WorkingEffectivelywithLegacyCode」のコピーを入手してください。あなたの状況では非常に貴重だと思います。
幸運を！
別のポッドキャストとリソースをお勧めします： ソフトウェア考古学に関するSE-Radionエピソード
一般的に、私はコードのエントリポイント（メイン関数、プラグインフックなど）から始めて、基本的な実行フローを実行します。それがまともなコードベースである場合、それはまともなサイズのチャンクに分割されるべきであり、それからあなたはコードの各チャンクが何に責任があるかを調べて理解することができます。システムの実行フローでいつ呼び出されたかを振り返ります。
パッケージ/モジュール/クラスの探索には、ソース上で実行された後に生成されるdoxygenを使用します。いくつかの優れたクラス関係図、継承階層、およびファイル依存関係グラフを生成します。これらの利点は、それぞれが単一のクラスに焦点を合わせており、それが隣人、兄弟、親とどのように結びついているかに焦点を当てているため、グラフは通常、扱いやすいサイズで理解しやすいものです。
クラス、関数、サブシステムの違いを理解しているので、明らかに不足しているドキュメントのように聞こえるものを埋めるためにコメントを追加したいと思います。これは、コードを2回読み直すときに役立ちます。
この記事はガイドラインを提供します
視覚化：アプリケーションのデザインを視覚的に表現したもの。
設計違反：オブジェクトモデルの状態の理解。
スタイル違反：コードが現在ある状態の理解。
ビジネスロジックレビュー：既存のソースをテストする機能。
パフォーマンスレビュー：ソースコードのボトルネックはどこにありますか？
ドキュメント：コードには、人々が何に取り組んでいるのかを理解するための適切なドキュメントがありますか？