複数の言語で定数をどのように管理する必要がありますか？

機能的には複数の言語で同じライブラリをサポートしている状況があります。多くの場合、これらの間で共有する必要がある定数があります（たとえば、jsonフィールド名キーまたはエラーコード）。

私が現在これを行う方法は、各言語の定数を定義するコードを持つことです。

問題はメンテナンスにあります。新しいエラーコードを追加する場合、すべてのライブラリで手動で更新する必要があります。少数の人にとってはこれで問題ありませんが、更新するのに5つのSDKを使用しなければならないのは面倒です。これらについても単一の真実の情報源があると便利です。

ある種のconfig-likeファイルについて考えてきましたが、それはすべてのデプロイされたパッケージに含まれる必要があり、ビルド/リリースプロセスが複雑になります。

複数の言語間で共有される定数のメンテナンスを処理するより良い方法はありますか？

あなたの現在のアプローチはおそらく最も簡単で最も簡単だと思いますが、ここにいくつかの代替案があります。

• すべての言語にクロスコンパイルされた別のパッケージに定数（およびおそらくモデル）を抽出します。ライブラリ全体をクロスコンパイルできる場合もありますが、それにはかなりの量の問題が伴う可能性があります。定数のクロスコンパイルは、問題がそれほど多くない程度に単純でなければなりません。定数パッケージを公開し、言語固有のライブラリでそれを使用できます。Haxeはおそらくそれを行うことができます。コンパイル時のチェック（コンパイルされた言語の場合）がまだあるので、このアプローチは良いです。
• 構成を中央サービスに保存します。たとえば、SOAP WebサービスにはWebサービス記述言語（WSDL）があり、RESTサービスには、サービスの操作とメッセージを記述するWebアプリケーション記述言語（WADL）があります。Spring Cloud Configのような一般的な集中構成サービスもあります
• 構成ファイル。既に提案していることは承知していますが、ビルド/リリースプロセスをそれほど複雑にする必要はないと思います。構成ファイルを別のビルドプロジェクト（バージョン管理できる場所）に配置します。すべての言語固有のパッケージリポジトリ（Maven、Nuget、NPMなど）にプロジェクトを公開し、言語固有のライブラリでパッケージに依存できます。これは、ビルドパイプラインにプロジェクトを追加するよりも複雑ではありません。
• RubberDuckが示唆したように、コード生成はクロスコンパイルの優れた代替手段です。共通の構成を使用して、各言語の定数定義を生成できます。

いい質問です！私はまったく同じ問題を抱えています。私の定数は基本的に、アプリケーションでサポートされている言語と、アプリの機能に関連する言語に関する追加情報です。

残念ながら、（あなたが持っているように）私が見つけた最良のことは、あなたが現在しているように、単に各言語の定数を再定義することです（間違いなく、あなたはそれを聞きたかったのです）。

DRY（WET ??）の反対なので、明らかに間違っているように感じます。ただし、定数はまれにしか変更されないため、言語ごとに5〜10分間定義し直してもそれほど気になりません。結局のところ、共有構成やコード生成などの「エレガントな」ソリューションに関する小さな問題の解決には、数時間から数日かかる可能性があります。修正にさらに労力を要する可能性のある何かがうまくいかないリスクを伴う複雑さを追加したのは、私が対処したいものではありません。

さらに、アプリケーションに非常に多くの定数があり、それらを追加または変更するときに言語ごとに再定義するのにかなりの時間がかかる場合、対処する必要のあるコードの匂いが大きくなる可能性があり、その時点で、より複雑なものに。

要するに、言語ごとにそれらを再定義することが私の最善の解決策であり、私が対処したい以上のリスク要因を持たないDRYについてはまだ考えていません。

ただし、間違いなく行うべきことの1つは、定数が一般化された（および言語に依存しない）方法で文書化されていることを保証することです（仕様、その他のドキュメント、「図面ボード」ドキュメントなどを含む会社ドキュメンタリーリポジトリがあります）このドキュメント）。また、定義の同期を維持するためのメカニズムがあることを確認してください。これは、意図的なコードの重複によるわずかな心理的苦痛を除けば、重複アプローチの問題と同じくらい大きな問題です。しかし、最終的には、絶え間ない変更は非常に意図的で頻繁ではないため、同期の問題は本質的にゼロになります。

また、長年にわたって、言語自体で常に定数が定義されている同じグループによって書かれたさまざまなライブラリの多言語移植版（現時点ではそれらが何であるか思い出せないほど疲れている）を見てきました。共有設定もコード生成もありません（Google APIクライアントライブラリを除く...しかし、今後、Googleにはそのような複雑さを許容するリソースがあります）。だから、私たちはこれにレンガの壁を打ったと思います。たぶん誰かがこの問題に対処するためのライブラリを思い付くでしょう;）

ライブラリのコアが1つの言語で記述され、他のライブラリがFFI（https://en.wikipedia.org/wiki/Foreign_function_interface）を使用してコアライブラリを呼び出すことを願っています。これにより、定数と定義を公開するためのAPIを提供する中心的な場所が得られます。このように、すべてがライブラリ内に自己完結しています。これはサミュエルの応答に含まれていないように見えるため、これについて言及しているだけです。

私はそれが本当にあなたのユーザーベースの能力に依存していると思う 他の構成ファイルの受け渡しを処理できるほど十分ですか？新しいサービスをセットアップできますか？私がサポートした大多数のユーザーにとって、私はすべてが自己完結型であることを望んでいます-このように、ユーザーはそれについて考える必要はないでしょう。