AWSのアカウント名やGoogle Cloudのプロジェクト名、その中で作成するリソース名などの命名規則は簡単でもいいから最初に決めておくとよさそう。特にprefixとsuffixについてはそろえておくと後々困りにくくなるんじゃないか、とはいえ経験したことが無いとプロダクト開発の一番最初にそこまで考えることもなかなかないかも、という話。
何かを自動化しようとした時、対象のリソース名を生成することはよくある。Production、Staging、Developmentなどの環境があるとき、その環境を識別するためにこの時、命名規則がなくバラバラだとちょっとだけややこしいコードになる。
例えば、全環境でProduction/Staging/Developmentを識別するSuffixがつけられている場合、 `foobar_${env}` のように素直にリソース名を生成できる。ここで、ProductionとStagingにはSuffixがなく、DevelopmentにだけSuffixがある場合は環境によってSuffixをつけるかつけないかの条件分岐が必要となり、少しだけややこしいコードになる。
他にもある。S3バケットのようなリソースに名前をつける際、あるバケット名は `foobar_${env}` なのに他のバケット名は `${env}_hoge` だったりすると、自動化しにくい。
さらに、あるリソースではsuffxに `prod` を使っているのに別のリソースでは `production` や `prd` を使っていたりすると、これまた自動化しにくい。
プロダクト名をprefixに、環境名(prod/stg/dev/testなど)をsuffixにする、という簡単なものでもいいから決めてそれを守っておくと後々ちょっと楽になるかもしれない。
とはいえ、動くプロダクトをまずは作って売るぞ！というような一番最初にどこまで命名規則を意識できるのか、筆者には経験がないので分からない。一度経験すればその後は意識するとは思う。後、命名規則を決めてもクラウド側の文字数制限や使える文字の制限で決めた規則が使えない、ということもあると思う。可能な限り守って、どうしても遵守できない場合はちょっと規則から外れることもやむなしなのかもしれない。
