依存関係を3種類に分ける

パッケージ依存・呼出し・データ流を整理する

学習時間の目安: 45 分.

1. 1manifest
2. 2宣言されたパッケージ依存

1. 1呼出し箇所
2. 2関数の呼出し

1. 1RPC境界
2. 2プロセス外へ送るデータ

独自の学習図。矢印は読み進める順序や判断の流れを表し、実測した実行traceではない。

前提となる章

1操作を端から端まで追う

この章の状態

本文は資料を読んで作成した教材です。実repoのbuild/test/debug、実API呼出し、Issue/PR投稿は行っていません。実践はこれから行う課題で、閲覧を実行結果と扱いません。

学習目標

• パッケージ依存・呼出し・データ流を整理する

矢印を混ぜない

manifestの依存、関数の呼出し、RPC/データの流れを同じ矢印にすると全体が読めなくなる。5ノード以内から始め、実線は確認済み、点線は仮説にする。直接依存と推移依存、開発用と実行時用も区別する。

黒箱の使い方

CLIがSDKを使っても全APIを読む必要はない。機能に必要な境界だけ囲み、その外は入力・出力を記録する。Spark ConnectとDatabricks ConnectでもOSS基盤と製品向け追加の境界を残す。

影響範囲

公開APIの変更は利用者へ波及する。テスト追加は比較的範囲を絞れるが採用保証ではない。生成ファイルは生成元と再生成手順を確認してから扱う。

実践課題: 依存関係を3種類に分けるの実践

1. ノードを5つまで選ぶ
2. 矢印にimport/呼出し/RPC/データと記す
3. manifestと実装の根拠を保存
4. 1行変更した場合の影響範囲を書く

成果物: 依存図と変更影響メモ

理解チェック

まず答えを見ずに自分の言葉で答えます。以下は自己確認用の正答と説明であり、自動採点・実行結果ではありません。

全依存を理解してから最初の修正？

答え: 対象機能の契約・関連テスト・外部境界を説明できる小さな範囲からでよい。

自分の学習進捗

記録方式: manual.

• 未着手
• 読んだ
• 試した
• 説明できる

閲覧だけで実践済みにしない

この章で使った資料

Bundle実装, databricks/databricks-sdk-go 公式repo, Apache Spark Connect, Databricks Connect

リポジトリの入口へ戻る · 手元の実験記録テンプレート