tl;dr
- チームで命名規則を定めたり、維持することには一定のコストが掛かります
- 後で変更することが容易なものには強い命名ルールを定めないようにしましょう
- あとでいい命名規則が見つかったとき、柔軟に変えるのが良いです
詳細
チームで開発していく上で、命名規則を定めることはかなり重要です。
特にインフラに関わる部分では、ドメインなどは変えるのにかなり大きなコストがかかりますし、Terraformで言えば多くの name や id は変更時に破壊的置換が必要になりますので、コストが高いです。
しかし、一方でtagなどは変更時にほとんどコストが掛かりません。
以下に同じ領域で大きく変更コストが異なるものの一例を挙げます。
| 領域 | 変更コストが小さい | 変更コストが大きい |
|---|---|---|
| GitHub Actions | workflowファイル名 ( name さえ同じであればファイル名はほぼノーコスト) |
name(これを変更するとGitHub Acitions画面上での実行ヒストリーの連続性が途切れ、過去の実行が参照しづらくなる。またGitHub Actions一覧上でのジョブの並び順へ影響を与える) |
| Terraform | ファイル名・tfファイル分割 (terraform実行結果にまったく影響を与えない) |
リソースの name や id(変更時にリソースの再作成が必要で、そのリソースが参照されていたりすると再作成はかなり大変) |
重要なのは、個人にしてもチームにしても、ルールを意識し・維持し・日々メンテナンスしていくことにキャパシティを消費することです。その意味で、あとで変更するのが容易な部分についてはそれほど厳密なルールを定めず、気づいたら、もしくは後で揃えたくなったら揃える程度にするのもよいでしょう。
上記の例で言えば、GitHub Actionsのワークフローの name プロパティ にはある程度ルールを置いたほうがよいです。一方でファイル名についてはある程度適当でもあとで git mv がほぼノーコストでできます。
Discussion