どのようにして大規模なコードベースに飛び込みますか？

未知のコードベースを探索および学習するために、どのツールとテクニックを使用しますか？

私はのようなツールを考えていますgrep、ctagsコードメトリクスが好き、ユニットテスト、機能テスト、クラス図ジェネレータは、グラフを呼び出すsloccountように、と。私はあなたの経験、あなたが使用または書いたヘルパー、そしてあなたが働いたコードベースのサイズに興味があります。

コードベースに精通することは時間の経過とともに発生するプロセスであり、「コードを要約できる」から「リファクタリングしてサイズの30％に縮小できる」まで、なじみがあることを意味します。しかし、どのように始めるのでしょうか？

私がいつもやっていることは次のとおりです：

エディター（Visual Studio / Eclipse / Whatever）の複数のコピーを開き、デバッグしてコードを改行します。コードの流れを調べ、スタックトレースを実行して、キーポイントがどこにあるかを確認し、そこから進みます。

メソッドごとにメソッドを見ることができますが、何かをクリックして、コードのどこで実行されているかを確認して、それをフォローできると便利です。開発者が物事をどのように機能させたかを感じてみましょう。

象はどうやって食べますか？

一度に一口:)

真剣に、私は最初にコードの作者と話をしようとします。

仕事をやり遂げるまでハッキングする必要がありますか

大部分、はい（ごめん）。

あなたが検討するかもしれないアプローチ：

1. ビジネス用語で、コードが何をすべきかを調べてみてください。
2. どんなに悪くても、存在するすべてのドキュメントを読んでください。
3. コードについて何か知っているかもしれない人と話してください。
4. デバッガーでコードをステップ実行します。
5. 小さな変更を導入し、何が壊れるかを確認します。
6. コードを少し変更して、コードを明確にします。

コードを明確にするために私が行うことのいくつかは次のとおりです。

1. コードを適切にフォーマットするには、コードプリティファイアを実行します。
2. コメントを追加して、何ができると思うかを説明してください
3. 変数名を変更して明確にする（リファクタリングツールを使用）
4. 特定のシンボルのすべての使用を強調するツールを使用する
5. コードの混乱を減らす-コードをコメントアウト、無意味なコメント、無意味な変数の初期化など。
6. 現在のコード規則を使用するようにコードを変更します（再びリファクタリングツールを使用）
7. 機能を意味のあるルーチンに抽出し始めます
8. 可能な場合はテストの追加を開始します（ほとんどの場合不可能です）
9. マジックナンバーを取り除く
10. 可能な限り重複を減らす

...そして、あなたができる他のどんな単純な改善も。

徐々に、その背後にある意味がすべて明確になるはずです。

始める場所は？知っていることから始めます。入力と出力を提案します。多くの場合、これらがどのようなもので、何に使用されるのかを把握できます。アプリケーション全体のデータを追跡し、データの行き先と変更方法を確認します。

私がこれすべてで抱えている問題の1つは動機付けです-それは本当のスローになる可能性があります。ビジネス全体をパズルと考え、どんなに小さくても自分の進歩を祝うのに役立ちます。

あなたの状況は実際に一般的です。作業する既存のコードがある新しい仕事に入らなければならない人はだれでも、その要素を処理します。システムが本当に厄介なレガシーシステムである場合、それはあなたが説明したものと非常に似ています。もちろん、現在のドキュメントはありません。

まず、多くの人が、Michael Feathersによるレガシーコードの効果的な使用を推奨しています。これは本当に良い本です。「このクラスをテストハーネスに入れることができません」や「私のアプリケーションには構造がありません」などの有用な章があります。特に、この本とその例は、主に中括弧言語を対象としています。節のあるSQLプロシージャーを使用している場合、それほど有用ではない場合があります。「このコードを変更するほど十分に理解していない」という章はあなたの問題について述べていると思います。Feathersはメモを取り、リストをマークアップするなどの明らかなことをここで言及しますが、ソース管理がある場合は未使用のコードを削除できるという良い点もあります。多くの人が、コメントされたコードのセクションをそのまま残しています。

次に、提案されたアプローチは確かに良いステップだと思います。最初に、コードの目的を高レベルで理解する必要があります。

質問への回答が必要な場合は、メンターまたはチームの誰かと確実に連携してください。

また、欠陥が明らかになった場合、コードをサポートする機会を利用してください（ただし、これを自発的に行う必要がない場合もありますが、欠陥はあなたを見つけます！）。ユーザーは、ソフトウェアを使用する目的と欠陥がユーザーにどのように影響するかを説明できます。ソフトウェアの意味を理解しようとするとき、それはしばしば非常に有用な知識となります。さらに、攻撃の目的を持ったコードを使用してコードにアクセスすると、「獣」に直面したときに集中できる場合があります。

本当に大きなソースファイルがある場合は、次のことを行います。

• 混乱全体をクリップボードにコピーします
• Word / textmateに何でも貼り付けます
• フォントサイズを最小にします。
• コード内のパターンを見て下にスクロールします

通常のエディターに戻ると、コードがどれほど奇妙に見えるかに驚くでしょう。

時間がかかる

特に慣れていないテクノロジー/言語/フレームワークを使用している場合は、レガシコードベースを理解しようとするときに急ぎすぎないでください。時間がかかるのは避けられない学習曲線です。

1つのアプローチは、関連するテクノロジーのコードとチュートリアルを行き来することです。チュートリアルを読んで/見てから、コードを見て、前任者がどのようにそれを行ったかを確認し、類似点と相違点を書き留め、メモを取り、既存の開発者に質問します。

「なぜこの部分をこのようにしたのですか」

「私はほとんどのオンライン人がこの方法でそれをしていることに気づきました、そして、あなたはすべて別の方法でそれをしました。これはなぜですか？」

「テクノロジーYよりもテクノロジーXを選択した理由は何ですか？」

これらの質問に対する回答は、プロジェクトの歴史と、設計および実装の決定の背後にある理由を理解するのに役立ちます。

最終的には、物事を追加/修正し始めることができるほど十分に慣れているでしょう。すべてが紛らわしいと思われる場合や、進行中の「魔法」が多すぎるように思われる場合は、十分に時間をかけて見て、消化し、図を作成していません。ダイアグラム（シーケンス図、プロセスフロー図など）を作成することは、複雑なプロセスを理解するのに最適な方法であり、さらに「次の人」の助けにもなります。

cscopeは、ctagsがCに対してできることをすべて実行でき、さらに、現在のすべての関数が呼び出された場所をリストすることもできます。さらに、非常に高速です。数百万のLOCに簡単に拡張できます。emacsとvimにきれいに統合します。

CおよびC ++コードカウンター-ccccはHTML形式でコードメトリックを生成できます。LOCの取得にもwcを使用しました。

doxygenは、HTMLで強調表示された相互参照コードを生成できます。大きなコードベースを閲覧するのに便利です。

Drupalで推奨する方法は、Drupal固有のものではありません。問題トラッカーから始めてください。確かに古い、未解決のバグレポートがあります。それらを再現できますか？はいの場合、チケットを更新して確認します。いいえの場合は、閉じます。この方法を使用すると、ソフトウェアを使用する多くの方法がわかり、クラッシュするコードベースを覗き込むことができます。または、コードのステップ実行を開始して、コードがクラッシュした場所に到達する方法を確認できます。このようにして、コードベースを理解し始めるだけでなく、大量のカルマを蓄積し、質問をコミュニティに歓迎します。

行うべき重要なことの1つは、ツールを使用して依存関係グラフを生成し、コードアーキテクチャをトップダウンで探索することです。最初に.NETアセンブリまたはjar間のグラフを視覚化します。これにより、機能とレイヤーがどのように編成されているかがわかります。次に、名前空間の依存関係を調べます最後に、クラスの依存関係を見て、クラスのセットがどのように連携して機能を実装するかを理解できます。NDepend for .NETなど、依存関係グラフを生成するいくつかのツールがあり、以下のグラフを生成します。

かつて、非常に素晴らしいソフトウェアエンジニアに、コード分析とメンテナンスの最も高価な形式は、コードを1行ずつウォークスルーすることであると言われました。もちろん、私たちはプログラマーであり、それはほとんど仕事に付属しています。幸いな媒体は、次のとおりです（この順序で）：1.ノートを入手して、コードがどのように機能するかを理解するためのメモを作成し、時間が経つにつれて追加します。2.コードに関するドキュメントを参照してください。コードベースをサポートしている著者または他の人に相談してください。「ブレインダンプ」を依頼します。4.詳細レベルのクラス関係の一部を理解できるようになったら、コードのステップスルーデバッグを実行して、コードの動作とコードが実際にどのように機能するか。

まず、それが何をするつもりなのかを理解します-それなしでは、意味がわからなくなる可能性があります。ユーザーと話し、マニュアルを何でも読んでください。

次に、実行をクリックして、主要な機能と思われるコードのウォークを開始します。

分割統治。各機能と関連するコードを確認し、それらをステップスルーして次のコードに進み、全体像をゆっくりと構築します。

プロジェクトに単体テストがある場合、私もそれらをテストするのが好きです。それらは常に非常に明快で啓発的なものです。

1. すべてのテストがあれば実行し、どのコードがカバーされ、どれがカバーされていないかを確認します。
2. 変更する必要があるコードがカバーされていない場合は、それをカバーするテストを作成してみてください。
3. コードを変更します。テストを壊さないでください。

マイケルフェザーズのレガシーコードを効果的に使用する

これが私の短いリストです。

1. 可能であれば、誰かにコードの概要を説明してもらいます。どのパターンが考慮されたのか、どのような種類の規則が表示されると予想されるのかなど。これには最初にいくつかのラウンドがあるかもしれません。私が既存のプロジェクトのタマネギを使って作業するときに尋ねる。

2. コードを実行し、システムがどのように見えるかを確認します。確かに、いくつかのバグがあるかもしれませんが、これは何をするのかを知るのに役立ちます。これはコードを変更することではなく、これがどのように実行されるかを見るだけです。さまざまな部分がどのように組み合わされて、システム全体になりますか

3. コードの内部メンタルモデルの構築に役立つ可能性のある基本的なドキュメントのテストおよびその他のインジケータを探します。もちろん、ドキュメントやテストが非常に少ない場合を除いて、少なくとも数日はおそらくここで提案します。

4. このプロジェクトで使用されている言語とフレームワークをどの程度知っていますか？ここで重要なのは、いくつかのことを見て、「はい、前に数十回見て、それをかなりよく知っている」と「世界で何が試みられていますか？これは良いアイデアだと誰が考えましたか？」大声で言わないが、特に壊れやすいかもしれないレガシーコードを見ていて、それを書いた人々が利用できないか、単に理由を覚えていない場合、私はそれらを考えるでしょう物事はありのままに行われました。新しい領域については、このコードでどのような構造とパターンを見つけることができるかを知るために余分な時間を費やす価値があります。

最後になりましたが、次のいくつかの予想されるアイデアを考慮して、各時点で何をすべきかという観点からプロジェクトを実行する人の期待を把握してください。

• 新しい機能を導入していますか？
• バグを修正していますか？
• コードをリファクタリングしていますか？標準はあなたにとって新しいものですか、それとも非常に馴染みのあるものですか？
• コードベースに慣れるだけですか？

すべてのプログラムには1つ（たとえば、メインメソッド、メインクラス、初期化など）があるため、私は常にプログラムへのエントリポイントから始めようとします。これにより、何が開始され、時には物事がどのようにリンクされるかがわかります。

その後、ドリルダウンします。データベースとDAOはどこかに構成されているので、物事がどのように保存されているのかがわかります。おそらく、ある種のグローバルインスタンスクラスも開始され、そこに何が保存されているかがわかります。優れた屈折ツールを使用すると、誰が何を呼び出すかを見つけることができます。

次に、これが情報の次のエントリポイントであるため、インターフェイスが構成および処理される場所を見つけようとします。再構築、検索、およびデバッグツールは、検索に役立ちます。その後、情報の処理がどこで始まり、どこで終わるかを把握し、すべてのクラスファイルを処理します。

次に、最初に頭を包み込むために、フローを紙に書き留めます。送信ボタンは一般的な検証に渡され、DAOまたはデータベースに渡されてからデータベースに保存されます。これはほとんどのアプリの大幅な単純化ですが、一般的な考え方です。ペンと紙はここで非常に役立ちます。なぜなら、あなたはすべてをすばやく書き留めることができ、あなたを助けてくれるはずのプログラムのフォーマットを心配する必要がないからです。

私はドキュメンテーションなどから始めたいと思いますが、私の経験では、ドキュメンテーションとローカルの知識の深さはシステムの年齢、サイズ、複雑さに反比例することがよくあります。

そうは言っても、私は通常、いくつかの機能スレッドを特定しようとします。機能的には、ログイン、顧客リストのプルダウンなどを意味します。パターンに一貫性がある場合は、1つのスレッドでシステムの必ずしも完全な断面図ではないことがわかります。パターンに一貫性があるかどうかを判断する最良の方法は、少数のスレッドを分析することです。

これは言うまでもないと思いますが、私の意見では、技術的な観点からではなく、機能的な観点からシステムを理解する方が良いでしょう。私は通常、使用されているツール（ORM、ロギングライブラリなど）についてあまり心配せず、使用されているパターン（MVPなど）に集中します。私の経験では、ツールは一般的にパターンより流動的です。

私はとてもやりました...

「何かが機能している」状況での現在のアプローチを次に示します。「他の方法で機能する」必要があります。

1. 目標を達成し、そのシステムが解決しなければならない（書かれていない場合）-それを書いてください。マネージャー、他の従業員、以前の従業員であっても利用可能かどうか尋ねます。お客様に質問するか、ドキュメントを検索してください。
2. 特定を取得します。存在しない場合-それを書いてください。それが存在しないかのように、誰かに尋ねる価値はありません。そうすれば、他の人があまり気にかけない状況になります。したがって、独自の記述方法のみ（後で参照する方がはるかに簡単になります）。
3. デザインを取得します。存在しない-それを書いてください。可能な限りドキュメントとソースコードを参照するようにしてください。
4. 変更する必要がある部分に詳細な設計を記述します。
5. テスト方法を定義します。したがって、古いコードと新しいコードが同じように機能することを確認できます。
6. システムを1ステップで構築できるようにします。古いコードでテストします。まだない場合は、SVCに配置します。
7. 変更を実装します。以前ではありません。
8. 1か月程度後に、何も壊れていないことを確認してください。

各ステップの間に必要になる可能性のあるもう1つのオプションのtodo：f off manager（プロジェクト所有者）は、「これらの変更は昨日既に行われているべきだ」とあなたに伝えます。いくつかのプロジェクトの後、彼は事前に仕様やドキュメントを入手するのを手伝うことさえあります。

しかし、通常（特にスクリプトの場合）、ビジネススコープでは不可能です（コストが高すぎますが、価値は低くなります）。1つのオプションは、クリティカルマスに達するまで変更を行わず、システムが実稼働を終了する（新しいシステムが来るなど）か、管理者がこれらすべてを行う価値があると判断したことです。

PS：異なる設定を持つ5つのクライアントに使用された1つのコードを覚えています。そして、各変更（新機能）には、「使用されるパーツ」と「構成クライアントが持つもの」を考慮して、何もブレーキをかけたり、コードをコピーペーストしたりしないようにする必要がありました。プロジェクトのcvsに設定を行い、仕様を記述すると、この思考時間がほぼ0に短縮されます。

ソースコードを印刷して、読み始めます。特に大きい場合は、選択した部分だけを印刷して理解を深め、必要な数のメモ/コメントを作成してください。

実行の最初からプログラムをトレースします。コードベースの特定の部分に割り当てられている場合、その部分内の実行をトレースし、使用されているデータ構造を把握します。

オブジェクト指向言語を使用している場合は、一般的なクラス図を作成してください。これにより、概要がわかりやすくなります。

残念ながら、最終的には、できるだけ多くのコードを読む必要があります。運がよければ、以前のプログラマーは、何が起こっているのかを理解するのを助けるために、可能な限り多くのドキュメントを書きました。

新しいコードベースを学習するときに最初に行う必要があるのは、何をすべきか、その使用方法、使用方法について学習することです。次に、アーキテクチャドキュメントを参照して、コードのレイアウト方法を学習し、この時点でのデータベースの方法も調べます。同時に、アーキテクチャを学習しているので、プロセスフローを確認したり、ユースケースドキュメントを作成したりできます。全体像を理解してからコードに飛び込み、コードを読み始めますが、このコードで実行している可能性のある作業に関連するコードのみを使用し、すべてのコードを読み込もうとしないでください。Xが正確に行われる方法よりも、コードがXを実行する場所を知ることの方が重要です。

コードを習得する以上の目標なしでコードを読み込もうとすることは、一般的に非生産的であり、自分で小さな変更を行うか、他の誰かの変更のコードを確認することは、時間のはるかに生産的な使用であることがわかります。

コードベースが大きい場合は、現在作業中の部分に注意を集中してください。さもないと、あなたは圧倒されて、頭が爆発するかもしれません。いくつかの高レベルの概要が役立つと思います（利用可能な場合）が、プログラムフローを追跡するためにデバッガで多くの時間を費やす可能性があります。アプリケーションの概要を把握し、使用されていることを確認することをお勧めします。これにより、コードがどのように/何/なぜ使用されているかを理解できます。

私は通常、コードに対して何らかのコード複雑性ツールを実行して、問題のある領域を特定します。高得点の領域は、おそらく更新が非常に困難です。たとえば、サイクロマティックスケールで450を記録する関数に遭遇しました。案の定、何百ものIF。それを維持または変更することは非常に困難です。最悪の事態に備えてください。

また、特にシステムで作業している場合は、既存の開発者に質問することを恐れないでください。内なる考えを自分自身に保ち、問題の解決に集中してください。他の開発者を混乱させるようなコメントは避けてください。結局のところ、それは彼らの赤ちゃんであるかもしれず、彼らの赤ちゃんがいと言われるのを好む人はいません。

小さなステップを踏むだけで、わずかなコード変更でも大きな影響を与える可能性があります。

プログラムコードフローを考え出すことが役立つので、変更を加える場合、依存関係検索を実行して、どのメソッド/関数が何を呼び出すかを確認できます。メソッドCを変更するとします。

1つのメソッド/関数のみがCを呼び出す場合、それはかなり安全な変更です。何百ものメソッド/関数がCを呼び出すと、影響が大きくなります。

コードベースが適切に設計、作成、および保守されていることを願っています。もしそうなら、それを理解するにはしばらく時間がかかりますが、最終的には潮流が変わります。

それが泥の大きな球であるなら、あなたはその内部の働きを決して理解しない（または理解したい）かもしれません。

私がやること

1）Source Monitorなどのソース分析ツールを使用して、さまざまなモジュールサイズ、複雑さのメトリックなどを決定し、プロジェクトの雰囲気をつかみ、重要な領域を特定します。

2）何が起こっているのか、コードベースのどこにいるかがわかるまで、Eclipseでコードを上から下にドリルスルーします（参照などを参照できるエディターがあると便利です）。

3）時折、Visioで図を描いて、アーキテクチャのより良い図を取得します。これは、プロジェクトの他のユーザーにも役立ちます。

これはよく起こります。オープンソースプラットフォームで作業を開始するまで、コードにいくつかの「癖」があることを認めることから始めなかった仕事を始めたことはないと思います。

ステップデバッガーと多くの粘り強さで長い道のりを手に入れることができます。残念なことに、特定の大きな泥の塊を学ぶには時間と経験が必要な場合が多く、それでも何年も経っても、誰も知らないサブシステムが生まれることがあります。

泥だらけのものを変更する前に、単体テストを作成することをお勧めします。そして、唯一のテストに合格するために一度コードを十分に変更します。リファクタリングするときに、事前に単体テストを追加して、ビジネス機能がリファクタリングによって破壊されていないことを確認します。

ペアプログラミングはオプションですか？他の人にアイデアをバウンスさせることは、その量の厄介な問題に対処する素晴らしいアイデアです。

重複を排除するために使用する手順を次に示します。

• 重複する標準のコメントプレフィックスを選択します（[dupe]コメントマーカーの直後に使用します。
• 重複手順に使用する名前について、チームと仕様を作成します。
• 最初のラウンド：全員がいくつかのファイルを取得[dupe][procedure_arbitrary_name]し、複製された手順の前に追加します。
• 第2ラウンド：全員がプロシージャまたはプロシージャのサブセットを取り、異なる同じ目的の実装の類似性の順序を示す値を割り当てます（文字列は次のようになります[dupe][procedure_arbitrary_name][n]）。
• 第3ラウンド：各手順の責任者は、関連するクラスでそれを書き換えます。
• 第4ラウンド：grep幸せ！

最も重要なことの1つは、単純な機能を使用して、考えられる最も単純な機能を選択し、それを実装することだと思います。維持されたウィッシュリストがある場合は、それを使用するか、コードベースに精通した人に相談して、機能を提案してもらいます。通常、これは5〜20 LOCでの変更であると予想されます。重要な点は、非常に派手な機能を追加しているのではなく、コードベースで作業（またはむしろ:)）して、ワークフロー全体を実行しているということです。あなたはする必要があります

1. コードを読んで、変更するコンポーネントを理解します
2. コードを変更し、それが周囲のシステムに与える影響を理解します。
3. 変更をテストし、コンポーネントが相互作用する方法を特定します
4. テストケースを作成し、1つまたは2つのテストケースを分割して、システムの不変条件を理解できるようにします。
5. モノをビルドするか、CIがビルドしてから出荷するのを見る

リストは続きますが、重要なのは、このようなミニプロジェクトでは、システムに精通するためのチェックリストのすべての項目を確認し、生産的な変更が行われることです。

私が追加したかった小さなこと：

この種の問題のために最近使用し始めたツールの1つは、マインドマッピングです。頭の中に何かがどのように実装されているかの詳細をすべて詰め込もうとする代わりに、私が経験しているシステムがどのように機能するかを説明するマインドマップを作成します。何が起こっているのか、さらに何を理解する必要があるのか​​をより深く理解するのに本当に役立ちます。また、変更する必要があるものを非常に正確なスケールで追跡するのにも役立ちます。

多数のマインドマッピングの選択肢の中でフリープレーンを使用することをお勧めします。

文書は存在しないか、文書がほとんどないか、古いものになります。存在するすべてのドキュメントを見つけます。チームリポジトリにある場合は、コピーを作成しないでください。そうでない場合は、そこに置いて、おそらく監督のもと、上司に整理する許可を求めてください。

チームのリポジトリにすべてを集め、用語集を追加します。すべてのベースには専門用語があります。用語集に文書化します。ツール、製品、顧客固有などのセクションを作成します。

ソフトウェア環境作成ドキュメントを作成/更新します。すべてのツール、癖、インストールの選択などがここにあります。

次に、「ProductName」入門ドキュメントなどをアップロードします。それが単なる心の流れであり、時間の経過とともに自己組織化するようにします。その後、古いドキュメントを調べて、最新の状態に戻します。他の開発者はそれを高く評価するでしょう。コードを学びながら、あなたはユニークな方法で貢献するでしょう。特に、あなたを困らせたり、間違った名前を付けたり、直観に反するようなものをすべて文書化します。

学習曲線が終わりに近づいたら、ドキュメントの更新について心配する必要はありません。次の新しい男にそれをさせてください。彼が到着したら、彼をあなたの作品に向けます。彼が答えを求めてあなたをバグし続けるとき、彼に答えないでください。むしろ、ドキュメントに質問を追加してから、URLを渡してください。釣り竿。

副作用の1つは、忘れてしまったときに、数か月後に参照できるツールを自分で作成してしまうことです。

また、ドキュメントではありませんが、関連する問題は、チームメイトが行う少し風変わりで手作業の多い手順です。バッチ、SQLスクリプトなどでそれらを自動化し、それらも共有します。結局のところ、手続き型の知識は、新しい環境で生産性を高めるという点では、宣言型の知識とほぼ同じくらいの大きさです。それが何であれ、それをしないでください。むしろ、スクリプトを作成して、スクリプトを実行します。釣り竿が再び攻撃します。

このトピックに関するかなり長い記事を書きました。抜粋です

私はこの問題についてかなり長い間考えていました。私は、一般的なプロセスとして自分の個人的なソリューションを作成することにしました。文書化した手順は次のとおりです。

1. 語彙シートを作成する
2. アプリケーションを学ぶ
3. 利用可能なドキュメントを参照する
4. 仮定をする
5. サードパーティのライブラリを見つける
6. コードを分析する

このプロセスは、大規模なデスクトップアプリケーションのコンテキストで記述されていますが、一般的な手法は引き続きWebアプリケーションと小さなモジュールに適用できます。

撮影：新しいコードベースの学習プロセス

共有できる小さなヒントがいくつかあります。

既存の製品の場合、集中的にテストを開始します。タスクを選択/取得する場合、特定の機能にさらに焦点を当てます。

• 次のステップは、依存モジュール、ライブラリ、フレームワークなどを見つける途中で、侵入して探索を開始できるコードを見つけることです。

• 次のステップは、その責任を持つ単純なクラス図を作成することです（CRCカードのように）

• マイナーな変更を開始するか、マイナーなバグを取り上げて修正してコミットします。したがって、プロジェクトのワークフローを学ぶことができます。コードだけではありません。多くの場合、大規模な製品には、承認と監査のために何らかの種類の帳簿があります（医療プロジェクトなど）。

• すでにプロジェクトに取り組んでいる人々と話してください。あなたのアイデア、考えを表現し、見返りに彼らの経験とこのプロジェクトでの長期にわたる意見を得る。これは非常に重要です。なぜなら、それはまた、チームとうまくやっていくのに役立つからです。

自分で大きなコードベースに飛び込む必要があったのは久しぶりです。しかし、ここ数年で、既存のかなり大きなコードベースがあるチームに新しい開発者を引き入れるために何度も試みました。

そして、私たちが首尾よく使用した方法、そして間違いなく私見で最も効果的な方法はペアプログラミングです。

過去12か月で、チームに4人の新しいメンバーが加わりました。そのたびに、新しいメンバーはコードベースに精通した別のメンバーとペアになります。最初は、年長のチームメンバーがキーボードを使用していました。約30分後、キーボードを新しいメンバーに渡します。新しいメンバーは、古いチームメンバーの指導の下で働きます。

このプロセスは非常に成功していることが証明されています。