🗒 Задача¶
Пишем логику экрана приложения для интернет-магазина. Представим, что у интернет-магазина было 75 заказов. Нужно продумать релевантные названия и корректно объявить 2 переменные, которые будут содержать:
-
количество заказов,
-
текст с благодарностью за покупку (текст на твое усмотрение).
Задай “говорящие” наименования переменных (например, для сторон прямоугольника не a и b, а height и width). Названия переменных должны состоять из нескольких слов. Тип переменных указывать принудительно.
❌ Ошибки¶
-
неправильный нейминг и стилистика — нужен camelCase
-
лишние файлы в git (с задачами или ненужные конфиги) — 1задача-1файл
-
для правок создают новый пулл реквест — при первых правках напомнить кратко алгоритм внесения правок и повторной сдачи задачи
-
оставляют аргументы fun main(args: Array
) — нет нужны сейчас, только на курсовом пригодятся -
реализация через класс, а не переменные
-
мержит сразу в master без аппрува
-
не ошибка — говорим, что не обязательно использовать U-переменные
-
название ветки кириллицей
✏️ Комментарии¶
Корректные нейминги PR (принимаем)¶
Больше одной пустой строки старайся не оставлять на будущее, предлагаю сразу привыкать писать красивый код согласно конвенции стиля Kotlin
Согласно [конвенции](https://kotlinlang.org/docs/coding-conventions.html) стиля Kotlin символ присваивания всегда обосабливается пробелами
при объявлении типа пробел ставится после двоеточия. Должно получиться вот так, например: `var orderCount: Int = 45`
Чтобы внести изменения нужно будет переключиться в эту ветку, сделать коммит с изменениями и запушить. И отправить ссылку на этот же пулл реквест в бот к соответствующей задаче.
Некорректные нейминги PR (принимаем)¶
Привет! Хорошее оформление пулл реквеста, но нейминги я бы привел в более общепринятый вид. С указанием префикса проекта, номера урока и задачи. Это относится и к названию пулл реквеста, и к названию ветки.
Это на будущее, сейчас аппрув. Теперь этот пулл реквест можно мержить в мастер. Перед созданием новой ветки (обязательно из мастера) не забудь сделать его Update, чтобы слитые изменения прилетели с сервера в локальный проект.
Для доработки задачи при работе через Gist - отредактируй этот документ и присылай ссылку на него в бот к соответствующей задаче.
Привет! отличное оформление пулл реквеста, все нейминги верные. Однако в Kotlin нет необходимости создавать классы в файле, чтобы в них делать некий запускаемый код.
Kotlin - функциональный язык. Поэтому достаточно в файле объявить функцию с зарезервированным названием main() и в ней писать код, который можно исполнять.
Предлагаю так и сделать)
Чтобы внести изменения нужно будет переключиться в эту ветку, сделать коммит с изменениями и запушить. И отправить ссылку на этот же пулл реквест в бот к соответствующей задаче.
Когда вместо Int например используют Short
В практике, в большинстве коммерческих проектов так конкретно типы указываются довольно редко. Если это не условно высокоточная программа уровня космонавтики, то в остальных случаях это экономия на спичках. Это для информации, ни в коем случае не ошибка.
Предлагаю сразу писать код в исполняемой функции main() Даже, если там нечего запускать в какой-то конкретной задаче.
Несколько комментариев по оформлению пулл реквеста:
- Префикс проекта с названием и номером урока задачи следует прописывать в названии пулл реквеста. Например, "KS-1-1 сделал то-то”
- Название ветки также должно содержать префикс проекта с номером урока и задачи, чтобы они все были уникальны и в них можно было легко ориентироваться. Слова в названии веток разделяются дефисами. Например, “KS-1-1-create-smth”.
Нарушение Git-flow¶
Есть нарушения в git флоу, то есть в логике работы с коммитами и ветками.
Обрати внимание, сначала ты сделал одну задачу, запушил и все ок.
Затем ты закоммитил в эту же ветку другую задачу (либо создал следующую ветку из предыдущей рабочей ветки) – это видно в истории коммитов.
Что из этого следует? В пулл реквест с одной задачей попала задача, которая должна быть в другой ветке. Это нарушает суть разделения кода задач по веткам. Задача из одной ветки не должна знать и пересекаться с задачей из другой ветки.
На большом проекте затрагивается много файлов и если в одном ПР делать другие изменения (из другой задачи), то при слиянии может быть много проблем и/или гит конфликтов. Например, над кодом другой задачи уже работает программист, изменения из второй задачи не проверены и не протестированы (тестировщики проверяют функционал по конкретному тех. заданию в рамках данного описания задачи в конкретной ветке).
Новые ветки создаем только из мастера (который предварительно надо обновить, если до этого мержились задачи в гитхабе), чтобы не было пересечений с другими тасками)
Что делать?
в данном пулл реквесте надо:
- переключиться в ветку текущего ПР
- удалить лишний файл с задачей (физически из проекта)
- сделать коммит (с изменением удаления)
- прислать ссылку на этот же пулл реквест снова в бот
И новые ветки всегда создаем из основной ветки master.
На будущее старайся, чтобы в пулл реквест с конкретной задачей не попадали измененные файлы, которые к задаче не относятся) это нарушает гитфлоу. при коммите их достаточно не отмечать галкой и не добавлять в стейдж
Комментарий к форматированию. согласно конвенции в котлин фигурная скобка функции открывается на той же строке, где функция декларирована — https://kotlinlang.org/docs/coding-conventions.html#formatting
По поводу U - переменных. Отлично, что применила их в коде, однако, в большинстве такая тонкая настройка не используется. То есть микро экономия памяти "на спичках" актуально разве что в ПО уровня космонавтики, где важен каждый байт.
Здесь и далее в Pull Request’ах аргументы функции `main()` излишни в рамках задач. Мы их никак не используем в задачках, но вернемся в рамках курсовой - будем передавать секретный токен бота, который нежелательно хранить прямо в коде.
Обрати внимание, что Pull Request содержит только код с правками для данного таска, а не весь таск целиком. В коммите `[Пересобрал проект]` ты добавил среди прочего решение для первой задачи.
В реальных проектах такой беспорядок порицается, по факту - в master попали изменения, которые еще не были никем просмотрены.
Самое главное исключить вариант, когда в разных ветках будет отредактирован один и тот же файл. Это называется "конфликты". Потому что система не будет понимать какой код приоритетнее. Их можно зарезолвить и даже в рамках курсового проекта будет на это практика, но пока лучше не доводить до такого.
Сейчас такого возникнуть не должно. Ветка с определенным коммитом - это определенное состояние проекта. И гит умный, командой merge (слияние) он добавит новый файл с задачей из новой ветки в существующий пакет. Конечно, если этот файл будет иметь другое название. Это и есть безопасное слияние двух состояний проекта, где файлы не конфликтуют друг с другом.
Еще можно упростить себе жизнь, сделав заглушки на несколько уроков вперед и самостоятельно их запушить сразу в мастер. Тогда не придется для каждой ветки создавать новые пакеты с файлом, а просто писать задачу в соответствующем.
Ну и отвечая на вопрос, можно безопасно создавать ветки параллельно, но всегда обязательно от мастера. Если до этого в него был сделан мердж другой ветки, то его надо обновить (клик на ветку справа внизу в Идее и Update), чтобы изменения с сервера появились в локальном проекте