Перейти к содержанию

🗒 Задача

Пишем логику экрана приложения для интернет-магазина. Представим, что у интернет-магазина было 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), чтобы изменения с сервера появились в локальном проекте

🧾 Решение

fun main() {
    val numberOfOrders: Int = 75    
    val textWithThanks: String  = "Спасибо за заказ!"
}