アイデアメモ: 設定ファイルでゴロゴリ弄(維持)れるアーキテクチャを考える際のポイント

本書では「プログラムの動作環境についても設定ファイルで選択できるようにしておくべきだ」と主張しています。

自分は急いでいると、ついプログラムコードとビジネスロジックが分別されていないコードを書きがちです。これまでは「それでも動くんだからいいじゃないか」と思っていましたが、本書を読んで反省しました。しかも今の自分が直面している課題に響く内容だったのでかなり考えさせられました。

以下は、設定とコードを分離する方向で設計を考えるために思ったことになります。

設定のレイヤーを分ける

プログラマーが提供するコード層が1枚あって、あとはユーザ(これにはプログラマ自身も含まれる)が編集できる設定層が1枚、という単純な切り分けを想定します。つまり、実行ファイルが1つあって、細かいチューニングは全て引数で指定というような場合です。

ものすごく単純なコマンドラインプログラムなどはこのタイプに当てはまることが多いと思います。
ただ業務用のシステムでビジネスロジックや外部サービス(APIなど)の変更に常にさらされているプログラム群はもう少し事情が複雑になります。

このような場合、少なくとも以下のように複数のレイヤーに分けて開発する必要性を感じています。

ビジネスロジックから導かれる設定値を入力したり、ユーザのプラットフォームを選択したりするための設定ファイル(設定画面) == 表層
プログラムをプログラムする設定ファイルやコードジェネレータ == 中間層
最終的には抽象的な構造を持つプログラムがサービスを実行する == 深層

上記のようなレイヤーの分割方法は、例えば、次のようなアーキテクチャに反映できます。

レイヤー	中身
表層	ブラウザなどに設定用の画面を表示し、ユーザに値を入力してもらう
中間層1	ユーザの入力値とコードの動作を紐付けるための設定ファイル(TOML/INI/JSON/CSVなど)
中間層2	設定ファイルと実行ファイル呼び出しを紐付けるスクリプト(シェルスクリプトなど)
深層	実行ファイル(バイナリー/Pythonなどのスクリプト)が与えられた設定ファイルや引数を元にサービスを実行

時間的に余裕がなかったり仕事への理解が浅かったりすると、中間層でやるべきことを深層(または表層)に無理やり寄せて作ってしまうことがあります。自分はこのパターンに陥りがちです。
サービス全体としてはひとまず動くので安心してしまいます。しかし、この後、振り返りを忘れてしまう怠慢な状態になるとメンテの機会が訪れた段階になって頭を抱えるわけです。
なお、自分の経験では上記のようなレイヤーの切り分け「だけ」ではメンテナンス性の向上には限界があると考えています。
この問題を解決するには同時にプログラムコードや設定値同士の直交性を確保する必要があります。
直交性とは大雑把に言えば「お互いの依存度が最小限になるように部品を作る」という意味です。

メモのメモ

以下はアイデアをまとめ中のメモです。

全部やろうとしない。全てをカバーできることを前提/目標にしていては何も進まない。
バイナリや設定ファイルの管理/維持/バックアップについての戦略

これらについては考えがまとまったらまた書きます。