Webから情報をマイニングするためのツールを構築しています。いくつかの作品があります。
問題は、問題のトラブルシューティングと、各段階で何が起こっているのかを「高レベルで把握」することです。
複雑なプロセスを理解して管理するのにどのようなテクニックが役立ちましたか？
相互作用する多くのコンポーネントを備えたシステムをどのように処理するのか興味があります。ソースコードをトレースするよりも高いレベルでシステムがどのように機能するかを文書化/理解したいと思います。
私はAT＆Tの有名なGraphvizを使用しています。これはシンプルで、うまく機能します。Doxygenが使用しているのと同じライブラリです。
また、少し努力すれば、非常に見栄えの良いグラフを作成できます。
言及するのを忘れて、私がそれを使用する方法は次のとおりです（GraphvizはGraphvizスクリプトを解析するため）、私は別のシステムを使用してGraphviz形式でイベントをログに記録するので、Logsファイルを解析して素敵なグラフを取得します。
コードは、各段階で何が起こるかを示しています。DSLを使用することは有益ですが、独自のスクリプト言語やコンパイラを作成するという犠牲を払う場合はそうではないかもしれません。
高レベルのドキュメントには、各ステップで何が起こるかの詳細を含めるべきではありません。手順の概要と、それらがどのように相互に関連しているかを提供する必要があります。
良いヒント：
実際に使用しない限り、コマンドラインツールを作成することはお勧めしません。使用しないツールをメンテナンスする必要はありません。（これは、役に立たないと言っているのと同じではありませんが、ほとんどの場合、外部プロセスを実行するのではなく、ライブラリに属しているように聞こえます）。
私の会社は、主要なコンポーネントごとに機能仕様を作成しています。各仕様は共通の形式に従い、必要に応じてさまざまな図や写真を使用します。私たちのスペックには、機能的な部分と技術的な部分があります。機能部分は、コンポーネントが高レベルで何をするか（なぜ、どの目標を解決するか、何をしないか、何と相互作用するか、関連する外部ドキュメントなど）を記述します。技術的な部分では、コンポーネントの最も重要なクラスと高レベルのデザインパターンについて説明します。
テキストは最も用途が広く、更新が簡単なため、私たちはテキストを好みます。これは大きな問題です。VisioやDiaの専門家（またはまともな人）であるとは限りません。これは、ドキュメントを最新の状態に保つ上での障害となる可能性があります。仕様はwikiに記述しているため、各仕様間（および変更の追跡）を簡単にリンクでき、システム内を非線形に歩くことができます。
依存関係構造マトリックスは、アプリケーションの構造を分析するのに役立つ方法だと思います。lattixのようなツールが役立ちます。
プラットフォームとツールチェーンによっては、アプリケーションのサブシステムまたはコンポーネント間の関係を文書化するのに役立つ非常に便利な静的分析パッケージが多数あります。.NET プラットフォームの場合、NDependが良い例です。ただし、他のプラットフォーム用には他にもたくさんあります。
システムを構築する前に優れた設計またはモデルを用意することは、アプリケーションをどのように構築する必要があるかをチームが理解するための最良の方法ですが、前述のようなツールは、アーキテクチャ ルールを適用するのに役立ち、多くの場合、設計に関する洞察を得ることができます。コードをトロールすることはできません。
あなたが言及したツールのいずれも使用しません。
大まかな図を描く必要があります (私は鉛筆と紙が好きです)。
さまざまなモジュールがさまざまなことを行うシステムを設計します。これを設計して、すべてのモジュールの多くのインスタンスを並行して実行できるようにすることは価値があります。
複数のキューを使用することを検討します
キューからデータを読み取り、データを 1 つ以上のキューに挿入する単純な (おそらく UI のないコマンドライン) プログラムを用意します (クローラーは、 「クロールする URL」 と「Web からクロールされたページ」の両方をフィードします) 。 、次を使用できます。
これらはキュー間に収まり、これらの多くのコピーを別々の PC で実行できるため、これをスケーリングできます。
最後のキューは、実際に使用するためにデータベースにすべてを実際にポストする別のプログラムに供給される可能性があります。
これらのコンポーネントをソフトウェア開発ライフ サイクル全体 (設計時、開発時、テスト、リリース、実行時) で分割することが重要です。図を描くだけでは不十分です。
私は、マイクロカーネル アーキテクチャを採用すると、この複雑さを「分割して征服」するのに本当に役立つことを発見しました。マイクロカーネル アーキテクチャの本質は次のとおりです。
以下を使用して、あなたのシステムに似たかなり複雑なバッチ処理システムを作成しました。
各コンポーネントは .NET 実行可能ファイルにマップされます 実行可能ファイルの有効期間は Autosys によって管理されます (すべて同じマシン上にあります) 通信は TIBCO Rendezvous によって行われます
実行時のイントロスペクションを提供するツールキットを使用できれば、なおさらです。たとえば、Autosys を使用すると実行中のプロセスや発生したエラーを確認でき、TIBCO を使用すると実行時にメッセージ キューを調べることができます。
NDepend を使用して、複雑な .NET コード ベースをリバース エンジニアリングするのが好きです。このツールには、次のようないくつかの優れた視覚化機能が付属しています。
依存関係グラフ:
依存関係マトリックス:
ツリーマッピングによるコード メトリックの視覚化:
トップダウン設計は非常に役立ちます。私が見た間違いの 1 つは、トップダウンのデザインを神聖なものにすることです。コードの他のセクションと同様に、最上位の設計を確認して更新する必要があります。