最近はずっと仕事でTerraformを使っている。
今まではJavaとかTypeScriptとか普通の手続き型言語を書いていて、「良いコード」を書くためのマインドセットとして「コードに意思や意図を込める」っていうのを意識してやってきた。
この「コードに意思や意図を込める」っていうのがTerraformというかHCLだと難しいなと感じる。
宣言型の特性、なんだろうか？他の宣言型言語使ったことがないからわからないけども。
Javaとかだと、要件やら設計意図をパッケージやらクラス名やらメソッド名やらで表現できた。
Terraformだとそれがリソース名しかない。もうあとはコメントに書くしかない。
AWSだったらAWSリソースを作成する、っていうユースケース的なものが限定されているものなので、そこまで意図を込める必要性もないのかもしれないけど。
設定値やら構成もなにか要件的な制約や理由があってそうしているはずなんだけどそれをリソース名に持たせるのは酷な話かなと。
だからこそ、「なぜその設定、構成になっているのか？」とか「そもそも何に使われるものなのか？」みたいなものをドキュメントとして残す必要性がJavaとかよりも高いんじゃないかと思っている。
PRにちゃんと書いてればいいんだけどね。「○○の設定値を変更」みたいなコミットメッセージか？というPR出したりしないようにしたいし、できればドキュメントをちゃんと残しておきたい。
現在の設定みたいなものはTerraformのコードそのものが今の設定をそのまま表現しているはずなので詳細設計書的なのは逆に不要だろう。
やらかした時のインパクトというか、不可逆性がインフラの方がありそうだし。
安心安全に修正や改善を行うためにもドキュメントしっかり書くのを意識していきたいよね。
もちろんTerraformじゃなくてもドキュメントはあるに越したことないけど。
Javaとかよりもコードに意思を込めづらい分、設計や要件のドキュメントがより大事なんじゃないかという話でした。
