はじめに

これは社内で使っているコーディングのガイドライン（強制ではない）の一部抜粋になります
弊社ではLookerを扱っている方々は必ずしもエンジニア経験があるわけではないが、LookMLのコーディングはプログラミングの要素も含んでいるため、書き方やレビューの観点などをまとめました
社内で作ったものを抜粋とした理由はクラスメソッドさんが公開しているものを盛大にベースにさせていただいている部分があるのでオリジナルの部分だけを公開しようと思いました

Exploreの粒度

リレーションに基づいて汎用的なExploreを一つ作り、小さな表や単項目の値の表示を行うことで再利用性をしやすくする
- このExploreを使っての一覧作成は重いクエリになりがちなので極力避ける
複雑なクエリや一覧表についてはExploreを切り出して実装する
- 汎用的なExploreを作ったとしても一覧や特化した集計を無理に同居させ用とすると定義自体が複雑化するので切り分けて作ることも大切
サービスを横断するような一覧や負荷が大きくなりそうな表示は複雑になりすぎないようExploreを切り出す

カスタムフィールドの使い方

カスタムフィールドって何？

view意外にも数字の集計や計算を行うことができます
- 　カスタムディメンション
  - 発行するSQLのselect句で数字の変換や条件分岐を入れ込むことができる
- 　カスタム測定
  - 発行するSQLの集計関数に対して条件分岐などを追加することができる
- 　表計算
  - 　クエリへの介入がないカラムの作成
    - 　発行されたSQLから取得した内容をさらに計算するカラム

使い所は？

(takasho的には)異なるテーブルのカラムを比較するときなどに使うのがおすすめです
- viewは一つのテーブルのカラムに対しての定義なので無理やり別テーブルの引用するとカオスになる予感なので一旦は単独で動くものを作る方針
  - 多少コード量が増えたとしてもカスタムフィールドを使った方が作りがシンプルにしやすい
- 抽出時にパフォーマンスが気になるけども、、、みたいなことがあればderived tableへ置き換えるというやり方もアリ(SQLでやるのが簡単なだけに同じようなderived table乱立を予防する)

derived tableを作るときの方針

パフォーマンスが必要になるとき
- 全てのテーブルをjoinしてから集計すると計算コストが高くなってしまうので、joinするテーブルを極力小さくしてあげる必要がある
- 今後明らかに増えると予想されるトランザクションデータの場合とかは最初からderived tableを作っておいて良いと考える
  - 例えばログ、サービスのリクエストの回数など、1年後、2年後を考えたときにどれくらいの件数になるかを考えて判断する
- BIツールでよくあるドリルXXみたいな見方に固執しなくて良い
  - ローデータのjoinや集計が容易にできるので結果的に計算コストの高いクエリが作成作成されがちで、レスポンスが遅くなる可能性があるので、BIツールでのメリットみたいなドリルxxみたいなところに固執しすぎないことが重要だとつい最近実感しました
テーブル跨いだ判断を行いたいとき
- カスタムフィールドではdimentionやmesureが違うと比較がしにくく、derived tableにすれば同等の項目として扱うことができ、検索条件として容易に使うことができる
SQLを書くか否か
- 項目の再利用性を考えると極力SQLを書かない方向を目指したい
  - SQLで項目を扱おうとすると改めて同じテーブルをjoinしたり作成したSQLにも同じ項目を実装する必要があり、二重に実装を行うことになる
- 反面、SQLを書いた方が早いケースもあるのは事実なので最終的なメンテナンス性から考えて良いと思うが、まずはviewへの実装可能性を考えるところから始める

レビュー観点

view
- ネーミングがわかりやすいか（命名規則に則っているか）
- 作成されたファイルのディレクトリが適切か
- 継承が深すぎないか
- derived tableにする必要があるか
- derived tableをSQLで定義する必要があるか
- コメントが欲しいか
- 同じことをやっているところがないか
explore
- ネーミングがわかりやすいか（命名規則に則っているか）
- 作成されたファイルのディレクトリが適切か
- exploreの定義先は適切か
- 関連、つなぎ方が正しいか
- joinが適切か
- relationが適切か
- 継承が深すぎないか
- コメントが欲しいか
- 同じことをやっているところがないか

その他

リリース優先にして気になるところは後からリファクタ
レビューはあくまでダブルチェックで、「こう言う書き方もあるよね」っていうスタイルで二人で良いやり方を模索する場
approveにするケース
- 答えが正しくてパフォーマンス懸念くらいならリリースしていいかも
- ネーミングは後から直しても良さそう
- 気になるところはリリース優先にしつつ、リファクタのチケットを切る
rejectにするケース(実際には修正を依頼する場合)
- 要件を満たせていない
- 答えが間違ってそう
- タイポ系
- 他への影響
同じ数値を扱うダッシュボードは、なるべく同じExploreを参照するようにしたい
- Exploreの組み方によって集計結果が変わることがあるので、ガバナンスの観点からまとめたい
- なので、似たようなExploreをfrom句で量産するのも非推奨としたい

スペシャルサンクス

レビューをしてくれた社内のLookerユーザ

参考

LookMLパラメーターリファレンス（機能別）
- https://docs.looker.com/ja/reference/lookml
Lookerベスト・プラクティス：LookML 要素別オススメ開発手法 #looker
- https://dev.classmethod.jp/articles/looker-best-practice-lookml/#lookml-best-practices-naming-convention
プログラミングの変数名、関数名を命名する際に便利なサイト・記事
- https://qiita.com/developer-kikikaikai/items/421d4ab74e161d993074
プログラミングでわかりやすい変数名の決め方
- https://qiita.com/lucky0707/items/47c7d443839076ddd86c