コメントのない複雑なプロジェクトがあります。プロジェクトは Java でプログラムされていますが、複数のメイン クラスがあり、テンプレートのように複数の .txt ファイルを使用し、複数の .bat ファイルを使用します。そのプロジェクトにいくつかの変更を加える必要があるため、どこから始めて、どのようにプロジェクトを発見し始めるのかわかりません。
1340 次
11 に答える
6
他の人たちと同じように、これはゆっくりとしたプロセスだと私は言います。
ただし、これを過去に何度も行ってきたので、これが私の方法論です。
コードが満たす要件をできるだけ多く特定します。これにより、より深く見ていくと、なぜ特定の物事がそのようになっているのかについて、いくつかの理由がわかるかもしれません。これらを見つける一般的な方法は、利用可能なテストを探すことです。自動化されたものが最適ですが、通常はコメントと同じくらい欠落しています。
コードへのエントリ ポイントを見つけます。これらは、コードを突き刺して、さまざまな入力がフローにどのように影響するかを確認できる場所を提供します。一般的なエントリ ポイントは、コード ロードの「メイン」タイプの関数、サービス インターフェイス、Web ページのポストバックなどです。
コードを図示します。コードの白黒ボックス画像を作成できるツールを探してください。私にとって、これはかけがえのないものです。私は時折、大きなリストを印刷して、マーカーと定規で攻撃しました。コードフローの（精神的またはその他の賢明な）独自のフローチャートを作成することを目指しています。
上記を (繰り返し) 使用して、発生すると思われるコードへの一連の出力を作成し、これらに、ログ、データ ファイル、データベース書き込みなど、既に知っている可能性のある出力を追加します。
最後に、時間があれば手動テストをいくつか作成しますが、できれば自動テスト ハーネスで上記を確認してください。ここで、コードの詳細を確認するためにデバッガーを使用し始めます。
この方法論は、通常、変更を加える自信を与えてくれます。
これは反復プロセスであり、必要に応じてコードの一部または全体で実行できることに注意してください。私は通常、最初はトップダウンのアプローチを好みます。その後、洞察が得られたら、詳細が圧倒されるまでドリルダウンし、それを繰り返します。しかし、これは私の心がこのように機能しているからです - あなたは違うかもしれません. 幸運を。
于 2010-10-28T20:40:13.370 に答える
3
私は通常、doxygen から始めて、すべての抽出オプション (特に EXTRACT_ALL と EXTRACT_PRIVATE) をオンにし、SOURCE_BROWSER、HAVE_DOT、CALL_GRAPH、および CALLER_GRAPH オプションを有効にします (ドットもインストールする必要があります)。これにより、ソフトウェアがよく見えます。関数ごとに呼び出しが表示され、グラフにリンクされます。ソースもそこからリンクされます。
doxygen は C および C++ を対象としていますが、Java ソースでも動作します (OPTIMIZE_OUTPUT_JAVA オプションを設定します)。
于 2010-10-29T09:04:30.653 に答える
3
メイン Main クラスを見つけます。出発点。クラスとそれらが所有するオブジェクト、およびそれらが参照する外部エンティティの図を描き始めます。論理的な結末が見つかるまで、すべての分岐に従ってください。
私は過去に UML リバース エンジニアリング ツールを使用したことがあり、視覚的なイメージは良いのですが、コードをステップ実行することは、私にとって常に最も困難でありながら最良の方法論でした。
そして、各ピースをステップ実行するときに、独自のコメントを追加できます..
于 2010-10-28T20:02:13.023 に答える
2
変更を開始し、ブレークポイントを設定し、デバッグを開始する必要があると思われる場所に最も近いコードの最初のエントリ ポイントを見つけようとします。ローカル変数の内容を確認し、何が起こっているのかを理解するにつれて、より深く作業を進めてください。次に、作業するコードの領域について基本的な理解ができたら、いくつかの小さな変更をいじり始めます。それについての理解度をテストします。起こっていることを図式化してみてください。自信を持ってそれを行うことができれば、戻ってコードについてさらに学習を続ける必要があるか、それとも、やらなければならないことをやり遂げるのに十分な知識があるかどうかを判断できるようになります。
于 2010-10-28T20:02:49.177 に答える
2
ああ。これを行う迅速な方法はないのではないかと心配しています。1 行 (または 2 行) をコメントアウトします -> テスト -> 何が壊れているかを確認します。また、break ステートメントをあちこちに配置して、デバッガーを実行することもできます。これにより、どのようにしてそこにたどり着いたか (つまり、クラス間の階層が何であるか) がわかります。
元の開発者が、認識してメモできるパターンをいくつか使用したことを願っています。すべてのことをたくさんメモしてください。高レベルの構造を理解することから始めて、そこから作業を進めてください。
物事が何をしているのかを理解せずに無限の時間を費やす準備をしてください.
クライアントと話し、プロジェクトが何のためにあるのか、それが何をするのかを理解するように努めてください。電子メールだけだとしても、誰かがそこにあるものの要件をどこかに入れなければなりませんでした。
于 2010-10-28T20:04:51.573 に答える
0
投稿された回答のほとんどに完全に同意します。
コードをリバース エンジニアリングし、クラス図を作成する開発ツールを使用して、全体像を把握することができます。
次に、忍耐が必要です。しかし、それを乗り越えたとき、あなたはより強く、より賢い開発者になるでしょう...
幸運を！
于 2010-10-28T23:28:12.483 に答える
0
まず、自動化された UML モデリング ツール (Eclipse を使用する場合はプラグインを使用できます) を使用し、さまざまなクラスの UML ダイアグラムの作成を開始して、それらが高レベルでどのように関連しているかを確認し、コードを視覚化します。これは何度も助けられました
于 2010-10-28T19:59:44.717 に答える
0
最初に行うべき最善のことの 1 つは、コードをビルドして実行することです。少し単純に聞こえるかもしれませんが、文書化されていないコードを引き継いだ場合の問題は、それをビルドして実行することさえできないことです。手がかりがいつ始まったのか。
于 2010-10-31T19:31:43.577 に答える
0
ログファイルが生成されている場合は、それを見て開始点 (メインクラス) からの流れを理解してください。それ以外の場合は、フローを理解するためにデバッグ ステートメントを配置します。
于 2010-10-28T20:01:05.683 に答える
0
ええ、それはかなり悪い場所のようですね。
最善の方法は、プログラムの行を 1 行ずつ見ていくことだと思います。コードの全体像を把握するようにして、紙とコードのコメントの両方にたくさんのメモを書いてください。
于 2010-10-28T20:39:25.497 に答える
0
javadoc または doxygen のクラス図機能を使用してドキュメントを生成し、doxygen を使用して生成されたクラス図をたどってコードを実行し、誰が何を呼び出しているかを確認するのが良い方法です。このようなプロジェクトに取り組んでいるときはいつでも、これは私にとって素晴らしく機能します。
于 2010-10-28T23:17:46.350 に答える