大規模なプロジェクトをどのように追跡しますか？

多くの異なるファイルを持つプロジェクトを扱うとき、私は常に、パーツが相互にどのように相互作用するかについて、ゆるい追跡をしているように見えます。私は小さなコンポーネントを単独で理解するのに本当に大きな問題を抱えたことはありませんが、プロジェクトの複雑さが増すにつれて、何が起こっているのかを精神的に理解することができなくなります。メソッドとソースファイルの数が増えると、特にOOPプロジェクトでこれに気付きます。

私の経歴：私は独学のWebプログラマーです。私は主にpythonを使用して迅速で汚いスクリプトを処理しましたが、いくつかの基本的なdjangoプロジェクトも実行しました。私のようなWebフレームワークのようなフラスコ、単一ファイルレイアウトの単純さに、私は簡単に何が起こっているかの（主に）追跡することができますので。

私は今、誰かが開発した大規模なZend Framework PHPプロジェクトとやり取りする必要がある状況にいることに気づき、多数のファイルに広がるコードを理解しようとすることに圧倒されます。

他の誰かが開発した大規模なコードベースを理解するために、どのテクニックとプロセスが有用だと思いましたか？全体像を把握するのに役立つ特定の図はありますか？

大きなコードベースを理解する秘trickは、すべてを理解しようとしないことです。一定のサイズを超えると、全体の頭の中にメンタルモデルを保持できなくなります。最初に作業する必要があるすべてのタスクに意味のあるアンカーポイントから開始し、そこから分岐して、必要な部分のみを学習し、残りの部分が広告どおりに機能することを信頼します。再帰を理解するようなものです。スタック全体を頭の中で保持しようとすると、脳が爆発します。

Grep、デバッガー、およびインテリセンスはここであなたの友達です。関数がどのように呼び出されるかわからない場合は、その関数にブレークポイントを設定し、スタックトレースをたどります。

もう1つ注意すべきことは、大きなコードベースがどこからともなく出現しないことです。大きければ大きいほど、経験豊富なプログラマーが多くなるので、どこから始めればよいかを尋ねますが、具体的に説明してください。「新しい支払いプロバイダーを追加する必要があります。コードのどこを確認すればよいですか」などの質問をします。コードベース全体を理解しようとするのではなく、そのタスクだけに焦点を合わせれば、徐々に慣れ親しむことができます。

ショートカットはありません。苦しむ必要があります。

ダイアグラムの取得方法に関する質問に答えるには、doxygenが必要です。私の知る限り、PHPで動作します。

より一般的には、新しいコードベースに遭遇すると、おおよそ次の段階を経ます。

1. ユーザーの視点からそれが何をするかを理解してください。実際に自分でパワーユーザーのようにアプリケーションを使用できるようにします。実際のエンドユーザーがどのように作業するかを理解します。これには、彼らが何をするのかをしっかりと理解するまで、彼らと一緒に座る必要があります。

2. 可能であれば、元の開発者と通信します。最初は、エンドユーザーの経験に刺激されたアーキテクチャ上の質問があります。後ほど、エッジケースと詳細について実装に関する質問があります。開発者から回答を得ることができると、どんなコメントや文書よりもはるかに役立ちます（せいぜい不完全で、しばしば誤解を招くか、まったく存在しない）。

3. 使用しているフレームワークについて学びます。少なくとも、本番アプリケーションに飛び込む前に、そのフレームワークで「hello world」またはその他の単純なアプリケーションを作成できる必要があります。

4. 展開プロセス全体を把握します（元の開発者が手を握っている間に行うのが最適です）。現在のコードベースを取得してビルドし、テスト/検証/製品環境を介してデプロイできない場合は、乾杯です。わずかな変更でも、展開のすべての過程を飛び越える必要があるので、この部分をすぐに取得してみませんか？そうすることで、アプリで使用されるすべての素敵なサーバー、データベース、サービス、およびスクリプトを紹介します。「どこにあるか」がわかります。

5. 機能テスト（ある場合）を把握します。物事が適切に実行されているかどうかをどのように知っていますか アプリケーションのケアとフィードのために、運用担当者は何をしなければなりませんか？

6. アプリのログを理解します。PHPを使用したことは一度もありませんが、真剣な推測をして、本格的なPHPアプリケーションには何らかのログが記録されると言います。ログを理解していれば、問題をデバッグするときがきっかけになります。

----ここまでは、コードベースを詳しく見ることすら言及していないことに注意してください。コードを見なくても大きなプロジェクトについて学ぶことができるLOTがあります。もちろん、ある時点で、コードに慣れる必要があります。これが私を助けるものです：

7. 図の場合、doxygenは、コールグラフやその他の関係を生成する優れたツールです。たまたまPHP機能があります！doxygenを試したことがない場合は、絶対に試してみる必要があります。フレームワーク内のコードがどれだけわかりやすいかを保証することはできませんが、助けにはなります。元の開発者は、コードのdoxygenで生成されたドキュメントを提示されたときに目にするものにしばしばショックを受けます。良いニュースは、それは本当に彼らの記憶をジョギングし、あなたをより良くするのに役立つということです。

8. 単体テストのスイートがある場合、それらを詳細に調べると、アプリケーションの内部動作への窓が提供されるはずです。これらは、変更中に導入された可能性のあるバグを探す最初の場所にもなります。

9. IDEブックマークは、コードベースのホットスポットにタグ付けするのに非常に役立ちます。それらをすばやく切り替えることができると、理解が促進されます。

10. 最近のバグレポートとその解決策を読むことは、ホットスポットを理解するのにも役立ち、コードベースの最も関連性のある部分を理解するのに役立ちます。

要求に応じて、ここに答えとしての私のコメントがあります。

他の人のコードを扱うとき、静的構造の概要を示すためにUMLクラス図を作成するか、可能であれば生成する傾向があります。ビジュアルダイアグラムは、特に後で戻ってクラスのコンテキストを忘れてしまった場合に特に役立ちます。私は時々、共同研究者間の相互作用を整理するために動的な行動のためにそれをしますが、私はそれを頻繁に行いません。

コードベースにテスト（統合またはユニット）が含まれている場合、それらもチェックアウトする価値がある場合があります。

私は実際に今週の間に新しいクライアントが別の開発者によって残された製品の機能強化を必要とするときにこれを行うつもりです。従うべき手順は次のとおりです。

a）使用されているプログラミングフレームワークを特定します。これは、アプリケーションの流れを知るのに役立ちます。

b）共通サービス-ロギング、例外処理、MVC、データベース接続、監査、ビュー（ページ生成）を特定します。これらは最も使用する部分だからです。

c）（アプリケーション内の）一般的なユーザーフローを実行し、コードのレイアウト方法に合わせて調整します。

d）いくつかの変更を行い、それらがどのように出力されるかを確認してください。これは最大のステップです。なぜなら、変更を開始するまで、コードはまだブラックボックスだからです。

次の2週間でどのようなアイデアを得るかをお知らせします

私は、ドキュメントを読むべきだと考えています。ハッカーは「コードはドキュメンテーションです」と言って、ドキュメンテーションを書かない言い訳としてそれを使用するのが大好きですが、それは間違っています。Linuxカーネルを見てください。何百万行ものコードからなる大規模なソフトウェアプロジェクトです。本を読んでそれを手に入れなくても、誰もが真っ先にやってくるとは思いません。作業しているコードが文書化されていない場合（または小規模なプロジェクトの場合は十分にコメントされている場合）、おそらく適切なコードではありません。

ドキュメントがまったくない非常に大きなものを扱っている場合（私もそこに行ったことがありますが、大雑把です！）、それが役立つのは、作業中の部分を分離しようとすることです。コードのその部分で、データ/イベント/メッセージ/インタラクションがそのユニットをどのようにやり取りするかを把握します。つまり、インターフェイスをリバースエンジニアリングします。それを書き留め。次回、別のユニットで作業するとき（最初に作業したユニットと話す場合はボーナス）、同じことを行います。すべてのドキュメントを保管してください。数か月後には、物事がどのように流れるのかがよくわかります。

作業している1つの小さなユニットのインターフェイスを把握し、後で参照できるように記録します。時間が経つにつれて、それがどのように機能するかのほとんどをつなぎ合わせます。あなたのプログラムが何をしているかを見つけて、そのメッセージがどのように流れるかを追跡してください。たとえば、システムが何らかの入力ネットワークメッセージを受け取り、出力メッセージを送信する場合、すべての詳細を心配することなく、そのメッセージがシステムをどのように流れるかをトレースします。

私がやることは、javaからUMLに逆変換されたすべてのファイルから単一のUMLモデルを作成することです。このアプローチは、モデルがもはや単なるプロジェクトの抽象的なビューではなく、プロジェクト自体が完全にMOFに、したがってUMLにマップされることを意味します。

私が得るのは、それぞれが分類器などで構成されるパッケージで構成される複数のサブモデルで構成される大きな単一モデルです。マルチプロジェクトレベルで作業すると、マルチプロジェクトレベルで各分類子とメソッド呼び出しをトレースすることもできます。同じメソッドがプロジェクトAの1つの分類子とプロジェクトBの別の分類子を呼び出すことができることを意味します。プロジェクトの完全な構造を確認する唯一の方法は、両方を同時に反転することです。コンポーネント図を作成する時間がないので、情報は正確ではありません。私は完全なプロジェクトを逆にするようにコンピューターに依頼することを好みます。チームとの各反復でリバースを実行すると、すべてのダイアグラムがすぐに更新されます。リバースエンジニアリングはインクリメンタルであり、JavaからUML IDへのマッピングを使用します。つまり、各java要素は、リファクタリングされてもプロジェクトの全期間を通じて同じままである単一の一意のMOF要素にマッピングされます。これにより、UMLモデリングに制限がなくなり、非常に大規模で複雑なプロジェクトモデリングが可能になります。あなたの情報のために、私は5000行以上のOOPコードを持つプロジェクトで働いています。すべてのプロジェクトが適切に反転され、グラフィカルなナビゲーションが可能になります

UMLモデルから、常に最新のビューを必要な数だけ作成できるため、クラス図のみを使用します。非常に複雑なプロジェクトをモデル化することもできます。