Правила работы с системой контроля версий:
-
ВСЕ РАБОТАЮТ НАД СВОЕЙ ЗАРАНЕЕ ОБГОВОРЕННОЙ ЧАСТЬЮ ЛОГИКИ/ДИЗАЙНА С ЦЕЛЬЮ ИЗБЕЖАНИЯ СТИРАНИЯ ЧУЖОГО ПРОГРЕССА
-
ЗАПРЕЩАЕТСЯ ИЗМЕНЕНИЕ СТРУКТУРЫ ПРОЕКТА
-
ПОСЛЕ ЛЮБОГО ИЗМЕНЕНИЯ В ПРОЕКТЕ ОБЯЗАТЕЛЬНЫЙ КОММИТ
-
a) Любой коммит должен сопровождаться комментарием вида "краткое_описание_изменений -vX.Y.Zw"
b) Краткое описание изменений не должно превышать 50 символов и 1 предложения
c) X обозначает добавление еще одного готового функционального комплекса. Пример - полный функционал Покупателя.
d) Y обозначает добавление иного значительного функционала. Пример - сделан функционал личного кабинета Покупателя
e) Z обозначает добавление минорного функционала. Пример - сделан функционал добавления продукта в список понравившихся.
f) w обозначает любые другие изменения.
-
После любого значительного изменения (vX/Y) требуется обновление билда в проекте для упрощенного тестирования
-
Требования к репозиторию:
a) Папка проекта и его файлов
b) Билд снаружи проектной папки в АРХИВИРОВАННОМ виде
c) Документация к проекту
d) WorkflowRules.md (Он же README.md)
e) Gitignore файл для поддержки билдов
d) Поддержка LFS для подгрузки больших файлов
-
Требования к файловой системе Unity:
a) Соблюдение общепринятой файловой структуры Unity (Код в папке Scripts/Logic, спрайты в папке Sprites и тд)
b) Название основной сцены НАЗВАНИЕ_ПРОЕКТА_Main.Proj
c) Все enum в одном файле
d) Каждый класс в отдельном файле
e) Для каждой подпапки Scripts/ScriptFolderName свой namespace
f) В каждой подпапке не более 5 файлов кода
-
Требования к сцене Unity:
a) Разделение в иерархии объектов на:
i) ENV STATIC ii) LOGIC iii) ENV DYNAMIC iv) UIb) Проверка работы приложения проводится в вкладке Simulator как минимум на трёх разных устройствах
Правила коммуникации:
- Основные инструменты коммуникации - Telegram Беседа (Текст, Голос, Видео), Discord Канал (Текст, Голос, Видео), Живое общение
- Если в голосовом формате идет диалог по делу, не перебивать
- Если в голосовом формате диалог слишком долго не по делу - перебивать
- Если хоть что-то понятно, но есть вопросы - спросить в текстовый чат
- Если ничего не понятно - читать документацию пока хоть что-нибудь не станет понятно
- Если п.5 не был достаточен для того, чтобы выразить оставшиеся вопросы в одном-двух предложениях - повторить п.5
- Если кто-то с чем-то не согласен - выразить несогласие в текстовый чат в одном-двух сообщениях
- Если кто-то хочет что-то предложить - обсудить в порядке живого общения/текстовой коммуникации
- Формулировать текст упорядоченным образом
- Если выраженная мысль не ясна, вежливо переспросить
- Не реализовывать живую коммуникацию в неподходящий для этого момент
- В подходящий же момент стараться начать осмысленный деловой диалог, если на то есть причина
Правила по написанию кода: При работе с языком программирования C# стараться следовать конвенции, предложенной Microsoft:
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions
Комментарии с большим числом строк допускаются только в начале документа
В иных случаях длина комментария не должна превышать 50 символов, 1 предложение и сам комментарий должен быть вынесен на отдельную строку.
Порядок поиска информации в документации:
Основным источником информации должны служить текстовые документы, в частности любого рода требования.
Визуальные документы больше подходят для сверки информации и являют собой наглядный пример.
Рекомендуется поиск по ключевым словам.
Рекомендуется поднимать вопросы в беседе о том, где найти информацию, только после прочтения, анализа и осознания предыдущих пунктов.
Средства распределения задач между членами команды:
- Соответствующий тематический периодический голосовой чат
- При проявлении инициативы относительно конкретных элементов задания задавать вопрос на общее рассмотрение в текстовую беседу
- Длительное отсутствие какого-либо прогресса в выполнении поставленных задач несет за собой глубокое прямое осуждение со стороны команды, руководства и заказчика
Средства отслеживания работы над проектом:
- После выполнения некоторой значимой на усмотрение исполнителя функциональной части задания требуется написание отчета о выполненной работе в текстовую беседу
- Коммиты в репозиторий также являют собой метод подтверждения проделанной работы и соответственно контрибуции в него являются обязательными и периодическими
- Кроме того, отчеты должны сопровождаться соответствующими хештегами #Name_Surname_Report (Пример #Viktor_Dulov_Report) для упрощенного поиска по беседе
- Одобряется и поддерживается сопровождение результатов работы скриншотами и иного рода медиа-демонстрациями продукта