何か分からないことがあって社内のドキュメントを調べたり人に聞いたりして回答を得た時、回答をもらって満足するのではなく一次情報を確認しておくといい。
例えば、AWSやGooge Cloudの設定や挙動のようなものだと、そもそもドキュメントに書かれていることや人の回答が本当に正しいのか分からない。現在だと変わっているかもしれないし、勘違いなどで誤った解答をもらっているかもしれない。誤りの内容によっては大きな問題になる可能性がある。一次情報を確認しておくことで、それらに気づくことができるのでお得。
また、一次情報を一度確認しておけば、その後も自分で確認できるのもお得である。一度調べたことは大体二度、三度と調べる（僕だけかもしれない）ので、調べ方を憶えておけば確認したくなった時に人に聞かず自分で確認できるし、誰かに聞かれた時も「こうやって確認できますよ」というふうに確認の仕方を教えることもできるようになる。
自分も完全にできているわけではなく、人から聞いてフーンとなって終わることも多いし、時間がないと調べずに終わることも多いのだが、意識したいと思っているので書いた。
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にする、という簡単なものでもいいから決めてそれを守っておくと後々ちょっと楽になるかもしれない。
とはいえ、動くプロダクトをまずは作って売るぞ！というような一番最初にどこまで命名規則を意識できるのか、筆者には経験がないので分からない。一度経験すればその後は意識するとは思う。後、命名規則を決めてもクラウド側の文字数制限や使える文字の制限で決めた規則が使えない、ということもあると思う。可能な限り守って、どうしても遵守できない場合はちょっと規則から外れることもやむなしなのかもしれない。
