legacy - 大規模なコードベースに慣れるための最良の方法は何ですか?

Question

大規模なコードベースが既に配置されている既存のチームに参加することは、困難な場合があります。最善のアプローチは何ですか;

ブロード; コードから、すべてがどのように相互にリンクしているかの概要をつかむようにしてください
狭い; 一度にコードの小さなセクションに集中し、それらがどのように機能するかを完全に理解する
開発する機能を選択し、作業を進めながら学習します
クラス図と UML が利用可能である場合 (および最新の場合) から洞察を得るようにしてください。
まったく別の何か？

私は現在、約 20k 行の C++ アプリとライブラリに取り組んでいます (編集: 物事の壮大な計画では小さい!)。業界では、経験豊富なプログラマーから紹介を受けると思います。しかし、そうでない場合、できるだけ早く付加価値を開始するにはどうすればよいでしょうか?

--
回答の要約:

デバッグモードでコードをステップ実行して、その動作を確認します
あなたよりもコードベースに精通している人とペアを組んで、コーディングする人と見たり議論したりする人を交代で行います。チームメンバー間でパートナーをローテーションして、知識が広まるようにします。
単体テストを書きます。コードがどのように機能すると思うかについての主張から始めます。期待どおりの結果が得られた場合は、おそらくコードを理解しています。そうでない場合は、パズルを解くか、問い合わせを行う必要があります。（ドナルに感謝します。これは素晴らしい答えです）
上記と同様の方法で、機能コードの既存の単体テストを実行します
UML、Doxygen によって生成されたクラスダイアグラム、およびその他のドキュメントを読んで、コードの全体像を把握してください。
小さな編集やバグ修正を行い、徐々に積み上げていきます
メモを取り、飛び込んで開発を開始しないでください。面倒なコードや不適切なコードを生成するよりも、理解に時間を費やす方が価値があります。

この投稿は、 the-best-way-to-familiarize-yourself-with-an-inherited-codebaseの部分的な複製です

score 25 · Accepted Answer

可能であれば、いくつかの小さなタスクから始めて、問題の周りのコードをデバッグします。デバッグモードでコードをステップスルーするのが、何かがどのように機能するかを学ぶ最も簡単な方法です。

score 18 · Accepted Answer

もう1つのオプションは、関心のある機能のテストを作成することです。テストハーネスを設定することは、システムの依存関係とその状態が存在する場所を確立するための良い方法です。各テストは、システムが機能する必要があると考える方法についてのアサーションから始まります。それがそのように機能することが判明した場合、あなたは何かを達成し、それを再現するためのいくつかの実用的なサンプルコードを持っています。それがそのように機能しない場合は、解決するパズルと従うべき一連の問い合わせがあります。

score 11 · Accepted Answer

まだ言及されていない人々に私がいつも提案していることの 1 つは、開発者になる前に、既存のコードベースの有能なユーザーになることが重要だということです。新しい開発者が私たちの大規模なソフトウェアプロジェクトに参加するときは、コードの作業に取り掛かる前に、時間をかけてエキスパートユーザーになることをお勧めします。

当たり前のことかもしれませんが、私は多くの人がコードにすぐに取り掛かろうとするのを見てきました。

score 9 · Accepted Answer

これは、あなたがどのような学習者であり、どのようなプログラマーであるかに大きく依存しますが、次のようになります。

まず広い範囲-範囲とサイズのアイデアが必要です。良ければ、これにはdocs/umlのスキミングが含まれる場合があります。それが長期的なプロジェクトであり、すべてを完全に理解する必要がある場合は、実際にドキュメントを正しく読むことができます。繰り返しますが、もし彼らが良ければ。
狭い-扱いやすいものを選び、それを理解しようとします。コードの「味」を取得します。
機能を選択します。自信がある場合は、今見た機能とは異なる機能を選択し、小さな変更を加え始めます。
反復-物事がどれだけうまくいったかを評価し、初期のステップをより深く繰り返すことで利益が得られるかどうかを確認します。

score 7 · Accepted Answer

厳格なローテーションとのペアリング。

可能であれば、ドキュメント/コードベースを調べながら、厳密なローテーションでペアリングを採用してみてください。つまり、2 人が一定時間 (たとえば 2 時間のセッション) 一緒に座ってから、ペアを切り替えます。1 人がそのタスクに取り組み続け、もう 1 人が別のパートナーと別のタスクに移ります。

2 人一組になって知識の一部を習得し、ローテーションが発生したときにその知識をチームの他のメンバーに提供することができます。これの良いところは、新しいペアが一緒になったときに、タスクに取り組んだ人 (この場合はコードの調査) が、より簡単に理解できる方法で概念を要約して説明できることです。時間が経つにつれて、誰もが同様の理解レベルに達し、うまくいけば「ああ、ジョンだけがそのコードのビットを知っている」という症候群を避けることができます.

あなたのシナリオについて私が言えることから、これには十分な数 (3 ペア) がありますが、分散している場合、または同じタイムスケールで作業していない場合、可能性は低いです。

score 6 · Accepted Answer

Doxygenを実行して最新のクラス図を取得してから、しばらくの間拡張することをお勧めします。これにより、コードに近づいて汚れたときに使用できる全体像がわかりやすくなります。

score 5 · Accepted Answer

私はそれがあなたがどんなタイプの学習者であるかに完全に依存することに同意します。そうは言っても、私はそもそも非常に大きなコードベースを持っていた2つの会社にいました。通常、私は次のように動作します。

可能であれば、関数型コードを見る前に、すでに作成されている単体テストを実行します。これらは一般的に非常に役立ちます。それらが利用できない場合、私は次のことを行います。

まず、私は実装をほとんど無視し、ヘッダーファイルのみ、またはクラスインターフェイスのみを調べます。各クラスの目的が何であるかを理解しようとしています。次に、最も重要な領域と思われる領域から始めて、実装を1レベル深く掘り下げます。これを測定するのは難しいので、時々私はファイルリストの一番上から始めて下に向かって進んでいきます。私はこれを幅優先学習と呼んでいます。この最初のステップの後、私は通常、残りのコードを詳細に調べます。最初の幅優先探索は、インターフェイスレベルから得たアイデアを固め/修正するのに役立ちます。次に、深さ方向の外観は、システムの実装に使用されたパターンと、さまざまな設計アイデアを示します。深さ優先とは、基本的にデバッガーを使用してプログラムをステップ実行し、各関数にステップインしてどのように機能するかを確認することを意味します。等々。これは明らかに大規模なシステムでは不可能ですが、20kLOCはそれほど多くありません。:)

score 3 · Accepted Answer

システムに精通している別のプログラマーと協力して、新しい機能を開発したり、バグを修正したりします。これは私が見た中で最もうまくいく方法です。

score 2 · Accepted Answer

これを特定のタスクに結び付ける必要があると思います。時間があるときは、気分に合ったアプローチを選んでください。

やらなければならないことがあるときは、自分自身に焦点を絞り、それを成し遂げてください。

score 2 · Accepted Answer

まず、コードの経験があるチームメンバーがいる場合は、コードの概要を説明するように手配する必要があります。各チームメンバーは、専門分野に関する情報を提供する必要があります。複数の人に説明してもらうことは通常価値があります。なぜなら、他の人よりも説明が上手な人もいれば、他の人よりも理解が深い人もいるからです。

次に、プレッシャーをかけずにしばらくの間コードを読み始める必要があります（上司がそれを提供する場合は数日または1週間）。多くの場合、プロジェクトを自分でコンパイル/ビルドし、プロジェクトをデバッグモードで実行できるため、コードをステップ実行できます。次に、足を濡らし、小さなバグを修正し、小さな機能強化を行います。うまくいけば、すぐに中規模のプロジェクト、そして後で大きなプロジェクトの準備が整います。あなたが行く間、あなたのチームメイトに頼り続けてください-しばしばあなたはあなたを指導してくれる人を特に見つけることができます。

苦労している場合でも、自分自身に過度の負担をかけないでください。これは正常なことです。大規模なコードベースを理解するには、長い時間、場合によっては数年かかることがあります。実際、何年経っても、コードの一部にまだ少し怖くて不透明な部分が残っていることがよくあります。プロジェクト間のダウンタイムが発生すると、それらの領域を掘り下げることができ、数回の試行の後、それらの部分さえも理解できることがよくあります。

幸運を！

score 2 · Accepted Answer

チームに 2 週間のバグ修正を依頼してください (2 週間ある場合)。彼らは喜んで誰かにその責任を負わせ、その期間の終わりまでに、あなたはライブラリの問題解決に多くの時間を費やしたので、あなたはおそらくそれをよく知っているでしょう.

score 2 · Accepted Answer

単体テストがある場合 (ないに違いない)。小さく始めて、単体テストが失敗しないようにします。コードベース全体を一度に見つめると、目が眩み、圧倒されます。

単体テストがない場合は、必要な機能に集中する必要があります。アプリを実行し、機能が影響を与える結果を確認します。次に、コードを調べて、アプリが変更したいものをどのように作成するかを理解しようとします。最後にそれを変更し、結果が思いどおりになることを確認します。

あなたはそれがアプリとライブラリだと言いました。最初にアプリを変更し、ユーザーとしてライブラリを使用することに固執します。その後、ライブラリを学習すると、変更が容易になります。

トップダウンのアプローチから、アプリにはおそらくすべてのアクションを制御するメインループまたはメイン GUI があります。アプリケーションの主な制御フローを理解することは価値があります。コードを読んで、アプリのメインフローの概要を把握することをお勧めします。GUI アプリの場合は、どの画面があり、ある画面から別の画面に移動する方法を示す紙を作成します。コマンドラインアプリの場合、どのように処理が行われるか。

企業においても、このようなアプローチは珍しくありません。多くの場合、アプリケーションがどのように機能するかを完全に理解している人はいません。そして、人々はあなたを案内する時間がありません. 彼らは特定のことについて特定の質問を好むので、自分で掘り下げて実験する必要があります. 次に、特定の質問が得られたら、アプリケーションのその部分に関する知識のソースを分離して質問することができます。

score 2 · Accepted Answer

ソースコードのリバースエンジニアリングツールを検討することをお勧めします。私が知っている2つのツールがあります：

SWAG キット (Linux のみ)リンク
バウハウスのアカデミックコマーシャル

どちらのツールも、ソフトウェア内のモジュール間の関係のグラフを生成する静的分析を含む同様の機能セットを提供します。

これは主にコールグラフと型/クラスの品位で構成されます。この情報を表示すると、コードの各部分が互いにどのように関連しているかがよくわかります。この情報を使用して、最も関心があり、最初に理解/変更する必要がある部分の実際のソースを掘り下げることができます。

score 2 · Accepted Answer

「問題領域」を理解することから始めます (それは給与システムですか? 在庫管理ですか? リアルタイム制御など)。ユーザーが使用する専門用語を理解していなければ、コードを理解することはできません。

次に、オブジェクトモデルを見てください。すでに図が存在するか、リバースエンジニアリングが必要になる場合があります (手動で、または Doug が提案するツールを使用して)。この段階で、データベース (存在する場合) を調査することもできます。オブジェクトモデルに従う必要がある場合は、そうでない場合もあります。これを知ることは重要です。

変更履歴またはバグデータベースを調べてください。頻繁に出てくる領域がある場合は、まずその部分を調べてください。これは、書き方が悪いという意味ではありませんが、誰もが使用するビットです。

最後に、いくつかのメモを残します (私は wiki の方が好きです)。

既存の人はそれを使用して、あなたの仮定を健全にチェックし、あなたを助けることができます.
後で参照する必要があります。
チームの次の新人は本当にありがとう.

score 2 · Accepted Answer

私も似たような状況でした。私はあなたがこのように行くと思います：

データベース駆動型アプリケーションの場合は、データベースから始めて、各テーブル、そのフィールド、および他のテーブルとの関係を理解しようとします。
基盤となるストアに問題がなければ、ORM レイヤーに移動します。これらのテーブルには、コードで何らかの表現が必要です。
それが終わったら、これらのオブジェクトがどのように、どこから来ているのかに移ります。インターフェース？何のインターフェース？検証はありますか？データストアに移動する前に、どのような前処理が行われますか?

これにより、システムに慣れることができます。単体テストを作成または理解しようとすることは、何をテストするのか、なぜその方法だけでテストする必要があるのかをよく知っている場合にのみ可能であることを忘れないでください.

また、データベースに依存しない大規模なアプリケーションの場合は、別のアプローチをお勧めします。

システムの主な目的は何ですか?
この問題を解決するためのシステムの主要コンポーネントは何ですか?
各コンポーネントは、それらの間でどのような相互作用を持っていますか? コンポーネントの依存関係を表すグラフを作成します。すでに取り組んでいる人に聞いてください。これらのコンポーネントは互いに何かを交換している必要があるため、それらも把握してみてください (IO が File オブジェクトを GUI に戻すなど)。
これに慣れたら、とりわけ依存度が最も低いコンポーネントに飛び込みます。次に、そのコンポーネントがさらにクラスに分割される方法と、それらが互いにどのように相互作用するかを調べます。このようにして、合計で 1 つのコンポーネントのコツをつかむことができます
次に依存度の低いコンポーネントに移動
最後に、通常、既に取り組んだ他の多くのコンポーネントに依存するコアコンポーネントに移動します。
コアコンポーネントを見ていると、以前に調べたコンポーネントを参照している可能性があります。心配しないで、がんばってください。

最初の戦略: このスタックオーバーフローサイトの例を見てみましょう。データストア、何が格納されているか、どのように格納されているか、それらのアイテムがコードでどのように表現されているか、UI でどのように表示されるかを調べます。それらがどこから来て、データストアに戻ったときにどのような処理が行われるか。

2 番目 の例として、ワードプロセッサの例を取り上げます。どのようなコンポーネントがありますか? IO、UI、ページなど。これらはどのように相互作用していますか？さらに学びながら進んでください。

くつろぐ。書かれたコードは誰かの考え方であり、論理や考え方が固まっていて、その心を読むには時間がかかります。

score 1 · Accepted Answer

コードに飛び込むだけでも、少し圧倒される可能性があることがわかりました。設計に関するドキュメントをできるだけ多く読むようにしてください。これにより、各コンポーネントの目的と構造が説明されることを願っています。既存の開発者がそれを理解できる場合に最適ですが、それが常に可能であるとは限りません。

コードの高レベルの構造に慣れたら、バグを1つか2つ修正してみてください。これは、実際のコードを理解するのに役立ちます。

score 1 · Accepted Answer

Doxygen のようなツールを使用してクラス図を作成し、まず全体像を理解する必要があるというすべての回答が気に入っています。私はこれに完全に同意します。

とはいえ、これはコードが最初からどれだけうまく分解されているかに大きく依存します。それが巨大な混乱であれば、学ぶのは難しいでしょう。きれいに整理されていれば、それほど悪くはありません。

score 1 · Accepted Answer

テストカバレッジツールを使用して、その機能がどこにあるか、または多くのモジュールにどのように分散しているかについて何も知らずに、関心のある機能のコードを見つける方法については、この回答を参照してください。

score 0 · Accepted Answer

（恥知らずなマーケティング先）

nWireをチェックしてください。これは、大規模なコードベースをナビゲートおよび視覚化するための Eclipse プラグインです。多くのお客様は、主要なフローの視覚化を印刷することにより、新しい開発者を慣らすために使用しています。

legacy - 大規模なコードベースに慣れるための最良の方法は何ですか?

19 に答える 19

Related

Reference