Skip to content

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

Благодарим за интерес к развитию RUSEON Core! Мы приветствуем исправления ошибок, оптимизацию производительности, улучшение документации и добавление новых возможностей.

Процесс разработки и Git Workflow ​

Мы используем модель ветвления на базе ветки dev:

  1. Форк репозитория: Создайте собственный форк репозитория на GitHub и склонируйте его локально.
  2. Создание ветки: Создавайте тематическую ветку от dev в формате feat/название-фичи или fix/описание-бага.
  3. Обсуждение изменений: Перед реализацией крупных архитектурных изменений создайте Issue для согласования концепции.
  4. Реализация и тесты: Любой код на Go должен сопровождаться тестами, проходящими проверку под флагом -race.
  5. Форматирование и линтинг: Выполните golangci-lint run и cd web && npm run lint.
  6. Создание Pull Request: Все PR направляются в ветку dev.

Стандарт сообщений коммитов (Conventional Commits) ​

Все коммиты должны строго следовать спецификации Conventional Commits:

text
<тип>[опциональная область]: <краткое описание>

[опциональное подробное тело сообщения]

[опциональный футер с ссылками на Issue]

Разрешённые типы коммитов: ​

ТипКогда использоватьПример
featДобавление новой функциональности или APIfeat(webrtc): add whep audio track negotiation
fixИсправление ошибки или некорректного поведенияfix(recorder): prevent file descriptor leak on disk full
perfОптимизация CPU, памяти или ввода-выводаperf(buffer): eliminate cloneBytes allocation in hot path
docsИзменения только в документацииdocs(api): document query parameters for /api/v1/archive
testДобавление или обновление тестовtest(e2e): add Testcontainers test for H.265 stream
refactorРефакторинг кода без изменения поведенияrefactor(db): isolate badger transaction helpers
choreОбновление зависимостей, CI/CD, сборкиchore(deps): upgrade pion/webrtc to v4

Стандарты написания кода ​

Рекомендации для Go: ​

  • Zero Allocations на горячем пути: Избегайте аллокаций слайсов и структур в циклах передачи медиакадров (WriteFrame).
  • Передача Context: Передавайте context.Context первым параметром в длительных операциях и обработчиках API.
  • Обработка ошибок: Всегда проверяйте и оборачивайте ошибки (fmt.Errorf("действие: %w", err)). Не игнорируйте ошибки через _.
  • Потокобезопасность: Защищайте общее состояние с помощью sync.RWMutex или атомиков (sync/atomic). Обязательно проверяйте код с go test -race.

Рекомендации для фронтенда: ​

  • Строгая типизация TypeScript (noImplicitAny).
  • Модульная архитектура компонентов в web/src/components/.
  • Валидация форм и понятная индикация ошибок для пользователя.

Связанная документация ​

Released under the MIT License.