여러 언어에서 상수를 어떻게 관리해야합니까?

여러 언어로 기능적으로 동일한 라이브러리를 지원하는 상황이 있습니다. 이들 사이에 공유해야하는 상수가 종종 있습니다 (예 : json 필드 이름 키 또는 오류 코드).

현재이 작업을 수행하는 방법은 각 언어의 상수를 정의하는 코드를 작성하는 것입니다.

문제는 유지 보수에 있습니다. 새 오류 코드를 추가하면 모든 라이브러리에서 수동으로 업데이트해야합니다. 이것은 몇 가지로는 괜찮지 만 업데이트 할 SDK 5 개를 말하면 지루합니다. 이것들에 대한 단일 진실 소스를 갖는 것이 좋을 것입니다.

나는 일종의 구성과 같은 파일에 대해 생각했지만 빌드 / 릴리스 프로세스에 복잡성을 더하는 모든 배포 된 패키지에 포함되어야 합니다.

여러 언어간에 공유되는 상수 유지 관리를 처리하는 더 좋은 방법이 있습니까?

귀하의 현재 접근 방식이 아마도 가장 간단하고 간단하다고 생각하지만 몇 가지 대체 아이디어가 있습니다.

• 상수 (및 모델)를 모든 언어로 크로스 컴파일 된 다른 패키지로 추출하십시오. 전체 라이브러리를 크로스 컴파일 할 수 있지만 상당한 문제가 발생할 수 있습니다. 크로스 컴파일 상수는 문제가 없을 정도로 간단해야합니다. 상수 패키지를 게시하고 언어 별 라이브러리에 의존 할 수 있습니다. Haxe 는 아마 그것을 할 수 있습니다. 이 방법은 여전히 ​​컴파일 타임 검사 (컴파일 된 언어의 경우)가 있기 때문에 좋습니다.
• 중앙 서비스에 구성을 저장하십시오. 예를 들어, SOAP 웹 서비스에는 WSDL ( Web Service Description Language )이 있고 REST 서비스에는 서비스 조작 및 메시지를 설명하는 WADL ( Web Application Description Language )이 있습니다. Spring Cloud Config 와 같은 일반적인 중앙 집중식 구성 서비스도 있습니다
• 구성 파일. 이미 제안한 것을 알고 있지만 빌드 / 릴리스 프로세스를 매우 복잡하게 할 필요는 없다고 생각합니다. 구성 파일을 별도의 빌드 프로젝트 (버전을 지정할 수있는)에 배치하십시오. 프로젝트를 모든 언어 별 패키지 리포지토리 (Maven, Nuget, NPM 등)에 게시 한 다음 언어 별 라이브러리에서 패키지에 의존 할 수 있습니다. 이것은 빌드 파이프 라인에 추가 프로젝트를 갖는 것보다 더 복잡하지 않아야합니다.
• RubberDuck이 제안했듯이 코드 생성은 교차 컴파일에 대한 좋은 대안입니다. 공통 구성을 사용하여 각 언어에 대한 상수 정의를 생성 할 수 있습니다.

좋은 질문입니다! 나는 똑같은 문제가 있습니다. 내 상수는 본질적으로 내 응용 프로그램에서 지원되는 언어 및 응용 프로그램의 기능과 관련된 언어에 대한 추가 정보입니다.

불행히도, 내가 찾은 가장 좋은 것은 현재하고있는 것처럼 각 언어에 대한 상수를 단순히 재정의하는 것입니다 (알고 있습니다 .

분명히 그것은 DRY ( WET ?? ) 의 반대이기 때문에 잘못 느낍니다 . 그러나 각 언어에 대해 5-10 분을 재정의하는 것이 실제로 나를 귀찮게하지 않도록 상수가 자주 변경되어야합니다. 하루가 끝나면 공유 구성 또는 코드 생성과 같은 '우아한'솔루션과 관련된 작은 문제를 해결하는 데 몇 시간 또는 며칠이 걸릴 수 있으므로 실제로 얻는 것이 무엇입니까? 문제를 해결하기 위해 추가 노력을 기울일 수있는 문제의 복잡성과 복잡성을 추가 한 것은 내가 다루고 싶은 것이 아닙니다.

또한 응용 프로그램에 상수를 너무 많이 추가하여 언어를 추가하거나 변경할 때 언어마다 재정의하는 데 상당한 시간이 걸리는 경우 처리해야 할 코드 냄새가 더 커질 수 있습니다. 더 복잡한 것에.

한마디로, 각 언어에 대해 그것들을 재정의하는 것이 최선의 해결책이며, 아직 다루고 싶은 것보다 더 큰 위험 요소가없는 DRY는 더 이상 생각하지 않았습니다.

그러나 분명히 해야 할 한 가지는 상수가 일반화되고 언어에 구애받지 않는 방식으로 잘 문서화 되어 있는지 확인하는 것입니다 . 이 문서). 또한 정의를 동기화 할 수있는 메커니즘이 있는지 확인하십시오. 의도적 인 코드 복제로 인한 소량의 심리적 고통을 제외하고는 복제 방법에있어 큰 문제입니다. 그러나 결국 지속적인 변화는 매우 신중 하고 드물게 발생하므로 동기 문제는 본질적으로 없어야합니다.

또한 수년 동안 언어 자체에 상수가 정의 된 동일한 그룹이 작성한 여러 라이브러리의 여러 언어 포트 (현재 라이브러리를 기억하기에는 너무 피곤함)를 보았습니다. 공유 구성, 코드 생성 없음 (Google API 클라이언트 라이브러리 제외 ...하지만 Google은 이러한 복잡성을 감당할 수있는 리소스를 보유하고 있습니다). 그래서 우리는 이것에 벽돌 벽을 쳤다고 생각합니다. 어쩌면 누군가 가이 문제를 해결하기 위해 결국 라이브러리를 만들 것입니다.)

라이브러리의 핵심은 한 언어로 작성되고 다른 라이브러리는 FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface )를 사용 하여 핵심 라이브러리를 호출하기를 바랍니다 . 이것은 상수와 정의를 게시 할 API를 제공하는 중앙 위치를 제공합니다. 이런 식으로 모든 것이 라이브러리 내에 포함되어 있습니다. 나는 이것이 사무엘의 반응에 포함되지 않은 것이므로 이것을 언급하고 있습니다.

사용자 기반의 능력에 달려 있다고 생각합니다. 다른 구성 파일의 전달을 처리 할 수 ​​있습니까? 그들은 새로운 서비스를 설정할 수 있습니까? 내가 지원 한 대다수의 사용자에게는 모든 것이 독립적으로 포함되기를 원합니다. 이런 방식으로 사용자는 그것에 대해 생각할 필요가 없었습니다.