LookML開発ガイドライン（サンプル）

[shinichi_kawaka]

本トピックは、以下のDiscourseの記事を翻訳したものになります。
🇺🇸 Example LookML Development Guidelines

本投稿は、LookML開発ガイドのサンプルとしてご利用いただけるものです。このリストの目的は、新しく設計を行う際の考慮点を提供し、スケーラビリティとモデル開発を容易にするコンポーネントのいくつかをハイライトすることになります。 開発チームにとって有用なパーツを自由にご利用ください。

すべてのLookML開発者は、開発者間での一貫性を確保し、モデルの可読性を向上させるために、以下ののルールに従う必要があります。 これにより、各開発者は、分析機能とキャパシティを継続的に構築しながら、モデルが稼働し続けるようにすることができます。

サマリー:

1. 作成した各ビューの先頭行に名前、作成日、目的を追加する
2. ビューにsub-organization.viewというタイトルを付け、ファイル形式が次のようになるようにします。sub-organization.view_title.view.lkml
3. 名前、作成日、説明を各新規のフィールドに追加する
4. 一回限りやテストフィールドにフラグをたてる
5. 1回限りのビューファイルで1回限りのExploreを整理して非表示にする
6. 全てのLookML警告とエラーをコミット前に解消する
7. 既存の拡張オブジェクトを拡張することを避ける
8. ビュー, Explore、モデルのオーナーを設定する
9. 新規コードのコミット時に、プルリクエストにおいてフィールド、ビューやExploreのオリジナルの作成者（や責任者）をタグ付けする
10. PDTに関して
    *新規で作成されたモデル/ビューファイルは週次のコードレビューセッションにおいてディスカッションされる

1. 作成した各ビューの先頭行に名前、作成日、目的を追加する
私達は特定のファイルの内容がうまく理解できない場合などに、誰に質問できるのかを共有してほしいと思っています。新しいビューファイルを作成するときは、次のスクリーンショットに示すように、ビューファイルの上部に名前、作成日、目的を追加してください。

2. ビューにsub-organization.viewというタイトルを付け、ファイル形式が次のようになるようにします。sub-organization.view_title.view.lkml
ワイルドカードをinclude: sub-organization.*.view.lkmlのように、組織に関連するファイルをだけを含めるように利用できます。次にサンプルを示します：:

marketing.campaigns.view.lkml - マーケティングモデルに利用される
salesforce.leads.view.lkml - 営業モデルまた、salesforceに特化して利用される
dcl.chat_reviews - 品質管理用にサポートモデルで利用される

Looker 6.24からはフォルダ機能が利用できるようになっていますので、フォルダを利用して上記の整理を行うことが現状は可能になっています。

3. 名前、作成日、説明を各新規のフィールドに追加する
各LookMLフィールドには、フィールドのタイトルやラベルがどれほど重要かに関わらず、説明が必要です。 次のように、名前、日付、およびフィールド定義のフィールドの説明を追加してください:

単体のフィールド

フィールドのセット

4. 一回限りやテストフィールドにフラグをたてる
a. _testを追記し、group_label: "Test"を全ての一度限りのフィールドに適用する:

b. 一度限りの派生テーブルに oo_というプレフィックスを追加する

5. 1回限りのビューファイルで1回限りのExploreを整理して非表示にする
1回限りのExploreは、Exploreの所有者が作成した1回限りのビューファイルに存在する必要があります。 1回限りのExploreを作成する場合は、それをより多くのユーザーから非表示にし、プロダクションにコミットするときに、ラベルでそのように示してください。hidden パラメータを使用できます。

6. コミット前に全てのLookML警告とエラーを解消する
良いLookerにする😃 ALL errors and warningsが解決されていることを確認せずにコードをコミットしないでください。 検証とテストを頻繁に行うことで、エラーの原因を簡単に絞り込むことができ、何百ものエラーに悩まされることがなくなります。

7. 既存の継承/拡張されたオブジェクトを格調することを避ける
既存の拡張済みExploreやビューは、デバッグを大変困難にします。モデルをエッシャーの迷路にしないでください。

8. ビュー、探索、モデルの「所有者」を設定する
ビュー、調査、モデルのサイズと複雑さに応じて、所有者を指定します。 質問に応じるだけでなく、ファイルの検証と保守も担当します。

9. 新規コードのコミット時に、プルリクエストにおいてフィールド、ビューやExploreのオリジナルの作成者（や責任者）をタグ付けする
責任者へ変更を通知することで、ポイントを明確にしサジェスチョンの追加やコードのレビューを簡単にします。

10. PDTに関して
PDTの構築が必須の場合、datagroup を作成し、PDTに追加することかを開発リーダーに相談してください。プルリクエスト（PR）に、データグループの作成にメリットがある理由、または特定のデータグループを選択した理由について簡単に説明してください。