Гайдлайн для вклада

Любой вид вклада приветствуется, включая:

• Отчеты о багах в Issues
• Обсуждение бизнеса или технологий в Issues
• Pull Requests
• Предложения или дополнения к документации
• Любое другое полезное действие для проекта

Мои личные возможности ограничены, поэтому приветствуются совместные усилия.

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

Концепция проекта

Целевой аудиторией litemall являются малые и средние предприятия, а не интернет-компании, поэтому концепция разработки litemall — это "маленький, но красивый":

• "Маленький" означает простую технологию, простую архитектуру, низкие показатели производительности и покрытие базовых функций бизнеса
• "Красивый" означает новую технологию, чёткую и легко расширяемую архитектуру, высокие уровни безопасности и возможность немедленной установки бизнеса

Исходя из вышеперечисленного, текущая архитектура litemall является простой, используя три самых базовых набора технологий.Хотя так говорится, но фактический порог входа в разработку довольно высок:

• Проект использует три набора технологий, которые относительно автономны;

• Используется фреймворк Spring Boot и Vue Element Admin, зависящие от множества библиотек;

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

• Вносит ли вклад слишком много сложностей без соответствующего увеличения пользы?

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

• Насколько сильно проект зависит от внешних библиотек? Необходима ли такая зависимость? Если используется лишь часть библиотеки, можно ли реализовать простой util-класс самостоятельно?

  Например, некоторые фреймворки используют fastjson, хотя Spring Boot уже использует Jackson по умолчанию. Поэтому если нет особых причин, вкладчики должны стремиться использовать Jackson.

• Не является ли использование слишком многих передовых технологий преждевременным? Можно ли отложить применение этих технологий? Здесь требуется осторожность. Например, если планируется внедрение кэширования, потребуется изучение связанных библиотек и возможных проблем при использовании. Аналогично, до версии v2.0.0 нет необходимости заранее рассматривать проблемы производительности. Также единого входа в систему является базовой функцией распределенной архитектуры, но два сервера могут использовать свои собственные методы входа. Обратите внимание:

Здесь не вопрос отвержения новых технологий, а стремление к постепенному и осторожному подходу. Кроме того, использование новой технологии планируется путём создания независимого распределенного варианта на основе стабильной версии текущего проекта.* Существует ли уже имеющаяся технология, которая выполняет ту же задачу?

Это приветствуется. Например, если уже есть административная панель на Vue-фреймворке, то административная панель, созданная с использованием другого фронтенд-фреймворка, также будет приветствоваться. Таким образом, различные технические решения будут доступны пользователям с различным опытом. Вместе с тем, следует стремиться к синхронизации различных версий. Также, если в настоящее время существует несколько фреймворков для разработки mini-applications, но mini-application для магазина пока ещё использует базовый вариант mini-application, то создание нового mini-application на основе этих новых фреймворков будет приветствоваться.

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

• Если вы хотите сделать небольшие изменения или улучшить документацию.

  Это тоже приветствуется. Многие открытые проекты рекомендуют делать небольшие и логически чётко оформленные изменения при внесении кода. Это позволяет более эффективно проверять код. Однако, если проблема связана с ошибками в написании слов, то следует исправлять такие проблемы в одном коммите.Хотя здесь может возникнуть некоторое недоверие к новым технологиям, если пользователи считают, что есть более подходящая технология или она необходима, они могут обсудить это. Конечно, если разработчики не согласны с некоторыми идеями этого проекта, они могут создать свой собственный вариант, основываясь на своих выборах технологий. Если они считают, что их решение является лучшим, они могут отправить ссылку на этот проект, чтобы другие разработчики могли его просмотреть.## Бизнес-функциональность проекта

Основные бизнес-функции проекта уже перечислены в документации.

Если вы хотите внедрить продвинутые функции, такие как функцию дистрибутивной торговли, рекомендуется делать это самостоятельно на основе данного проекта.

Если вы считаете, что некоторые базовые функции не реализованы, вы можете сообщить об этом через Issue или обсудить это в QQ-группе, чтобы добавить её в план последующих разработок.

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

Вклад в код

• На данный момент строгих требований к стилю кода нет, но эти требования будут добавлены в дальнейшем.

Нормы для Issue

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