Як слід керувати константами на кількох мовах?


13

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

Я зараз це роблю, маючи код, що визначає константи в кожній мові.

Проблема полягає в технічному обслуговуванні. Якщо я додам новий код помилки, мені потрібно оновити його в кожній бібліотеці вручну. Хоча це нормально для кількох, це стає втомливо, якщо я скажу 5 sdks для оновлення. Було б непогано мати єдине джерело істини і для них.

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

Чи є кращий спосіб впоратися з підтримкою констант, які поділяються між різними мовами?


Ваш підхід чудово, Ендерленде. Я намагався знайти краще рішення для переосмислення, тому що багато разів багато клієнтів споживають API, які я програмую, і дійсно немає елегантного рішення. Перевизначення констант все ще є найпростішим.
Енді

5
@DavidPacker ні ні ні, у вас має бути справді елегантне рішення. Не кажіть мені, що це найкраще! :-)
Ендерленд

1
Я ставив під сумнів свій вибір, але потім зрозумів, що константи мають бути постійними. Вони передбачувані, оскільки є постійними. Зберігаючи їх у форматі JSON або будь-якому іншому, в цілому форматі розбору, вони вже не є константами. Типовим прикладом мого робочого процесу є об’єкт сповіщення, що містить typeатрибут для ідентифікації структури при передачі його по дроту. Маючи це, мобільні клієнти визначають лише константи (типи), які вони розуміють в даний момент часу, і ігнорують будь-які невідомі типи. Динамічне визначення спричинило б багато проблем.
Енді

Вам потрібна таблиця таблиць, яка відображає рядки констант із таблиць мов.
Johnny

Відповіді:


10

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

  • Витягніть константи (а можливо, і моделі) в інший пакет, який складений між собою на всіх ваших мовах. Можливо, ви зможете скласти всю бібліотеку, але це може спричинити значну кількість проблем. Просто константа перехресного компілювання повинна бути досить простою, щоб не було стільки питань. Ви можете опублікувати пакет констант і залежати від нього у ваших мовних бібліотеках. Хакс може, мабуть, це зробити. Цей підхід хороший тим, що ви все ще будете перевіряти час компіляції (для компільованих мов)
  • Зберігайте конфігурацію в центральній службі. Наприклад, мильні веб-сервіси мають мову опису веб-служби (WSDL), а служби REST мають мову опису веб-додатків (WADL), яка описує операції та повідомлення служби. Існують також загальні послуги централізованої конфігурації, такі як Spring Cloud Config
  • Налаштування файлу. Я знаю, що ви вже запропонували це, але я не думаю, що це має сильно ускладнювати процес збирання / випуску. Помістіть свій конфігураційний файл в окремий проект збірки (там, де ви можете його версію). Опублікуйте проект у всіх сховищах специфічних для всіх мов пакетів (Maven, Nuget, NPM тощо), тоді у ваших мовних бібліотеках ви можете залежати від пакету. Це не повинно бути складнішим, ніж створення додаткового проекту у вашому конвеєрі.
  • Як запропонував RubberDuck, генерація коду є хорошою альтернативою перехресному компілюванню. Ви можете генерувати постійні визначення для кожної мови, використовуючи загальну конфігурацію.

5
Згенерування коду @RubberDuck звучить цікаво (особливо для одного з моїх випадків тангенціального використання, який уже включає генератор коду в будь-якому разі).
Ендерленд

3

Чудове запитання! У мене таке саме питання; мої константи по суті: які мови підтримуються в моїх програмах та додаткова інформація про ці мови, коли вони стосуються функціональності в додатку.

На жаль, найкраще, що я знайшов (як і у вас), - це просто переосмислити константи для кожної мови, як ви зараз робите (я знаю, ви напевно хотіли це почути ).

Очевидно, це почуває себе неправильно, тому що це протилежність DRY ( WET ?? ). Однак константи повинні змінюватися настільки рідко, що 5-10 хвилин переосмислення їх для кожної мови насправді не турбує мене. Зрештою, невеликі проблеми з таким "елегантним" рішенням, як спільне налаштування або генерація коду, можуть зайняти години чи дні, щоб вирішити, що ж насправді отримано? Додаткова складність із ризиком того, що щось піде не так, що може докласти додаткових зусиль для виправлення, - це не те, з чим я хочу мати справу.

Крім того, якщо у вашій програмі є стільки констант, що їх переосмислення за кожною мовою при їх додаванні чи зміні потребує значної кількості часу, ви можете просто мати більш важливий запах коду для вирішення, і в цей момент, можливо, ви захочете звернутися до чогось складнішого.

Отже, коротше кажучи, переосмислення їх для кожної мови було моїм найкращим рішенням, і я ще не повинен придумати щось більше ДУХОГО, яке б не мало більше фактора ризику, ніж я хочу мати справу.

Одне, що потрібно обов'язково зробити, - це забезпечити, щоб ваші константи були добре задокументовані узагальненим (та мовним агностиком) способом (у нас є документальний репортаж компанії із специфікаціями, різними документами, документами «креслярської дошки» тощо), де ми зберігаємо цей документ). Також переконайтеся, що у вас є механізми (механізми) для синхронізації їх визначень. Це настільки ж велика проблема, як у вас буде підхід щодо дублювання, за винятком невеликої кількості психологічних проблем від навмисного дублювання коду. Зрештою, ваші постійні зміни повинні бути дуже обдуманими та нечастими , тому проблеми синхронізації повинні бути по суті нульовими.


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


0

Сподіваємось, ядро ​​вашої бібліотеки написано однією мовою, а інші бібліотеки використовують FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface ) для виклику до основної бібліотеки. Це дасть вам центральне місце для надання api для публікації констант і визначень з. Таким чином, все знаходиться в бібліотеці. Я лише згадую це, оскільки воно, схоже, не входить у відповідь Самуїла.

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


1
Hopefully, the core of you library is written in one language, and the other libraries use FFI На жаль, у нас є бібліотеки як для веб-клієнта, так і для коду сервера (на декількох мовах), тому ... це було б нетривіально (і, мабуть, вразливість безпеки, якби ми могли почати з веб-програми).
enderland

Я б запропонував вам покращити свою безпеку, оскільки я ніколи б не довіряв своїм користувачам достатньо, щоб зберегти конфігураційні файли в секреті.
Роберт Барон

Як ви розгортаєте веб-програми, які обробляють коди помилок? Або назви полів json? Мене бентежить те, що ви думаєте, що я роблю, що це питання безпеки. Запуск довільного коду на машині мого клієнта - це абсолютно безпечна проблема, що дозволяє їм розбирати json з сервера, здається, не буде, якщо я щось не пропускаю.
enderland

Я працював у компаніях, які основою безпеки були генератори випадкових чисел у стилі DOS та значення насіння, що зберігаються як константи. Вони, як правило, виправляються дуже швидко після їх вказівки. Однак якщо ви викладете насіння значення у світ, ви віддасте ключ до королівства. Оскільки ваше програмне забезпечення, здається, передусім веб-базі, зберігайте конфігурацію в об'єкті JSON і нехай кожна з мов розбирає однакові спільний файл.
Роберт Барон

Назви полів JSON, ймовірно, не мають і не повинні бути постійними. Які б шанси на те, що ці назви полів потрібно було б змінити, але ви не змінюєте ім'я самої константи? Ви, ймовірно, більше виграєте від створення коду для доступу до записів або використання мови вираження, наприклад, ObjectPath.
Лежать Раян
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.