Руководство по внесению вклада

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

• Ошибки, о которых сообщается в Issue.
• Обсуждение бизнеса или технологий в Issue.
• Pull Request.
• Мнения или дополнения к документации.
• Любые другие действия, которые имеют смысл для этого проекта.

Я ограничен в своих возможностях, и я рад работать вместе с другими разработчиками.

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

Однако перед началом сотрудничества, пожалуйста, ознакомьтесь со следующими моментами.

Идея проекта

Litemall ориентирован на малые и средние предприятия, а не на интернет-компании, поэтому идея разработки Litemall — это простота и элегантность:

• Простота означает, что технология проста, архитектура проста, показатели производительности низкие, а бизнес охватывает только основные функции.
• Элегантность означает, что технологии новые, архитектура чёткая и легко расширяемая, коэффициент безопасности не низкий, бизнес может быть непосредственно развёрнут и использован.

Именно из-за этих соображений текущая архитектура Litemall проста, и все три стека технологий являются базовыми.

Хотя это так, на самом деле порог входа для разработки не низок:

• Проект использует три стека технологий, которые относительно независимы друг от друга;
• Используемые фреймворки Spring Boot и Vue-Element-Admin уже зависят от большого количества библиотек;
• Помимо разработки технологий, разработка также включает в себя другие технологии, такие как настройка среды, контроль версий, технологии тестирования, логирование и развёртывание.

Поэтому перед внесением нового кода или обсуждением бизнеса рекомендуется рассмотреть следующие вопросы:

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

• Зависит ли проект от слишком большого количества библиотек? Действительно ли необходимо полагаться на эти библиотеки? Если используется лишь небольшая часть библиотеки, можно ли создать простой класс util? Например, некоторые технологические фреймворки используют fastjson, хотя spring boot по умолчанию использует jackson, поэтому, если нет особых причин, вкладчикам следует использовать jackson.

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

• Есть ли уже одна технология, нужна ли другая технология с той же целью? Это приветствуется. Например, уже существует бэкэнд на основе vue, но бэкенды на основе других фронтенд-фреймворков также приветствуются. Это позволяет пользователям выбирать разные технологии. Конечно, следует стараться поддерживать синхронизацию между разными версиями. Или, например, у некоторых небольших программ уже есть некоторые фреймворки для разработки, в то время как текущий бэкенд для небольших торговых площадок всё ещё использует исходную технологию небольших программ, поэтому перестройка бэкенда для небольших программ на основе этих новых фреймворков для разработки приветствуется. То есть этот проект стремится избегать глубоких технологий и склоняется к широким технологиям, помогая себе и другим изучать и понимать различные технологии.

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

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

Бизнес проекта

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

Вклад кода

• Стандарты кода в настоящее время не являются строгими, и они будут дополнены позже.

Стандарт Issue

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