残念なことに、非常に古く、文書化も不十分 で、設計も不十分なコードを変更しなければならないことがあります。
既存のコードにはあまり構造がないため、簡単な変更を行うには長い時間がかかることが多く、実際に多くのコードを読まないと、どこに何が起こるかを感じることができません。
このような場合に大いに役立つと思うのは、コードの概要を視覚化し、さらに詳細にドリルダウンすることさえできるツールです。ほとんどまたはまったくない構造を見つけようとしていることを考えると、そのようなツールを正しくするのは非常に難しいと思います。
これは質問ではなく、ただの思い込みだと思います。私はそれを質問にすべきです -他の人々のコード、良い面と悪い面を理解するのを助けるために他の人は何をしますか?
うーん、これは難しい問題です。多くのことを話すには時間がかかりません...
1）コードを実行できれば、人生はずっと楽になります。ブレークポイント（特に条件付き）ブレークポイントはあなたの友達です。
2）純粋主義者のアプローチは、既知の機能に対していくつかの単体テストを作成し、コードと理解を改善するためにリファクタリングしてから、再テストすることです。問題が発生した場合は、さらに単体テストを作成します - 退屈/古い/新しいプロジェクトに移動するまで繰り返します
3) ReSharper は、どこで使用されているか、たとえば何がメソッドを呼び出しているかを示すのが得意です。これは静的ですが、良いスタートであり、リファクタリングに役立ちます。
4) 多くの .net イベントはパブリックとしてコード化されており、イベントは最適な時期にデバッグするのが面倒な場合があります。それらをプライベートに再コーディングし、追加/削除でプロパティを使用します。その後、ブレークポイントを使用して、イベントでリッスンしているものを確認できます。
ところで - 私は .Net スペースで遊んでいます。ジョエルのように、この種の作業を支援するツールが欲しいのですが、優れた動的コード レビュー ツールを知っている人はいますか?
私は過去にいくつかのNASTYコードの所有権を取得するように求められました - 仕事と「遊び」の両方.
私がコードを引き継いだアマチュアのほとんどは、数回の反復で必要なことを実行するためにコードを進化させただけでした。それは常に、ライブラリ A が B を呼び出し、A を呼び戻し、C を呼び出し、B を呼び出すなどの巨大な近親相姦の混乱でした。多くの場合、彼らはスレッドを使用し、クリティカル セクションは見られませんでした。
コードのハンドルを取得する最善/唯一の方法は、OS エントリ ポイント [main()] から開始し、コール ツリーを示す独自のコール スタック図を作成することであることがわかりました。最初から完全なツリーを構築する必要はありません。各段階で作業しているセクションをトレースするだけで、それを実行できるように十分に処理できます。
それをすべて締めくくるには、見つけることができる最大の枯れ木のスライスとペンを使用してください. 画面やページを前後にジャンプする必要がないように、すべてを目の前に配置することで、生活が非常に簡単になります.
編集:コーディング標準については多くの話があります...それらは、悪いコードを良いコードと一貫して見せるだけです(通常、見つけにくくなります)。コーディング標準によって常にコードの保守が容易になるとは限りません。
私は定期的にこれを行います。そして、いくつかのツールとトリックを開発しました。
これに関する問題は、ほとんどの企業で結果によって評価されることです。そのため、貧弱なコードをすぐに書き、別のプロジェクトに移るプログラマーもいます。だからあなたはゴミを残され、あなたの上司はあなたの進歩の遅さを速くて汚い男と比較します. （幸いなことに、私の現在の雇用主は異なります）。
私は通常、コンポーネントが使用されるさまざまな主要な方法の UML シーケンス図を使用します。それらを自動的に生成できるツールは知りませんが、BoUML や EA Sparx などの多くの UML ツールは、ソース コードからクラス/操作を作成できるため、入力の手間が省けます。
貧しいもの全体に走り書きできることは、私にとって最も便利な方法です。通常、私は基本的なコード構造図を作成しようとしているときに、多くの「ええと、それは面白いです...」を見つけます。これは、最終的には図自体よりも便利であることがわかります。自動化されたツールは、私が称賛するよりもおそらく役立つでしょうが、それらの面白いビットを見つけることの価値は、私にとって急速に生成される図の価値を超えています。
ダイアグラムについては、主にデータの行き先を探します。それはどこから入り、どこで終わり、途中で何を通過するのでしょうか。一般的に、データに何が起こるかは、全体的なレイアウトの良い印象を与えるようであり、私が書き直している場合に戻るべきいくつかの骨があります。
BOUMLを強くお勧めします。これは無料の UML モデリング ツールで、次の機能を備えています。
つまり、コードを BOUML にインポートしてそこで表示するか、SVG にエクスポートして Firefox で表示します。
単体テストによってレガシー アプリを把握するためのアドバイスについては、 「レガシー ASP.NET Web フォーム アプリケーションの単体テスト」を参照してください。
似たような質問と回答がたくさんあります。これが検索です https://stackoverflow.com/search?q=unit+test+legacy
要点は、そのレガシーの単体テストを作成している場合、レガシーを理解するのがおそらく最も簡単だということです。
よく文書化されていない/実行されていないコードのレビューを自動化するためのツールをうまく利用できませんでした.混乱した/不適切に設計されたプログラムは、一般的に有用なモデルに変換されません. エキサイティングでもすぐにやりがいがあるわけでもありませんが、スポットを選んでプログラムの実行を 1 行ずつ追跡し、文書化してコメントを追加し、必要に応じてリファクタリングすることで、最高の結果が得られました。
多くの場合、優れた IDE (EMACS または Eclipse) が役に立ちます。また、UNIX プラットフォームでは、相互参照 (etags、ctags) またはチェック (lint) または多くの警告オプションがオンになっている gcc のためのツールがいくつかあります。
まず、関数/メソッドを理解しようとする前に、コーディング規則 (スペース、中括弧、インデント) に合わせて少しリファクタリングし、コメントが間違っていると思われる場合はほとんどを削除します。
次に、理解した部分をリファクタリングしてコメントし、ソース ツリー全体でそれらの部分を検索/grepして、そこでもリファクタリングします。
時間が経つにつれて、より良いコードが得られ、使いたくなるでしょう。
レガシー コードに取り組んでいるときは、システム全体を理解しようとはしません。それは、複雑性の過負荷とそれに続く脳の爆発につながります。
むしろ、私はシステムの 1 つの機能を取り上げ、それがどのように機能するかを端から端まで完全に理解しようとします。通常は、特定の機能を見つけることができる UI コードのポイントから始めて、コードにデバッグします (通常、これは最初に見つけることができる唯一のものであるため)。次に、GUI で何らかのアクションを実行し、コードをデータベースまでドリルダウンしてからバックアップします。これにより、通常、システムの少なくとも 1 つの機能を完全に理解することができ、システムの他の部分についても理解できる場合があります。
どの関数が呼び出され、どのストアド プロシージャ、テーブル、およびビューが関与しているかを理解したら、コードを検索して、アプリケーションの他のどの部分がこれらの同じ関数/プロシージャに依存しているかを調べます。これは、私が行おうとしている変更がシステム内の他の何かを破壊するかどうかを調べる方法です.
データベースおよび/またはコード構造の図を作成することも役立つ場合がありますが、システム全体を無視して、必要な部分だけに集中する方が良い場合もあります。変化する。
私の大きな問題は、私は（現在）非常に短い時間で理解する必要のある非常に大きなシステムを持っており（この点について契約開発者に同情します）、これを行う経験があまりないことです（以前は幸運にもそうすることができました）ゼロから設計するもの。)
私が使用する 1 つの方法は、変数、メソッド、クラスなどの命名の意味を理解しようとすることです。これは、原子レベルからの一連の思考のハイレベルなビューを (できればますます) 埋め込むため、便利です。
私がこれを言うのは、通常、開発者は要素に (彼らが信じているもので) 意味のある名前を付け、意図した機能への洞察を提供するからです。確かに、開発者が自分のプログラム、用語、または (多くの場合、私見ですが) 巧妙に聞こえようとしていることに欠陥がある場合、これには欠陥があります。キーワードやクラス名を見て、その用語を初めて辞書で調べた開発者はどれくらいいるでしょうか?
会社が使用している標準とコーディング規則がすべてです。
誰もが異なるスタイルでコーディングしている場合、他のプログラマーコードなどを維持するのは困難です。使用する標準にいくつかのルールがあると判断した場合、すべてがうまくいくでしょう:)注:たくさん作る必要はありません:)なぜなら、人々は自分の好きなスタイルでコーディングできるはずだからです。