________________________________________________________________________
TODO: пошукати та додати посилання на відео від Колі по заданих темах
________________________________________________________________________

# PART 1

Проходження онбордінгу - не коликтивне завдання.
Рівень самостійності виконаних завдань рівнопропорційний вникненню в суть ключових моментів проекту.

**1. Етапи зборки проекту. Part 1 - побудова виконавчого файлу (3 год)**
*Мета: побудувати уявлення яким чином виконується збірка проекту на прикладі TeamCity, як налаштовується при цьому оточення та як оновлюються дані AUS.*

TeamCity - CI/CD система управління побудовою застосунків і неперервної інтеграції. На даний момент вона використовується для нашого проекту.
Надалі планується перехід на GitLab CI/CD, але це не має вплинути на загальний флоу етапів CI/CD.

1) Розглянути зборку ClientDev/Android http://teamcity.servupdate.com:8111/buildConfiguration/Riverslot_ClientDev_AndroidUniversal
- Описати Build Steps, що відбувається.
- Як налаштовується оточення?
- Куди передаються результати збірки для того щоб в подальшому попасти на AUS?
- Deploy - особливий степ. Порівняти збірки для всіх платформ в рамках ClientDev, описати де він виконується та трохи пошукати інфу що таке AppCenter та для чого він використовується. Коротко описати.

`Hint: для доступу до Build Steps потрібно натиснути на кнопку Edit Build Configuration...`

**2. Етапи зборки проекту. Part 2 - пакування ресурсів (6 год)**
Розглянути зборку ClientDev/newResources http://teamcity.servupdate.com:8111/buildConfiguration/Riverslot_ClientDev_NewResources
- Описати Build Steps, що відбувається.
- Як налаштовується оточення?
- Куди передаються результати збірки?
- Розглянути детально скрипт resources/PackAll.py, описати алгоритм пакування ресурсів. Для чого призначені наступні сутності ResourcePacker, TheoraEncoder, TexturePacker, ResourceFolderHash?є
- Як надалі використовується результат роботи ResourceFolderHash?
- Як упакувати ресурси певної якості? Для чого це може знадобитися на практиці?
- Для чого використовується скрипт PackAll.sh?

**3. Етапи зборки проекту. Part 3 - система патчінгу (4 год)**
З метою оптимізації оновлення ресурсів було впроваджена система патчінгу ресурсів. Основний принцип - передавати зміни файлів у вигляді патчів. До цього, коли вносилися зміни до ресурсів гри, заново викачувалася оновлена папка з ресурсами гри. При умові тренду збільшення об'єму ресурсів ігор та періодичного їх рефакторингу, стало досить некомфортно для кінцевих користувачів.

1) Розглянути зборку ClientDev/newPrepareAusDev
- Описати Build Steps, що відбувається.
- Як налаштовується оточення?
- Куди передаються результати збірки?

2) Основні принципи патчінгу
- Яка сутність нашого проекту відповідає за створення патчів?
- Яка бібліотека використовується, чому на вашу думку вона була обрана?
- Які файли підлягають патчингу в нашому проекті?
- Яким чином отримані патчі з AUS застосовуються до файлів ресурсів?

Hints:
- копія GeneratePatchList.py знаходиться в нашому проекті в папці tools
- коміти, в яких був доданий даний функціонал
9ac1811c98a1b65d24cd837bc73ec80b02138a9c
3c098da8bc01494dd6b57c9b8ad1f43eb2a05b3b
2aefe133304a62e056ce83b1efeff49d54b621a1

**4. AUS, принцип роботи. Запуск локального AUS. Порядок запуску додатку, взаємодія з AUS (12 год)**
AUS (auto update server) - інструмент, який використовується для обміну даними, що відповідають певній версії додатку. Саме завдяки AUS кінцевий користувач отримує оновлені ресурси та оновлений виконавчий файл, якщо це передбачено конфігурацією збірки.

В рамках задачі необхідно ознайомитися з основними принципами роботи AUS:
1) Яким чином додаток визначає чи є необхідність зв'язуватися з AUS? Як це налаштувати (через код/систему збірки)?
2) На якому етапі додаток встановлює зв'язок з game server та AUS? Описати загальний алгоритм.
3) Яка сутність в клієнті відповідає за оновлення даних? Які її основні принципи роботи?
4) Якщо передбачено оновлення виконавчого файлу, яким чином виконується перезапуск додатку після скачування останньої версії?
5) Для чого використовується файл deploy/Manifest?
6) Як на прикладі TeamCity AUS отримує зміни
`Hint: Riverslot/AUS/Deploy/aus-dev`

Для закріплення набутих знань та використання їх на практиці необхідно запустити локальний AUS.
Виконайте певні зміни в ресурсах головного меню та отримайте їх через локальний AUS. Важливо: в рамках навчального процесу зробіть так щоб AUS містив ресурси тільки в 1 якості, а також в обмеженій кількості (тільки ті, які обовязкові і необхідні для запуску MainMenu). Необхідно зробити запис екрану мобільного пристрою для підтвердження виконаного завдання.

Опис протоколу та інструкція щодо запуску локального AUS - https://netgame.atlassian.net/wiki/spaces/KB/pages/221642753/AUS

**5. GameServer/WebBackend (3 год)**
Клієнт взаємодіє з 2ма backend сутностями - GameServer та WebBackend ("платежка").
З GameServer точно більшість працювала при створенні ігор.
WebBackend - використовується для реалізації деякого "фічового" функціоналу.
Основний клас для взаємодії з WebBackend - vsdk::AcpApi.

- Описати за що відповідає GameServer, який принцип взаємодії з клієнтом?
- Яка сутність відповідає за Account?
- Які фічі реалізовані через GameServer і в чому основний принцип vcore частини GameServer фіч?
- Як відбувається ініціалізація AcpApi, які дані відправляються і на якому етапі завантаження додатку?
- Які фічі реалізовані через AcpApi?

**6. Google analytics в проекті, загальні принципи використання (3 год)**
Google Analytics — це інструмент, який допомагає власникам програм розуміти, як користувачі взаємодіють з їхнім продуктом. Він збирає дані про дії користувачів у програмі, включаючи інформацію про помилки. Ці відомості допомагають покращити додаток, роблячи його зручнішим та функціональнішим. Основна робота Google Analytics здійснюється через пряме надсилання HTTP-запитів на сервери Google Analytics.

- Які параметри є обов'язковими для надсилання події в Google Analytics?
- Що спільного в усіх подіях, які ми реалізували в Google Analytics?
- Яка загальна інформація надсилається разом з кожною подією?
- Для чого потрібний режим налагодження і як його включити?

**Завдання:**
- Реалізуйте свій власний подійний запит на основі існуючих та надішліть його. При успішному виконанні завдання сервер повинен повернути статус HTTP код 204 або 200, що означає "Запит успішно оброблений".
- Спробуйте надіслати дані з помилкою за допомогою режиму налагодження. У чому полягає різниця між стандартною відповіддю сервера та відповіддю в режимі налагодження?

**7. Принципи проведення code review (4 год)**

Для чого потрібне code review?
- розробники розбираються в коді проекту та краще орієнтуються по ньому
- обмін заннями та досвідом
- підтримка якості коду проекту для більш ефективної роботи з ним в подальшому
- робота над софт скілами
- виправлення пропущених грубих помилок

*На що потрібно звертати увагу при code review:*
1. Грубі помилки (відсутність відписок, некоректна робота з пам'яттю, відсутність обнулення EndHandlers, memmory leaks, в тому числі і відсутність очищення кешу, не врахування завантаження ресурсів з AUS та ін.)
2. Code style та перевірка дотримання принципів чистого коду.
3. Архітектурні рішення, використання "велосипедів" коли вже є рішення, яке призначене для повторного використання (якщо навіть на етапі внесення правок по ревью на виправлення цього немає часу, обов'язково потрібно вказати слабкі місця для того щоб розробник зробив висновки і не повторював це в майбутньому).
4. Логічні помилки.
5. Перевірка читаємості коду та ступеню доступності розуміння рішення без глибокого занурення. Структурованість коду.

Якщо завдання передбачає додавання нового функціоналу, що в перспективі буде повторно використаний, або стоїть задача розробки складної гри/фічі (що ми до цього не робили), необхідно проводити ревью поетапно:
- формулюємо загальну задачу і обговорюємо які сутності мають бути, створюємо UML діаграму та затверджуємо
- деталізуємо діаграму до рівня орієнтовних інтерфейсів, затверджуємо
- після реалізації - проводимо обовязкове code review (не чекаємо завершення виконання всієї задачі)

Лекція про принципи чистого коду
https://youtu.be/otrfSgeK3JI
Локанічна стаття з основними принципами
https://habr-com.translate.goog/ru/articles/741186/?_x_tr_sl=ru&_x_tr_tl=uk&_x_tr_hl=uk&_x_tr_pto=sc&_x_tr_hist=true
Є гарні думки
https://tproger.ru/articles/kod-revju-kak-sdelat-pravilno

**Завдання:** перегляньте свої попередні code review і подумайте чи відповідають вони вище наведеним критеріям та порадам. Доповніть список *На що потрібно звертати увагу при code review*