[解決済み] 引数渡し戦略 - 環境変数 vs. コマンドライン

質問

私たち開発者が書くアプリケーションのほとんどは、起動時に外部からパラメータを指定する必要があります。ファイル パス、パイプ名、TCP/IP アドレスなどを渡します。これまで私は コマンドライン を使用して、起動するアプリケーションにこれらを渡していました。でコマンドラインをパースする必要がありました。 main でコマンドラインを解析し、引数を必要な場所に誘導しなければなりませんが、これはもちろん 良い設計 ですが、これは メンテナンスが難しい を維持するのは困難です。最近、私は 環境変数 という仕組みを使うことにしました。これらはグローバルでどこからでもアクセス可能であり、それは エレガントではない アーキテクチャの観点からは コードの量を制限する .

これらは両方の戦略に対する私の最初の（そしておそらくかなり浅い）印象ですが、より経験豊富な開発者の意見を聞きたいと思います --。 プロセスに引数を渡すために環境変数とコマンドライン引数を使用することの長所と短所は何ですか？ 私は以下の事柄を考慮したいと思います。

1. 設計品質（柔軟性/保守性）。
2. メモリの制約
3. ソリューションのポータビリティ。

備考

広告 1. これが一番気になる点です。

広告です。2. これは少し現実的な話です。私が知っている Windows での制限事項は、現在 巨大 (コマンドラインと環境ブロックの両方で32kB以上)です。必要なら大量の引数を渡すためにファイルを使用すればいいだけなので、これは問題ではないと思いますけど。

広告です。3. 私はUnixについてほとんど何も知らないので、両方の戦略がWindows上と同様に使用可能であるかどうかはわかりません。もしよろしければ詳しく教えてください。

どのように解決するのですか？

1) 環境変数はなるべく使わないようにすることをお勧めします。

環境変数の長所

• どこからでも見えるので、使いやすい。 多くの独立したプログラムが情報の一部を必要とする場合、このアプローチは全体的に便利です。

環境変数の短所

• どこからでも見える (削除可能、設定可能) ため、正しく使用するのが難しい。 環境変数に依存する新しいプログラムをインストールした場合、既存の環境変数を踏みにじることになるのでしょうか? 昨日、猿のように動き回っていたとき、不注意で環境変数を台無しにしてしまったのでしょうか?

私の意見

• プログラムの個々の呼び出しごとに異なる可能性が最も高い引数 (たとえば、n を計算するプログラムでは n) にはコマンドライン引数を使用します。
• ユーザーが変更したいと思うかもしれないが、それほど頻繁に変更しない引数には設定ファイルを使用する (たとえば、ウィンドウがポップアップするときの表示サイズ)。
• 環境変数は控えめに -- できれば変更されないことが予想される引数のみに使用する (例: Python インタープリタの場所)。
• あなたの言いたいこと They are global and accessible from anywhere, which is less elegant from architectural point of view, but limits the amount of code は、グローバル変数の使用を正当化する理由を思い起こさせます;)

環境変数の使い過ぎの恐ろしさを身をもって体験した私の傷跡

• 仕事で必要な 2 つのプログラムが、環境の衝突のために同じコンピューターで同時に実行できません。
• 同じ名前で異なるバグを持つ複数のバージョンのプログラム。プログラムの場所が環境から取得され、 (静かに、微妙に) 間違っていたため、ワークショップ全体が何時間も屈服することになった。

2) 制限

もし私がコマンドラインが保持できるもの、あるいは環境が処理できるものの限界に挑戦しているのであれば、すぐにリファクタリングするでしょう。

私は過去に、多くのパラメータを必要とするコマンドラインアプリケーションのためにJSONを使用したことがあります。 文字列や数値と一緒に、辞書やリストを使用できるのは非常に便利でした。 そのアプリケーションは 2 つのコマンド ライン引数を取るだけで、そのうちの 1 つは JSON ファイルの場所でした。

この方法の利点

• CLI ライブラリと対話するために多くの (苦痛な) コードを書く必要がなかった -- 一般的なライブラリの多くに複雑な制約を強制させるのは苦痛です (「複雑な」というのは、特定のキーまたは一連のキー間の交替をチェックするより複雑であるということです)。
• 引数の順序に関するCLIライブラリの要件について心配する必要はありません -- JSONオブジェクトを使用するだけです!
• 複雑なデータを簡単に表現できる (回答 What won't fit into command line parameters? のような複雑なデータを表現しやすい。
• 他のアプリケーションからのデータを簡単に利用できる -- プログラム的に作成することも解析することもできる
• 将来の拡張に対応しやすい

ノート : 私はこれを.config-fileアプローチと区別したい--これはユーザーの設定を保存するためのものではないのだ。 私はこれを「コマンドラインパラメータファイル」アプローチと呼ぶべきかもしれません。なぜなら、私はコマンドライン上にうまく収まらない多くの値を必要とするプログラムのためにこれを使うからです。

3) ソリューションの移植性。 環境変数やコマンド ライン引数に関する Mac、PC、Linux の違いについて詳しくは知りませんが、言えることはあります。

• はすべて環境変数をサポートしています。
• いずれもコマンドライン引数をサポートしています。

はい、わかっています -- あまり役に立ちませんでしたね。 申し訳ありません。 しかし、重要なポイントは、あなたが ができる 合理的なソリューションが移植可能であることを期待できるということです。 わかりません）。

最後にもう一点。

Tomaszが言及したように、パラメータがどこから来たかはアプリケーションの大部分にとって重要ではないはずです。