Как управлять константами в разных языках?

У меня есть ситуация, когда я поддерживаю то, что функционально является одной библиотекой на нескольких языках. Часто между ними есть общие константы (например, ключи имен полей json или коды ошибок).

В настоящее время я делаю это с помощью кода, определяющего константы в каждом языке.

Проблема заключается в обслуживании. Если я добавляю новый код ошибки, мне нужно обновить его в каждой библиотеке вручную. В то время как это хорошо для некоторых, это становится утомительным, если я скажу 5 SDK для обновления. Было бы неплохо иметь хоть один источник правды для них.

Я думал о каком-то конфигурационном файле, но он должен быть включен в каждый развернутый пакет, что усложняет процесс сборки / выпуска.

Есть ли лучший способ обработки констант, которые совместно используются несколькими языками?

Хотя я думаю, что ваш нынешний подход, вероятно, является самым простым и простым, вот пара альтернативных идей:

• Извлеките ваши константы (и, возможно, модели) в другой пакет, который кросс-компилируется для всех ваших языков. Возможно, вы сможете кросс-компилировать всю библиотеку, но это может привести к значительному количеству проблем. Просто кросс-компиляция констант должна быть достаточно простой, чтобы не было столько проблем. Вы можете опубликовать свой пакет констант и зависеть от него в своих языковых библиотеках. Хэкс, вероятно, может сделать это. Этот подход хорош, потому что у вас все еще будет проверка во время компиляции (для скомпилированных языков)
• Храните конфигурацию в центральной службе. Например, мыльные веб-службы имеют язык описания веб-служб (WSDL), а службы REST имеют язык описания веб-приложений (WADL), который описывает операции и сообщения службы. Существуют также общие сервисы централизованной конфигурации, такие как Spring Cloud Config.
• Конфиг файл. Я знаю, что вы уже предложили это, но я не думаю, что это должно сильно усложнить процесс сборки / выпуска. Поместите ваш конфигурационный файл в отдельный проект сборки (где вы можете установить его версию). Опубликуйте проект во всех языковых репозиториях пакетов (Maven, Nuget, NPM и т. Д.), А затем в своих языковых библиотеках вы можете зависеть от пакета. Это не должно быть сложнее, чем иметь дополнительный проект в конвейере сборки.
• Как предложил RubberDuck, генерация кода является хорошей альтернативой кросс-компиляции. Вы можете генерировать постоянные определения для каждого языка, используя общую конфигурацию.

Отличный вопрос! У меня точно такая же проблема; мои константы по существу: какие языки поддерживаются в моих приложениях, а также дополнительную информацию об этих языках, поскольку они относятся к функциональности в приложении.

К сожалению, лучшее, что я нашел (как и у вас), - это просто переопределить константы для каждого языка, как вы это делаете в настоящее время (я знаю, вы определенно хотели это услышать ).

Очевидно, что это неправильно, потому что это противоположно СУХОЙ ( ВЛАЖНОЙ ?? ). Однако константы должны меняться так редко, чтобы 5-10 минут переопределения их для каждого языка меня не особо беспокоили. В конце концов, небольшие проблемы с некоторыми «элегантными» решениями, такими как общая конфигурация или генерация кода, могут занять несколько часов или дней, так что же в действительности получается? Сложность и риск того, что что-то пойдет не так, что может потребовать дополнительных усилий, - это не то, с чем я хочу иметь дело.

Кроме того, если ваше приложение имеет так много констант, что их переопределение для каждого языка, когда вы добавляете или изменяете их, занимает значительное время, вы можете просто иметь более значительный запах кода для работы, и в этот момент вы можете захотеть включить к чему-то более сложному.

Короче говоря, переопределение их для каждого языка было моим лучшим решением, и мне еще предстоит придумать что-нибудь более СУХОЕ, которое не будет иметь большего фактора риска, чем я хочу иметь дело.

Одна вещь , чтобы определенно сделать, хотя, чтобы убедиться , что ваши постоянные хорошо документированы в обобщенном (и от языка) способ ( у нас есть компания documentarion репо с спецификации, прочие документы, «чертежной доски» документы и т.д. , где мы храним этот документ). Также убедитесь, что у вас есть механизм для синхронизации их определений. Это примерно такая же большая проблема с подходом дублирования, как и у вас, за исключением небольшого психологического стресса от намеренного дублирования кода. Но, в конце концов, ваши постоянные изменения должны быть очень осознанными и нечастыми , поэтому проблемы с синхронностью должны быть практически нулевыми.

Я должен также упомянуть, что за эти годы я видел многоязычные порты различных библиотек (слишком утомленные, чтобы помнить, что они есть в данный момент), написанные одной и той же группой, в которой неизменно определены константы в самих языках. Нет общей конфигурации, нет генерации кода (за исключением клиентских библиотек API Google ... но давай, у Google есть ресурсы, чтобы позволить себе такую ​​сложность). Так что я думаю, что мы натолкнулись на кирпичную стену на этом. Может быть, кто-то в конце концов придумает библиотеку для решения этой проблемы;)

Надеемся, что ядро ​​вашей библиотеки написано на одном языке, а другие библиотеки используют FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface ) для вызова основной библиотеки. Это даст вам центральное место для предоставления API для публикации констант и определений из. Таким образом, все внутри библиотеки. Я только упоминаю об этом, поскольку, похоже, он не включен в ответ Самуила.

Я думаю, что это действительно зависит от того, насколько способна ваша пользовательская база. Достаточно ли способны справиться с передачей другого файла конфигурации? Могут ли они настроить новый сервис? Для подавляющего большинства пользователей, которых я поддерживал, я хотел бы, чтобы все было автономно - таким образом, пользователям не нужно было бы думать об этом.