そうする意味がないのであれば、名前を変えない/増やさない

僕は変数の命名やsnake_case, spinal-caseなどミクロなコーディングルールに拘りがあるのですが、重要としていることの一つに 名前を増やさない ということがあります。この記事ではそれを紹介します。

GitHub ActionsのWorkflowファイルを使った例

.github/workflows/auth-system-terraform-apply.yml

name: terraform-apply

on:
  workflow_dispatch:

jobs:
  auth_system_terraform_apply:
    runs-on: ubuntu-latest
    steps:
      - ...

僕はこういった書き方を理由なくすることはなく、通常以下のように書きます。

.github/workflows/auth-system-terraform-apply.yml

name: auth-system-terraform-apply # terraform-apply でした

on:
  workflow_dispatch:

jobs:
  auth-system-terraform-apply: # auth_system_terraform_apply でした
    runs-on: ubuntu-latest
    steps:
      - ...

何が違うのでしょうか。前者の例だと、yamlファイルのファイル名、workflowのname, jobの名前がすべてバラバラでした。
一方、後者の例だとそのすべてが同じ auth-system-terraform-apply になっています。

この2つの例で何が違うのか

まず、大前提としてそれらの3つは本質的に同じでいいものとします。yamlファイルのファイル名とworkflowのnameを別にする必要があるケースは僕が知る限り無いし、jobもjobの数が1つであるならworkflowの名前と別にする意味はありません。以降、その過程の元で話を進めます。

結論から書くと、本質的に同じでよいものにバラバラの名前をつけるのはよくありません。それは以下のような様々なデメリットが有るためです。

1. (わずかとはいえ) 同じ名前でいいものに別の名前をつけるための思考がもったいない
2. searchability(検索性)を下げる
3. よくにているが別の文字列の並びは認知負荷を上げる(同じであるという認識は微妙に違うことの認識よりだいぶ安い)

また、僕のような名前を注意してつける人間は名前が違うことに対してなぜ違うのか意味を見出そうとします。
例えば、以下のような build-and-deploy というワークフローがあったとします。

.github/workflows/build-and-deploy.yml

name: build-and-deploy

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - ...

このワークフローの定義を読んでいて、最初に見つかったジョブの名前が build である場合、僕はおそらく次のジョブが deploy という名前でありそれぞれのステップでジョブを分けているのだろうと予測します。
しかし、このジョブ名が単に雑に付けただけでdeployもその中でやっているとしたら、せっかくの予想が裏切られることになり、高次で表現できたコードの構造をうっちゃって一行一行コードを読んで全体を把握する必要が出てきます。

まとめ

同じ名前でいいものには極力一文字一句同じ名前をつけましょう^[1]。

スポンサー

この記事はSpeeeでの業務中に30分で書きました。

脚注

1. 僕はtypoを避けるため、同じ名前のときはわざわざ文字列をコピペするぐらいには同じであることを注意しています