Участие в разработке¶

Проект открытый (лицензия MPL-2.0) — приветствуются сообщения об ошибках, предложения и pull request'ы.

Как ведутся задачи¶

• Все задачи проекта создаются в репозитории kfk-tasks.
• Ход работ виден на доске GitHub Projects.

Сообщения об ошибках и предложения от пользователей можно оставлять в issues репозитория адаптера — мейнтейнер перенесёт их в трекер задач.

Сообщить об ошибке¶

Укажите в issue:

• версию платформы 1С и версию адаптера;
• описание проблемы и шаги воспроизведения;
• отрывки из журнала регистрации и логов внешней компоненты;
• вариант внедрения (расширение / основная конфигурация).

Предложить улучшение¶

• Опишите задачу и ожидаемое поведение — «что» и «зачем», а не только «как».
• Для вопроса постарайтесь приложить минимальный воспроизводимый пример.

Прислать pull request¶

1. Для значимых изменений сначала откройте issue для обсуждения — это сэкономит время и вам, и мейнтейнеру.
2. Опишите в PR суть изменения и мотивацию.
3. Убедитесь, что изменение не ломает существующую функциональность — прогоните тесты.
4. Следуйте стилю кода подсистемы: префикс кфк, имена на русском, публичный API — только в модулях кфкИнтеграция / кфкИнтеграцияКлиент (см. Архитектура модулей).

Изменения в файлах под MPL-2.0 должны оставаться открытыми — это условие лицензии.

Проверка влияния изменений¶

Метаданные и очереди¶

При изменении объекта метаданных или схемы очереди проверьте:

1. формы и права;
2. запросы фоновых обработчиков и индексы;
3. сериализацию, десериализацию и внешнее логирование;
4. очистку и сроки хранения;
5. импорт/обновление настроек;
6. документацию и примеры;
7. YAxUnit- и UI-сценарии;
8. совместимость поставки как расширения и встраивания в основную конфигурацию.

Фоновые операции и статусы¶

При изменении worker logic, запросов или переходов статусов:

1. проверьте выборку, позиции операций и индексы;
2. определите поведение при аварийном завершении и перезапуске;
3. задайте статус, журнал и счётчики на каждой ветке;
4. проверьте блокировку, разблокировку и ручной возврат в очередь;
5. покройте пустую очередь, неполную порцию, дубль и ошибки;
6. исключите конфликт очистки с активной обработкой;
7. обновите мониторинг и операторскую документацию.

Публичный API¶

Переименование метода, изменение параметра или значения по умолчанию, структуры результата, допустимого типа, routing semantics либо lifecycle сессии считается изменением публичного API. Такое изменение требует SDD, compatibility analysis, документации и focused tests.

С чего начать¶

Если вы впервые в проекте — пройдите onboarding-маршрут «С чего начать разработку адаптера»: от клонирования репозиториев до первого PR.