ハロー！わおわお🤗！プロレタリアプログラマー人間だよぉ！みんなからはプロプロ人って呼ばれて疎まれているさ！

今日はどうしたの？なんで生まれて来たの？

…

あ、まだプログラマーやってんの。かわいそっ🤤🥺🥺😊😊

そっかぁーー。まだ苦しみたいんだぁ。人それぞれでいいよね💕💕。じゃあ折角だし今日は構成の話でも聞いていきなよ！チェケダァウ！🫠🙃🫠🙃🫠🤟

◆まえがき

プログラム書いてご飯を食べていく人生を歩むんなら「構成（Configuration）」という概念を知っておくと有利。有利なので覚えておいてください。できたら愛してください。僕の肩で羽を休めておくれ。

俺は今まで構成について語られている技術の文章を読んだことがないゆえ、以下には個人的な理解を書いているのみ。ヨソでは通用しないので注意しておくれ。冷たい水をください。

今回の話は地味。ピンとくるためには練度が必要であるからザコが読んでもそんなに楽しくないかも。

◆構成

構成は、プログラムを実行しているときに読める情報の一種である。その構成という情報ソースについて考えたい。

構成は

  • いわゆるデータではない
    • 動的に書き換えない
    • マスタデータでもない
  • ソースコードに記述されない
  • グローバルアクセスできる

を満たす外部情報を指す。俺の中では。

代表的な構成で言えば、外部接続先の情報。HTTPサーバーのアドレスとかタイムアウトの設定とかSQL Serverの接続文字列とか。

構成というパターンについて理解しておくと、システム組むうえで何をどこに収めりゃいいんだか即断できたりして幸せ。

◆データじゃないってなんだよ

構成はデータとしての性質を欠くことができる。構成はコードに注入される情報の一種。データというものの細かい説明は今はしたくないんで、データベースに入っていたらデータっていうことにしておこうや。

注入っていう語彙を使ったけど、それも俺が言ってるだけなんでヨソでは通用しない。「依存性の注入（Dependency Injection）」という用語から表現を拝借している。

データベースに格納したデータはCRUD出来る。すなわちCreate、Read、Update、Delete。かたや構成はReadのみ可能。

いましがた「構成はReadできる」と書いたが、少し語弊あります。プログラムにReadするためのコードを書いて適時構成を読むというか、プログラムに構成情報を注入して動作させるイメージで捉えるのが正解。

構成の考え方を持っていない人間にコードを書かせると、構成をRDBに格納し始める。それは違うというのを伝えたくてこんなくだらん記事を書いている秋です。

構成はテキストファイルとして存在していがち。構成は飽くまでパターンでしかないから、お前の得意な処理系にConfigurationの概念を扱える仕組みが用意されているかどうかは分からない。言語名 + Configurationとかって検索すればいいよ。

▼マスターデータでもない

構成は、実行時にそれを読んでプログラムの動作を調整するため利用される。だからマスタデータとも異なる。例えば画面に表示するメッセージだとか通信内容に含まれる情報は構成として扱うべきではない。ビジネスロジックの動きを変えるために参照される静的情報は構成じゃない。そりゃマスタデータです。

ただし、開発環境と本番環境でアプリケーションの背景色や表示文字を変えたいみたいなケースでは構成に記述する。

◆コードに記述されない

構成にあたる情報はハードコーディングされない。マジックナンバーとしてベタ書きされない。

コードに書いちゃったら構成と呼びたくない。それを構成と呼びたいんなら外だししろ。

デバッグ時の動作を調整したくて「isDebug」とかって変数を宣言しておいて手でtrue/falseを書き換えたするのも構成を使えていない例。

◆構成の便利さ

▼ビルド結果に埋め込めちゃう

構成がテキストファイルとして存在しているとき、その内容はソースコードをビルドするときに埋め込むこともできる。実行中に変更されないから。かたや設定（Setting）はコード実行時にも並行してテキストファイルやら存在していることが多い。設定はコード実行時の入力により上書きされることもある。わかりやすいところで言えばゲームの音量設定とか画質設定とかだろうか。

構成（Configuration）と設定（Setting）については文脈によって指してるもの違ったりもするから注意されたし。

構成情報を埋め込むビルド戦略をとった場合、構成情報を変えるためにはリビルドせねばならなくなる。リビルドしたくないときは埋め込んじゃいけない。

プログラムの実行時に読まれる構成もあれば、ビルド構成というのもある。ビルドするときに使用する構成。ビルド変数とか呼ばれることもある。

▼差し替え

構成を記述したファイルに「env」と言う名前を付ける文化があったりする。これは構成の差し替え可能性と関係している。

envは即ちenvironment、環境を意味している。コードの実行環境を構成するための情報をenvと呼ぶことありけり。環境変数という言葉を聞いたことがあるかもね。

構成を環境変数（env）と呼ぶのは、サーバーフレームワークとかOSとかコンテナ技術の界隈に多い。npmでenvって語彙が使用されるのは、元のNode.jsがJavaScriptの実行環境だから。ただ、その実行環境全体に及ばない構成情報もenvって呼んでたりするんで微妙。

構成は差し替えることが出来る。構成ファイルを複数用意しておけば、差し替えて動作を変えることができる。構成情報をテキストファイル等に持たずハードコーディングしていた場合は、コードまで書き換えてリビルドせねばならない。編集箇所が複数に及ぶと切り替えが面倒だし書き換え忘れもありうる。書き換える前の構成情報を残したくてコメントアウトしたりするのも無様。

構成をテキストにしておけば複製して新しい構成を作ることもできるしgit管理もできますわね。

◆リモートに構成を配置する

クラウドの時代でありますから、構成もクラウドに乗せちゃえる。

GCPには似たもの無いんかな。少し探したんだけど見つからなかった。

ドキュメントを読めばわかるんだけど便利。バージョン管理できたり複数のリソースから同じ情報を間違いなく参照できたり。

「リモートに配置された構成を読むための構成情報」はテキストで持たねばならんでしょうな。

◆シークレット

データベースへの接続文字列とかは構成にそのまま書くとセキュリティがおまんこになっちゃう。シークレットはシークレットを書くための場所に書いてください。

構成管理とシークレット管理は統合されていたりする。

初見では認証まわりでハマるかもしれんけど仕掛けが分かれば難しいことは無い。

◆結

構成ってそんな感じ。何かしらの気づきを得られたんなら幸甚に存じます。

構成をデータベースに書いたらダメと言うこともない。汎用データベースに乗せるべきでないというベストプラクティスを自覚できていればいい。構成情報は適切なソースに適切な粒度で配置しつつ、ただそこに一握り残った僕の思いをすくい上げて心の隅において。みたいな。