🧵 すべてのプログラムの内部情報を画像として出力することで、自分や他の人の生活が少しでも楽になります。✨ スレッド ✨
私が書くほぼすべてのプログラムは、何らかの方法でその内部状態をダンプできます。 このスレッドから皆さんに伝えたいことの一つは、自分のプログラムでも同じようにできるということです。複雑である必要はありません！
こういう意味ではないんです。 ポインタが矢印で示され、NULLを表す小さな記号などがついた、連結リスト形式の図を見たことがあるでしょう。実装について話すときには便利ですが、勉強以外でこれを使う機会は滅多にありません。 クレジット: モーゼス・エフィオン・エクペニョン
ブルックリン カレッジの CISC 3130 のリンク リストの素晴らしい図に感謝します 🚂🚃🚃 出典: https://t.co/VTw0qbKDXA
抽象化レイヤーを上に移動して、ADT のコンテンツを表示することは有用ですか? おそらくそうではないでしょう。プログラムにとってより意味のあるものを、その言葉で示す方が良いでしょう。それは単一のデータ構造の内容である場合もあれば、複数のデータ構造間の関係である場合もあります。
私はコンパイラ関連の作業をたくさんしていますが、この考え方は他の場所にも当てはまります。 コンパイラにフェーズがあるのは、各フェーズの間に異なるデータが存在するためです。そのため、それらをダンプするのは非常に自然なことのように思えます。 CLI ツールにフラグを追加するだけでこれを実現できます。必要なのはこれだけです。
これはUnixシェルの初期段階の構造です。このプログラムは、構文木と階層的なシンボルテーブルの関係を示しています。これらのテーブルは解析中に同時に生成されます。これらの関係がお分かりいただけると思います。
どのように格納されているかではなく、何が含まれているかだけを示しています。これは単に内容を示すだけで、これらの特定のデータ構造の実装については言及していません。これは、プログラムの他の部分をデバッグするための適切な抽象化レベルです。
これは別のプログラムからの別のツリーです。これはCおよびC++コンパイラからのIRです。 この部分自体をデバッグしない限り、実装の詳細は単なるノイズになります。
これらの構造は大きくなる可能性があります。しかし、ズームアウトした場合でも、大まかな形状を把握しておくとデバッグに役立ちます。 物事の見た目を見れば、変化のパターンを見つけることができます。私たちの脳はそういうのに優れているんです！
プログラムの構造化について：データの構造を正しく理解しましょう。コードはそれに付随するものです。 - コードの変更が容易になる - データ設計はあらゆるところに根付いていく - だからこそ、フェーズ（またはモジュールなど）内に収めることが重要だ
ステートフルデーモンの場合、IPC 経由で現在の状態を照会する方法を追加します。 レンダリングはプログラムの外で行ってください。
graphviz、json、シンプルな TSV など、データに最も自然と思われるものを出力します。 *シンプル*な形式で印刷し、外部ツールを使用してレンダリングします。
プログラムがあるからといって、そのプログラムがこれらすべてを担当する必要はありません。分割しましょう！異なる言語を使いましょう。 私はawkを使っています。皆さんは好きな言語を使ってください。
JSONは、異なる言語を使用するチーム間の共通通貨として最適です。商用で作業している場合は、これを社交の場として活用し、「チーム間の連携」を重視するエンジニアとしてポイントを獲得しましょう。
色は色覚異常者にも分かりやすく、機能的な情報のみに使用してください。Bang Wongさんのパレットが気に入っています。 https://t.co/XtUlGdalOb
ワークフローは、データの取得と視覚化の両方において重要です。作成したものを確認するためにたくさんの作業をしなければならず、本来の目的が妨げられてしまうのは良くありません。 次回はそのことについて少し書いてみようと思います。 お気をつけて。読んでくれてありがとう。
