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

Самое простое решение, оно же самое расточительное, заключается в написании отдельного модуля для каждой версии. При этом имеются следующие недостатки: низкое переиспользование кода; высокая ветвистость -- возникают конструкции вроде следующих:

if (protocol_version == 0)
protocol_method_0(...);
else if (protocol_version == 1)
protocol_method_1(...);

Более того -- при обновлении протокола придётся дописывать по ветви во *всей* программе!

Ещё одним способом решения может быть модификация предыдущего метода: включить в вызов каждой функции протокола аргумент версии. Тогда можно будет делать так:

protocol_method(protocol_version, ...);

Ветвистость, конечно, останется, но её будет меньше, поскольку мы её перенесли в код самих функций, реализующих протокол.

Но вот что делать, скажем, если в новой версии протокола изменена сигнатура функции? Тогда мы снова вынуждены городить if-else для того, чтобы правильно работать. В этом случае можно придумать ввести дополнительный аргумент "сырых" данных, в которых может быть что угодно или сделать все функции с переменным числом аргументов, а что туда писать прописать в документации, однако это уж слишком непрозрачно.

Делают же как-то это и уже много лет! Например, если указать gcc использовать такой-то стандарт, он и будет его использовать! Читал ещё про шаблон "Стратегия", но он годится только для объектно-ориентированных языков. Как-то же справлялись с этим до Java/C++ и подобных? @tech@mastodon.ml

Все здравствуйте! У меня возникла пара вопросов, которые я уже некоторое время не могу для себя разрешить.

Вопрос 1. Каких соглашений следует придерживаться при написании коммитов до реализации некоторого труднозатратного функционала (feature)? Под труднозатратным я подразумеваю такое изменение, которое, для удобства будущего чтения
истории коммитов, необходимо разбить на несколько изменений поменьше (например, такое может возникнуть при
реализации функционала для нескольких операционных систем: первый коммит в feature-ветке относился бы к OS-1,
второй -- к OS-2 и т.д.). В общем случае рекомендуют придерживаться Conventional Commits, но тогда minor-версия
будет возрастать слишком быстро (потому как каждое изменение в рамках feature-ветки придётся помечать как feat).
На форумах предлагали следующий вариант: объединить все коммиты в ветке в один (squash), который уже пометить как
Conventional Commit. Однако в этом случае теряется история изменений... Может быть есть какой-нибудь промежуточный
вариант, допускающий автоматизацию (скажем, генерацию CHANGELOG.md), являющийся общепринятым? Хочется всё сделать правильно.

Вопрос 2. При тестировании коммита на соответствие Conventional Commits рекомендуют использовать husky и
commitlint (git-hook). Однако всё это добро необходимо всякий раз складывать в репозиторий (загружаются
node_modules весом ~100 MiB), что меня не слишком устраивает: для такой относительно небольшой задачи требуется
столько всего устанавливать! Нет ли варианта проще, что-то вроде небольшой утилиты для этого? Да и вообще, есть ли какой-то список средств для автоматизации подобных задач (аналоги commitlint, conventional-changelog, standard-version и проч.) не из npm? | @rf@mastodon.ml