21

Stacker新しいプログラマーが現場に足を踏み入れたときに見つけた最も衝撃的なことについて、誰も尋ねませんでした。

リストの非常に上位にあるのは、すぐに慣れなければならないコードベースを継承することの影響です。N 行のコードを維持する責任が突然自分に課せられ、それがどのくらいの期間にわたってまとめられているかを知り、それに貢献し始める時間が短いことに気付くと、非常にショックを受ける可能性があります。

この新しいデータをすべて効率的に吸収するにはどうすればよいでしょうか? この移行を容易にするものは何ですか? ショックが収まるほどの数のオープンソース プロジェクトにすでに貢献している唯一の現実的な解決策はありますか?

これは、ベテラン プログラマーにも当てはまります。新しいコードベースへの移行を容易にするために、どのような手法を使用していますか?

これらの移行に関するいくつかの戦争の話を聞きたいので、これに Community-Building タグを追加しました。特にストレスの多い学習曲線をどのように処理したかを自由に共有してください.

4

13 に答える 13

14

鉛筆とノート (要求されていない解決策を作成しようとして気を散らさないでください)

  • 毎週月曜日に 1 時間かけてメモを取り、前の週のメモを読んで整理する

  • 大規模なコードベースでは、最初の印象に惑わされる可能性があり、慣れているうちに問題が急速に再編成される傾向があります。

  • 前回の作業環境での問題が、新しい環境では必ずしも有効であるとは限らないことを忘れないでください。先入観に注意。

  • 作成したメモ/観察は、どの質問を誰に尋ねるべきかをすばやく知るのに役立ちます。公式 (および非公式) のすべての関係者の名前を集めていることを願っています。

于 2008-10-18T05:38:30.200 に答える
13

継承されたコードに慣れるための最良の方法の 1 つは、手を汚すことです。いくつかの単純なバグを修正することから始めて、より複雑なバグに取り組んでください。これは、コードを体系的にレビューしようとするよりも、コードに慣れるのに役立ちます。

要件または機能仕様のドキュメント (最新のものであることが望ましい) がある場合は、それを読む必要があります。

高レベルまたは詳細な設計ドキュメント (最新のものであることが望ましい) がある場合は、おそらくそれを読む必要があります。

別の良い方法は、コードに精通している人々との「情報伝達」セッションを手配することです。そこで彼らは高レベルの設計のプレゼンテーションを提供し、コードの重要な/トリッキーな部分のウォークスルーも行います。

于 2008-10-18T05:26:23.033 に答える
11

単体テストを書きます。疣贅をより迅速に見つけることができ、コードを変更するときが来たときに自信が持てるようになります。

于 2008-10-18T05:09:14.767 に答える
4

コードの背後にあるビジネス ロジックを理解するようにしてください。なぜコードが最初に書かれたのか、そしてそれが何をするべきなのかがわかったら、それを読み始めることができます。

于 2008-10-18T08:53:55.000 に答える
3

私の手順は次のとおりです。

1.) コード ベース内のすべてのソース、ヘッダー ファイルを使用して、ソース インサイト (または使用する適切なソース コード ブラウザー) ワークスペース/プロジェクトをセットアップします。最上位の関数 (main) から最下位の関数まで、より高いレベルでブラウズします。このコード ブラウジングの間、関数呼び出しの流れをたどる紙またはワード ドキュメントにメモを書き続けます。このステップでは、関数の実装の詳細には入らないでください。後の反復のために保持してください。このステップでは、関数に渡される引数、戻り値、関数に渡される引数がどのように初期化されるか、それらの引数セットの値がどのように変更されるか、戻り値がどのように使用されるかを追跡します。

2.) ステップ 1.) を 1 回繰り返した後、コード ベースで使用されるコードとデータ構造のレベルを取得し、MSVC (またはコード ベースのプログラミング言語に応じて他の関連するコンパイラ プロジェクト) をセットアップし、コンパイルします。コードを実行し、有効なテスト ケースで実行し、メインから関数の最後のレベルまでコードをもう一度 1 ステップ実行します。関数呼び出しの合間に、渡された、返された、さまざまなコード パスが取られた、さまざまなコード パスが回避されたなどの変数の値を動かし続けます。

3.) 1.) と 2.) を繰り返して、コードを変更したり、コードを追加したり、既存のコードのバグを見つけたり、バグを修正したりできるようになるまで繰り返します。

-広告

于 2008-10-18T07:07:26.790 に答える
2

これが「最善の方法」であるかどうかはわかりませんが、最近の仕事で行ったことは、コード スパイダー/パーサーを (Ruby で) 作成し、呼び出しツリー (および逆呼び出しツリー) を構築することでした。後でクエリを実行できます。SQL関数/プロシージャを呼び出すPerlを呼び出すPHPがあったため、これは少し重要でした。他のコード クロール ツール (つまり、javadoc、rdoc、perldoc、Doxygenなど) も同様の方法で役立ちます。

単体テストや仕様を読むことは、非常に啓発的です。

物事を文書化することは役に立ちます (自分のために、または他のチームメイトのために、現在および将来のために)。既存のドキュメントを読みます。

もちろん、チームメイト (または上司) に質問することの威力を過小評価しないでください。早い段階で、私は必要に応じて「X を実行する関数/スクリプト/foo はありますか?」と尋ねました。

于 2008-10-18T05:20:27.803 に答える
1

コア ライブラリを調べて、関数宣言を読んでください。C/C++ の場合、これはヘッダーのみを意味します。わからないことは文書化する。

前回これを行ったとき、挿入したコメントの 1 つは「このクラスは使用されていません」でした。

于 2008-10-18T05:37:08.487 に答える
1

バグを修正して、コードを理解するようにしてください。ドキュメントを修正または維持します。コード自体のコメントを変更しないでください。新しいバグが発生するリスクがあります。

私たちの仕事では、一般的に言えば、正当な理由なしに製品コードを変更することはありません。これには外見上の変更が含まれます。これらでもバグが発生する可能性があります。

コードのセクションがどれほど不快に見えても、バグ修正やその他の変更を行う必要がない限り、それを書き直そうとしないでください。学習しようとしてコードを読んでいるときにバグ (またはバグの可能性) を見つけた場合は、後でトリアージできるようにバグを記録しますが、修正しようとしないでください。

于 2008-10-18T06:38:30.657 に答える
1

別の手順...

Andy Hunt の"Pragmatic Thinking and Learning - Refactor Your Wetware" (これには直接触れていません) を読んだ後、言及する価値のあるヒントをいくつかピックアップしました。

行動を観察する:

UIがあればなお良し。アプリを使用して、関係 (リンク、モーダルなど) のメンタル マップを取得します。役立つかどうか HTTP リクエストを調べてください。

フォルダー構造を確認します。

繰り返しますが、これは軽いです。何がどこに属しているかを確認し、構造が十分にセマンティックであることを願っています。ここから常にトップレベルの情報を取得できます。

コールスタックをトップダウンで分析:

紙やその他の媒体に目を通してリストしますが、タイプしないようにしてください-これにより、脳のさまざまな部分が関与します(必要に応じてレゴから構築します)-関数呼び出し、オブジェクト、および変数最初にトップレベルに最も近い。定数とモジュールを見て、できれば細かい機能に飛び込まないようにしてください。

マインドマップ!:

おそらく最も重要なステップです。コードの現在の理解の非常に大まかなマッピング ドラフトを作成します。マインドマップをすばやく実行してください。これにより、脳のさまざまな部分 (主に R モード) がマップで発言できるようになります。

  1. 雲、ボックスなどを作成します。最初に紙に配置する必要があると思われる場所に配置します。自由に構文記号でボックスを示してください (例: 'F'-Function、'f'-closure、'C'-Constant、'V'-Global Var、'v'-low-level var など)。矢印を使用します: 引数には着信配列、戻り値には発信配列、またはより自然に思いつくもの。
  2. 関係を示すために接続を描き始めます。乱雑に見えても問題ありません。これは最初のドラフトです。
  3. 手早く大まかな修正を行います。読みにくいので、別の簡単な構成を行いますが、複数の改訂は行わないでください。

デバッガーを開きます。

  1. マッピング後に持っていた考えを検証または無効にします。変数、引数、戻り値などを追跡します。
  2. HTTP リクエストなどを追跡して、データの送信元を把握します。ヘッダー自体を確認しますが、リクエスト本文の詳細には飛び込まないでください。

マインドマップ再び!:

これで、トップレベルの機能のほとんどについて適切なアイデアが得られたはずです。

  1. 最初のマインド マップで見逃したものをすべて含む新しいマインド マップを作成します。これにはもっと時間をかけて、比較的小さな詳細を追加することもできますが、以前の概念と競合する可能性があることを恐れないでください.
  2. この地図を前回の地図と比較し、以前の疑問を取り除き、新しい疑問を書き留め、相反する視点を書き留めます。
  3. かすんでいる場合は、このマップを修正してください。必要なだけ修正しますが、修正は最小限に抑えてください。

コードではないふりをする:

機械的に表現できるなら、そうしてください。これの最も重要な部分は、アプリの動作やコードの小さな部分のメタファーを考え出すことです。ばかげたことを真剣に考えてください。動物だったら、モンスターだったり、星だったり、ロボットだったり。どんなものでしょう。それがスタートレックにあったとしたら、彼らはそれを何に使うでしょうか. それを比較検討するために多くのことを考えてください。

分析よりも合成:

ここで、「何」ではなく「どのように」を見たいと考えています。ループのためにあなたを介して低レベルの部分を取り出して無菌環境に置くことができます (あなたはその入力を制御します)。どのような出力が得られますか。システムは当初考えていたよりも複雑ですか? もっと簡単?改善が必要ですか?

何か貢献してください、おい!

テストを書き、バグを修正し、コメントし、抽象化します。ささいな貢献を始めるのに十分な能力が必要であり、失敗しても問題ありません:) ! コミット、チャット、メールで行った変更に注意してください。何か卑劣なことをした場合は、本番に移行する前にそれを見つけることができます。何か問題がある場合、チームメイトに問題を解決してもらうのに最適な方法です。通常、チームメイトの話を聞くと、マインドマップの衝突を引き起こした多くのことが解消されます。

一言で言えば、最も重要なことは、トップダウン方式を使用して、脳のさまざまな部分を可能な限り活用することです。ラップトップを閉じて、可能であれば席を窓の外に向けるとよいでしょう。調査によると、締め切りを強制すると、締め切りから 2.5 日後まで「プレッシャーの二日酔い」が生じることがわかっています。だから、リラックスして、タイムクランチはありません。そして、失敗しても安全な環境を自分自身に提供してください. 詳細に到達するまで、これらのほとんどはかなり急ぐことができます。高レベルのトピックの理解を回避しないように注意してください。

これがあなたにも役立つことを願っています:)

于 2014-03-20T21:43:46.483 に答える
0

コードベースから把握したことごとにドキュメントを作成します。実験によってそれがどのように機能するかを調べてください - あちこちで数行を変更し、何が起こるかを見てください. プログラムで一般的に使用される変数と関数の検索を高速化し、オートコンプリートに追加するため、geany を使用します。コード ベースの元の開発者に連絡できるかどうかを確認するには、facebook またはグーグルで検索してください。コードの本来の目的を見つけ出し、意図した目的を達成するために、コードがその目的に適合するか、最初から書き直す必要があるかどうかを確認します。

コードで使用されたフレームワーク、コードを生成するために使用されたエディターを調べます。

コードがどのように機能するかを推測する最も簡単な方法は、特定の部分がどのように行われたかを実際に再現し、そのような部分がある場合はコードを再チェックすることです。

それはリバース エンジニアリングです。つまり、ソリューションを再設計しようとするだけで何かを見つけ出すことです。

ほとんどのコンピューター プログラマーはコーディングの経験があり、コード内に存在する場合に調べることができる特定のパターンがあります。

コードには、オブジェクト指向と構造指向の 2 種類があります。

両方を行う方法を知っていれば問題ありませんが、どちらか一方に慣れていない場合は、その方法でプログラミングする方法を再学習して、そのようにコーディングされた理由を理解する必要があります。

オブジェクト指向コードでは、各オブジェクト クラスの動作とメソッドを文書化した図を簡単に作成できます。

それが構造的に指向されている場合、つまり関数によって意味されている場合は、各関数の機能とコード内のどこに表示されるかを文書化した関数リストを作成します。

私は web 開発者であるため、index.php から他のページの残りの部分まで、何かがどのように機能するかを理解するのは比較的簡単です。

幸運を。

于 2008-11-04T12:22:43.330 に答える
0

vi および emacs ユーザーができることの 1 つは、タグの使用です。タグはファイルに含まれています (通常は TAGS と呼ばれます)。コマンドで 1 つ以上のタグ ファイルを生成します (emacs の場合は etags、vi の場合は vtags )。次に、ソースコードを編集すると、タグファイルをロードする紛らわしい関数または変数が表示され、関数が宣言されている場所に移動します(十分ではありません)。私は実際に、Alt-cursor を使用してソースをナビゲートできるようにするいくつかのマクロを作成しました。これは、UNIX の多くのフレーバーでの popd や pushd のようなものです。

ババト

于 2008-10-18T07:04:12.803 に答える
0

コードに入る前に最初に行うことは、(必要に応じて複数の異なるユーザーとして) アプリケーションを使用して、すべての機能を理解し、それらがどのように接続されているか (アプリケーション内で情報がどのように流れるか) を確認することです。

その後、アプリケーションが構築されたフレームワークを調べて、いくつかのビューまたは UI コードで今見たすべてのインターフェイス間の直接的な関係を作成できるようにします。

次に、データベースとデータベース コマンド処理レイヤー (該当する場合) を調べて、その情報 (ユーザーが操作するもの) がどのように格納され、アプリケーションとの間でどのようにやり取りされるかを理解します。

最後に、データがどこから来て、どのように表示されるかを学習した後、ビジネス ロジック レイヤーを調べて、データがどのように変換されるかを確認します。

すべてのアプリケーション アーキテクチャはこのように分割でき、実際にデバッグしたり新しいものを追加したりする前に、全体的な機能 (アプリケーションの誰が誰であるか) を知ることが有益であると信じています。

はい、ソフトウェアの現在のバージョンを開発した人と話すことも大いに役立ちます。ただし、彼/彼女がすぐに会社を辞めようとしている場合は、彼/彼女のウィッシュリストにメモしておいてください (プロジェクトのためにやりたかったが、予算の制約のためにできなかったこと)。

于 2008-10-18T08:41:41.953 に答える