回答:
コードから始めます。個別の設計文書がある場合、それは間違っていないか誤解されている可能性があります。そのため、コードの単純なフローをトレースすることから始めます。webappの場合、たとえば、リクエストまたはリクエストのシーケンスです。それができたら、もっと理解を深めるための一種のスケルトンができました。その後、戻ってデザインや他のドキュメントを読むかもしれませんが、その時点で、それらを関連付けて検証する具体的なものがあり、ダフ情報を検出できます。または、コードの読み取りやテストケースなどを続けます。
私はより高いレベルから始めます。ドキュメントに直面しているユーザーがいる場合-ユーザーマニュアルまたはガイド。それができなかった場合は、要件の仕様を見て、ソフトウェアが何をすべきかについての考えをつかむことができます。デザインを見て、それをコードファイルにマッピングしてみます。うまくいけば、これらは適切な方法でフォルダに構造化されます。次に、設計の一部を選択し、ファイルに移動してコードの流れをたどり、細部に行き詰まることはありません。
開発者システムをセットアップすることから始めます。文書化された手順を使用します。これにより、猫はドキュメントがどれだけ現実と同期しているかを把握できます。
また、依存関係が何であるかを教えてくれます。これは重要です。
開発者のセットアップが完了したので（そして、セットアップドキュメントに修正を加えてマークアップします）、バージョンをビルドします。最終的には、このフェーズ全体で質問をすることになります。
これでビルドされました。ユーザーマニュアルから導入演習を行います。これは、システムが実際に何をするかを大まかに教えてくれます。
これで、システムに関する部分的な手がかりが得られ、設計文書を読みました。これは、文書がこれまでにどの程度間違っていたかに比例するものだと考えています。
実際の動作に関するドキュメントに到達したら、コードを調べて、実際に何が存在するかを確認できます。彼らは決して並ぶことはありませんが、私は今、どれだけ信じるべきかを知っています。
次に、「todo」および「fixme」コメントのIDE出力を確認します。「バージョン2.0で修正」などのことも、チップオフです。
だから、真実を学ぶことがすべてであり、人々が指摘するように、個別の設計文書はほとんど最新または正しいものではありませんが、ある時点で人々が何を考えていたかを教えてくれます。そしてもちろん、それらの人々はおそらく尋問をしているわけではありません。
私の好みは、設計から始めてプロジェクトの概要を把握し、詳細を掘り下げる前にその主要な機能や構造のいくつかを理解しようとすることです。
複雑なソフトウェアの場合は、あたかもそれが新しい開発プロジェクトであるかのように大まかにアプローチします。大きなビジョン、ビジョン、コンテキスト、範囲、利害関係者から始めます。いくつかのユーザードキュメントを読み、それがどのように使用されるかを理解してください。可能であれば（または該当する場合）、ソフトウェアを使用してユーザートレーニングを行ってください。次に、要件と設計ドキュメントを調べて、高レベルでどのように機能するかを理解します。まだ残っている場合は、デザイナーに相談してください。さまざまな観点からシステムアーキテクチャを見てください。そこから、コア機能を掘り下げてコードを調べ、必要に応じて要件と設計に戻ります。コードを確認しながら、ソフトウェアを実行して動作を確認してください。その間、将来の参考のためにいくつかの要約ドキュメントをコンパイルします-あなたはCliffs Notesを所有しています。すべてがどのように機能し、適合するかについてかなり良いアイデアを得るまで分岐しますが、作業する部分に集中します。これで、システム全体、または少なくとも自分に該当する部分を完全に理解できました。
もちろん、現実の世界では、特に大規模なプロジェクトで手を汚し始める前に、これらすべてを行う時間がない場合があります。しかし、これは私次第ならどうするかです。
コード自体と設計ドキュメントの間を行き来する必要があります。
コードまたは設計から始めることができますが、それは実際には重要ではありません。よくわかり、本当に混乱するまでコードを読んでから、設計ドキュメントを調べてください。または、設計ドキュメントを読んで概要を把握し、コードを見てその外観を確認してください。コードで作業している限り、ほぼ無限に繰り返します。
設計ドキュメントはほとんど常に古く、多くの点で間違っていることに注意してください。ただし、これらの点を念頭に置いている限り、古いドキュメントは、過去のある時点で著者の心を理解するのに役立ちます。高レベルの問題や懸念の多くは依然として有効であり、作成者が当初考えていた場所の日付付きの写真さえあれば、コードがどこにあるのかをより迅速に理解できる可能性が非常に高くなります行く。
コードと設計を進めながら、今日のコードの理解を説明する独自のドキュメントを作成します。これらのドキュメントは、1つか2つの簡単なスケッチかもしれませんし、Wikiの記事かもしれませんし、何か別のものかもしれません。あまり複雑にしないでください。30ページのワードドキュメントはありません。自分の考えを打ち倒すだけで、自分の考えが大きく明確になります。
設計ドキュメントから始めます。特に、仕様-それは見られているものの意図を伝えます。
可能であれば、デザインノートとドキュメントを参照して、それがどのように行われたか、思考プロセス、関係者のスタイルと性質の概要を把握します。
可能であれば、その後、その作業に携わった人々と話をします-それは何をしますか？どうやって？どうして？遺体はどこに埋葬されていますか？
開発者の間では、コードに飛び込む傾向があります。「このコードを見せてください」。これは彼らにとっては良いことですが、私のニーズをハイジャックする傾向があります-これは、低レベルのものにコンテキストを与える高レベルを理解することです。
膨大な量の頭脳を使用して、完全なコンテキストから少しのコードを見て、意味のあるものを理解します。そのため、可能であれば、開発者に、原則、構造、ユニット、モジュールなど、すべてがタスクの評価につながるものについて話すようにします。
そうしてはじめて、コードに挑戦する価値があります。
物事の大きなスキームでは、コードを見ることは、0と1でいっぱいのページを見ることに似ています。意味はありますが、それを理解するには長い時間がかかります。どこを見るか、どの部分が意味があるかを知ることで、検索スペースを狭めることができます。
つまり、ドコ、人、コードだけが存在しない場合、コードを見る以外に何もありません。
その場合、私は通常ゆっくりとした深い読みでそれを理解しようとせず、クイックパスを行い、すべてを読み飛ばします。時々、これは単にファイルを開いて、ページダウンキーを押して座っていることです。これを行うだけで、全体像を驚くほど高く評価できます。（場合によっては、実行可能ファイルを文字列ダンプし、署名とパターンを探してそれらをトロールすることもあります。これは過去20年間で驚くほど実りの多いものです。）
テストから始めます。単体テストと統合テストが適切に記述されている場合、それらはユースケースを説明します。それらがうまく書かれていないか、まったく書かれていない場合（悲しいことに、これは主にそうです）、コードのエントリポイントから始めて、デザインと一致させます。
次に、エントリポイントを調査した後のツリーで発見された各ユースケースのテストを作成して、コードをプローブし、コードカバレッジユーティリティを使用して、不足しているものを確認します。これらのテストは、コードがどのように機能するかを正確に教えてくれます。
私はいつも私が見ているものに価値を加えようとしています。テストの作成、コードのクリーンアップ、大きな（20行以上）関数のリファクタリング。
ドキュメントを作成するだけでは、コードと相互作用することはないため、コードに実際の価値は追加されません。
さて、「デザイン」とは何ですか？README？UMLダイアグラム？設計文書を途中で作成できます（ほとんどの場合）、途中でコーディングすることはできません
コードは事実であるのに対して、どんなデザインも単に意見になります
コードの理由を理解できない場合にのみ、セカンダリドキュメントを参照します
コードを読むことは、開発者にとって不可欠なスキルです。あなたは今それを学ぶかもしれない、とにかくあなたのキャリアの間に多くの有用なドキュメントを見ることはないだろう
次に、開発者のREADME、TODO、およびChangelogを調べます。ソフトウェアがなぜ書かれたのか、どのように書かれたのか、そしてどこに行くのかわからない場合は...使用しません。
必要に応じて、最初にデザインを作成し、次にトップダウンでコーディングします。したがって、作業する必要があるすべてのレベルでコンテキストを理解します。
しかし、レポートや計算の修正など、非常に具体的な変更を行う必要がある場合は、コードを確認するだけです。
より具体的には、私の「最初の設計」アプローチは次のとおりです。
ドメインモデルが存在する場合は、ドメインモデルから始めます。存在しない場合は、少なくとも基本的なモデルを構築します（適切な出発点はデータモデルです）。アプリケーションの「用語集」とオブジェクト（クラス）間の関係を定義します。
アプリケーションによって「どのオブジェクトが処理されるか」を示しています。
次に、ユースケースモデルを探して、アプリケーションによって「どのプロセスが実行されるか」を見つけます。ただし、プロセスのシーケンスを示すプロセスマップがあればそれを使用します。
その後、アプリケーションの素晴らしい写真を撮って、変更の設計に取り掛かることができます。
ところで、上記の答えはビジネスアプリケーションのコンテキストにあります。
コードは嘘をつきません。最初にプロジェクトの概要を把握して、プロジェクトの機能を理解することをお勧めします。ただし、プロジェクトのしくみを詳細に理解することがタスクの場合、少なくとも私にとっては、コードを見るのは、見ている各クラスで別のジグソーパズルを1つずつ見るようなものです。ジグソーパズルのピース。コードが適切に構造化されている場合、クラスの動作を調査することなく、クラスの名前から形成されるパターンを見ることができます。多くの場合、さらに役立つコードからヒントや手がかりを得ることができます。
最後に、プログラムが何をするかについての明確なアイデア、完成したジグソーパズルを取得します。ドキュメントは不完全または不正確かもしれませんが、コードは決して嘘をつきません。これらすべては、個々のメソッドが何をするかを理解することなく実行できます。誰もがこの方法でプロジェクトについて学ぶことができるわけではありませんが、頻繁に行うと、数時間の学習で中規模アプリケーションの要点を理解できることは言うまでもなく、簡単になります。私はそれがすべて好みに帰着すると思いますが。
最も重要なモジュール/アプリケーションのポイントのコードを見た後：コードを見て、設計の良さを確認できます。
例：
あなたは、財務報告に関するウェブアプリのアプリケーション管理で作業する必要があります。
メッセージ、開始アプリケーションと終了アプリケーション（dbでのロックの可能性）、報告する必要のあるデータの作成のマスタープロセスなどに関するコードを読んだ後（たとえば、ガスのストレージでは、マスタープロセスは供給と注入を伴う顧客の貯蔵エリア内のガス在庫の計算;二次プロセスは、この計算済みのデータに関する請求です