Результати пошуку

Побудова модульної архітектури — поширений підхід для розробки масштабованих і підтримуваних проєктів для Android. Який спосіб розділення на модулі обрати? Яка їхня оптимальна кількість? Чи варто робити модуляризацію, коли проєкт на стадії MVP? Владислав Козир, Android Engineer у Headway поділився кейсом впровадження модульної архітектури для учасників комʼюніті мобільної розробки. Він розповів про теоретичні та практичні аспекти, підхід, який рекомендує Google, згадав, з якими проблемами стикнулася його команда під час імплементації рішення та як їх долала. > Модуляризація: плюси, мінуси, підводні камені > Як розбивати проєкт на модулі: бачення та рекомендації Google > Принципи розподілення на модулі > Час збірки > Як ми починали роботу над модуляризацією > Корисні матеріали Модульна архітектура: плюси, мінуси, підводні камені Як виглядає типовий флоу розробки більшості продуктових команд: отримавши дизайн певної фічі, команда береться до розробки. Якщо задача досить складна, може зʼявитися проміжний етап її проєктування всередині команди. В ідеальному світі після закінчення розробки команда передає ресурси на локалізацію, «релізиться» та починає A/B тестування. Отримавши результати, приймає рішення на основі аналітики. І зрештою має почистити конфіги та прибрати зайві івенти з аналітики. Подібний флоу мала наша команда, але зі зростанням ми стикнулися з певними проблемами. Одним із найочевидніших рішень була модуляризація. Постало питання: чи підійде це нашому кейсу, та чи буде результат вартим зусиль? Так виглядає умовна схема модулів та звʼязків між ними у нашому хедлайнері — застосунку Headway. Для збору модуля :app потрібен певний функціонал: Reader, Library тощо. Уявімо ситуацію, що команда локалізації й контенту захотіли мати окремий застосунок, в якому можна давати фідбек і переглядати його в апці. Під ці потреби добре лягає концепція модуляризації всього проєкту. Наприклад, якщо нам потрібен суто Reader (:App-demo-reader), ми беремо всі потрібні фічі, які відносяться до неї, а також модулі, повʼязані з domain- чи з data-логікою, і будуємо залежності. Демо-апка також може додатково містити модулі, повʼязані з фідбеком до контенту, — певну репортингову систему, яка дозволить слідкувати за якістю контенту, сповіщати про проблеми з ним. Плюси модульної архітектури: Краща організація коду. Це дозволяє команді масштабуватися без зайвих проблем. Легке управління та підтримка. Невеликі функціональні команди зможуть розробляти певні модулі та відповідати за певну область застосунку. Це допоможе пришвидшити розробку. Зручність тестування. Кожний модуль можна тестувати незалежно, що полегшує виявлення та виправлення проблем. Це призводить до кращого тестового покриття та надійності коду. Скорочення часу збірки. З правильним підходом до модульної архітектури можна оптимізувати час холодної та гарячої збірки. Мінуси модульної архітектури: Ретельне планування та координація. Варто завчасно продумати та перепроєктувати вашу систему, щоби мати прогнозований результат її використання і не стикатися з великою кількістю проблем. Ризики конфліктів та несумісності в управлінні залежностями. Як розбивати проєкт на модулі: бачення та рекомендації Google У ґайді з модульної архітектури Google спростовує міф про єдиний варіант розбиття проєкту на модулі за шарами (data, domain, presentation), згідно з ідеєю Clean Architecture. На думку розробників, можна так само розділяти проєкт на модулі суто за сферою використання, тобто певними фічами. Що ми маємо в такому разі: фіча, яка містить логіку Reader, має також посилатися на прогрес із бібліотеки користувача. Тобто вона буде залежною від інших фіч. У такому випадку ми збільшуємо висоту дерева модулів у проєкті, що призводить до збільшення паралельної збірки. Отже, краще розбивати проєкт і за фічами, і за шарами. Наприклад, у фічі Reader ми можемо винести в окремий модуль все, що пов'язано з книжками в domain-логіці, в інший модуль — все, що повʼязано з даними. Далі між цими модулями потрібно встановити правильні залежності та отримати гранульовані модулі. В них буде збережена необхідна логіка, яку доволі зручно тестувати та підтримувати. У цьому полягає рекомендація Google, і, забігаючи наперед, це досить вдале рішення. Принципи розподілення на модулі Про принципи SOLID знають усі досвідчені розробники — про них питають чи не на кожній технічній співбесіді. Вони допомагають правильно структурувати код, щоби можна було ефективно працювати. Роберт Мартін пропонує принципи звʼязності компонентів, які описують певні аспекти роботи з ними. В цьому контексті компонентом є певна сукупність класів, інтерфейсів. Варто звернути увагу на три принципи: REP (The Release / Reuse Equivalency Principle) — основна ідея полягає в тому, що компоненти мали окреме версіонування, щоб забезпечити повторне використання коду. Потрібно організувати класи у компоненти, які можна застосувати повторно, а потім відстежувати їх за допомогою релізу. Без номерів версій неможливо забезпечити сумісність усіх повторно використовуваних компонентів один з одним. CCP (The Common Closure Principle) — цей принцип вказує, які класи слід групувати разом. Багаторазові класи з більшою ймовірністю залежать один від одного, тому вони рідко використовуються окремо. CCP стверджує, що класи компонента повинні бути нероздільними. Це означає, що якщо один компонент залежить від іншого, то він має залежати від усіх його класів, а не від окремих з них. Коротко кажучи, класи, які не мають тісного зв'язку один з одним, не повинні зберігатися в одному компоненті. CRP (The Common Reuse Principle) — цей принцип вказує, що ми не повинні змушувати користувачів залежати від речей, які вони не збираються використовувати. Тому слід пам'ятати, що модулі в компоненті будуть використовуватися разом. Це означає, що ми маємо переконатися, що класи, які ми розміщуємо в компоненті, є нероздільними, адже неможливо залежати від одних і не залежати від інших. В іншому випадку ми будемо використовувати більше компонентів, ніж це необхідно. Ці принципи суперечать один одному, отже ми можемо дотримуватись лише двох з них або намагатися балансувати. Щоби зрозуміти, чому це складно, розглянемо їх попарно: CCP-REP є досить інклюзивними, намагаються зробити модулі більшими, відповідно збільшують зв'язність коду. Але CRP — ексклюзивний принцип, який дотримується тенденції зменшення модулів; CRP-REP — принципи, орієнтовані на повторне використання, прагнуть оптимізовувати модулі для тих команд, які їх використовують. З іншого боку, принцип CCP орієнтований на підтримку, оскільки прагне оптимізовувати модулі для тих, хто їх розробляє. Отже, ви маєте бути готовими зосередитись на двох підходах, відкинувши третій. Згідно з Робертом Мартіном, існує ще низка принципів, які стосуються саме залежностей. ADP (The Acyclic Dependencies Principle) — про циклічні залежності, а точніше їхню відсутність. Граф залежностей пакетів, модулів не може мати циклів. На схемі вище видно, що фіча С замикається на фічі А. В цьому випадку є два рішення: Використовувати окремий модуль із залежністю, від якого залежить С і А. Це рішення підходить, якщо використання цього допоміжного модуля не буде поодиноким випадком. Додати в модуль С певний інтерфейс, який дозволить комунікувати з фічею А через модуль :app. Рішення підходить для поодинокого випадку. SDP (The Stable Dependencies Principle) — принцип стабільних залежностей. Наприклад, ми маємо розповсюджені модулі для роботи з базами даних. Вони є стабільними, тому на них базується більша частина системи. Якщо певні модулі мають велику кількість використань, вони вважаються більш стабільними. Вся ієрархія залежностей має будуватися від найбільш стабільного до найменш. Тобто модуль :app завжди буде найменш стабільним, адже він змінюється від задачі до задачі, інкапсулюючи в собі частину логіки, яка потрібна для зведення певного функціонала навігації. SAP (The Stable Abstractions Principle) — абстракція підвищує стабільність. Йдеться про те, що ми завжди хочемо залежати від абстракції та змінювати тільки реалізацію певних компонентів у системі. Час збірки у модульній архітектурі Розглянемо наш граф залежностей в Gradle. Використання модулем :app фічі Reader — це ребро графу. Час збірки доволі сильно залежить від висоти нашого дерева. В холодній збірці ми спочатку збираємо найбільш стабільні модулі та розпаралелюємо побудову дерева за залежними модулями. Тобто спершу у нас будуватиметься модуль з ремоут-конфігами. Далі перебудовується модуль аналітики та паралельно створюється модуль з даними. Після цього будуватиметься модуль з фічею. Щоби зменшити кількість перебудов і покращити в цілому досвід розробки при модуляризації, важливо використовувати для великих фічей кешування залежностей Gradle. Якщо нам потрібно в модулі з аналітикою додати до фічі певний перелік івентів, то у нас будуть перебудовуватися майже всі фіче-модулі, залежні від аналітики. В таких випадках великі модулі потрібно виокремлювати, робити більш стабільними і використовувати певні залежності при необхідності або виносити публічне API. Це дозволяє зменшувати час збірки для багатомодульних проєктів і підвищує продуктивність розробки функціонала. Як ми починали роботу над модуляризацією Раніше наш проєкт можна було назвати монолітом. У ньому була виокремлена та розбита за шарами частина з data- та domain-логікою, а також стилі, графіка та дизайн системи. Через те, що ми не застосовували підхід із розділенням за фічами, така архітектура призводила до певних складнощів при збільшенні команди. Перша проблема, з якою ми стикнулися, розпочавши перехід на модульну архітектуру, — навігація. Якщо дотримуватись концепту, що всі фічі мають лежати на одному рівні та не залежати одна від одної, нам потрібно було знайти спосіб зводити виклики інших функціональностей. Для цього розділяли фічі по модулях, виносили навігацію та зводили її в модулі :app. Ми не користувалися стандартними рішеннями, запропонованими Google, а використовували власне рішення на базі підходу координаторів, адже потребували доволі гнучкої логіки у відкритті певних екранів і певних флоу, залежно від різних станів застосунку. Це дозволило сегрегувати запуск тестів на окремі модулі. Ми використовуємо підхід до модуляризації варіантів екранів або фічей. Чому це важливо в нашому контексті? Наприклад, в корені in-app модуля і payment-модуля можна викласти API для роботи з платежами, і на базі нього посилатися на певні фічі всередині in-app payment. Саме цей підхід вирішив проблему із залежностями під час A/B-тестування, а також дозволив більш ефективно зводити функціонал і зберігати ресурси окремо. Достатньо видалити умовно модуль з певним функціоналом і на цьому наша робота з прибиранням зайвого коду закінчена. Таким чином, ми зводимо до мінімуму ризики неправильної підчистки певних фічей, і це призводить до більшої стабільності. Наразі проєкт має близько 50-60 модулів, і процес модуляризації продовжується — найближчим часом плануємо розділяти data- та domain-логіку. Обираючи підхід для свого проєкту, враховуйте, що універсального рішення, яке підходить усім, не існує. Будуйте архітектуру так, щоби вона в першу чергу органічно підходила вашій команді. Корисні матеріали Martin Fowler, Presentation Domain Data Layering Robert C. Martin, Principles of OOD Robert C. Martin, Clean architecture Gergely Orosz, Building mobile applications at scale

Роль фронтенд-розробника полягає не лише у тому, щоби спроєктувати робочий інтерфейс, а й у тому, щоб бути сполучною ланкою між іншими командами. За необхідності, він розумітиметься і на дизайні, і на бекенді, і на продакт-менеджменті. Однак на цьому шляху є багато речей, які заважають робочому процесу та ускладнюють завдання. Про найбільш розповсюджені болі фронтенд-розробника розповідає Олесь Марола, Front-end Developer у Genesis Growth Team. Олесь понад чотири роки працює розробником, а у Genesis уже рік розробляє продукт для маркетологів. БІЛЬ №1 Фронтендери вищих ґрейдів стають «містками» між командами й витрачають на комунікацію багато часу та зусиль. Аби виконати об’ємне завдання, фронтенд-розробнику потрібно спілкуватися з багатьма сторонами — дизайнерами, бекенд-розробниками, тестувальниками, продакт-менеджерами тощо. Спочатку фахівець дізнається про всі особливості проєкту та взаємодії сам, якщо потрібно — ставить до відома продакт-менеджера. Однак кожна сторона має власні цілі, пріоритети та вподобання. Орієнтуватися серед різноманітних поглядів та шукати спільне може бути важко, особливо, коли ідеї або вимоги суперечливі. Непорозуміння призводять до затримок, перепрацювань і навіть конфліктів між командами — що тільки заважає розробці продукту. БІЛЬ №2 Необхідність працювати під тиском, у стислі терміни або з вимогами, які швидко змінюються. Фронтенд-розробка передбачає багато варіантів того, як можна реалізувати ту чи іншу задачу. Починається робота — і розробник працює за технічним завданням, але потім одержує фідбек від тимліда: все потрібно робити інакше. У мене був подібний кейс. Я почав працювати над завданнями певним чином, а коли пізніше зідзвонився з продакт-менеджером — виявилося, що пріоритети змінилися, й задачу потрібно робити взагалі інакше. Пара-трійка змін — і таска уже зовсім не така, як спочатку. Інша ситуація: розробник не уточнив ТЗ, самостійно додумав, як зробити краще, але у результаті код має велику складність, чого можна було б уникнути. Такі шматки коду в майбутньому буде дуже важко підтримувати. Робота в умовах нестабільності характерна для бізнесів на ранній стадії, яким треба якомога швидше запустити MVP. Колись нам потрібно було спроєктувати першу версію продукту — тобто, клієнтську частину, адмінку й бекенд — за два тижні. Через подібні історії проходить більшість молодих проєктів, яким треба налаштувати процеси, цикл розробки, комунікацію і т.д. Однак у стійкому продукті, що вже пару років на ринку подібних проблем буде менше. БІЛЬ №3 Необхідність забезпечувати сумісність з браузерами. Фронтенд-розробники мають переконатися, що їхній код працює коректно й виглядає узгоджено і в Google Chrome, і в Mozilla Firefox, і в Safari, і в Microsoft Edge, і в інших браузерах. Кожен з них має власний механізм рендерингу й може інтерпретувати HTML, CSS та JavaScript дещо по-різному. Те, що ідеально вписується в Chrome, може зламатися або відображатися інакше в Safari. Добре, що уже не потрібно підтримувати хоча б Internet Explorer. Проблема полягає не лише у відмінностях браузерів, а у їхніх різних версіях. Наприклад, якщо продукт нормально функціонує в останній версії Google Chrome — не факт, що він працюватиме в старіших версіях браузера. Буває так, що ми підтримуємо новіші версії, а потім приходить тестувальник, який робив регресії та перевіряв старіший гаджет, і виявляється, що все поламалося. Певний відсоток людей досі користується більш ранніми версіями браузерів, тому ми робимо застосунки й для них також. БІЛЬ №4 Продукт має виглядати гармонійно на різних пристроях і розмірах екранів, однак дизайн для всіх брейкпойнтів не роблять. Цей біль актуальний лише для розробників, які займаються версткою. Коли робиться дизайн, ніхто не «морочиться» з брейкпойнтами на планшети та інші нестандартні екрани. У найгіршому випадку проєктують тільки версію на десктоп, у кращому — варіант для мобайлу. Так, дизайнери малюють найбільший і найменший варіант, а проміжних немає. Інша проблема виникає, коли дизайнери працюють із не зовсім стандартними параметрами екрана. Наприклад, обирають висоту фрейму в Figma 900 пікселів. Здебільшого юзери мають гаджети з меншою висотою екрана, як-от 700 пікселів. І в такому випадку, контент з оцих 200 пікселів, просто не вміщається, а тестувальники приходять з питаннями до фронтендера. Тоді розробник має самостійно робити адаптиви для різних екранів. На перший погляд, це простіше та швидше, ніж намалювати декілька різних екранів. Однак для фронтендера це додаткове завдання та час, який він міг би витратити на розробку іншого функціоналу. БІЛЬ №5 Підтримувати чистий код у проєктах зі зростаючою складністю не завжди виходить. Особливо, коли над ним працюють понад три людини. Коли коду бракує ясності, командна робота дуже ускладнюється. Якщо база обростає дублікатами, застарілими шматками або неактуальними коментарями, то у майбутньому це може спричиняти проблеми з масштабуванням. Наприклад, щоб розробити нову фічу, код потрібно буде не просто змінити, а переписати. Через це завдання, що мало зайняти годину, розтягується на всі чотири. Крім того, така база ускладнює залучення новачків до проєкту. І він, і тимлід витрачатимуть час і зусилля на занурення у процес — а продуктивність страждатиме. В ідеальному світі на проєкті має бути архітектурний підхід, а всі шорсткості виправляються рефакторингом коду. Однак тут є інша проблема: на це не завжди є час, тож завдання ризикує перекочувати до категорії «ми колись до цього повернемося». БІЛЬ №6 Кодова база проєкту застаріла, їй бракує належної документації або документації загалом. Проблема, яка пов’язана з попередньою. Якщо чистий код працює без збоїв, написаний у єдиному стилі, добре задокументований та відформатований, то застаріла кодова база призводить до труднощів у імплементації рішень, збільшення часу подальшої розробки, складнощів оновлення ПЗ тощо. Наслідки можуть відчуватися не одразу, а за кілька місяців чи навіть років, коли вже вийшла купа мажорних апдейтів, оновилися технологічні пакети й додалися нові бібліотеки. Відрефакторити великий проєкт майже неможливо. Ще більше ускладнює проблему неактуальна документація. Розробникам доводиться витрачати багато часу на розшифровку архітектури системи, структури коду тощо. Колись нашій команді дістався подібний проєкт «у спадок». Спочатку здається, що все зроблено добре, а потім настає час оновлювати код або додавати якийсь функціонал — а це довго й боляче. БІЛЬ №7 Дизайнери роблять макети, але деякі елементи не працюють так, як їм би хотілося. Під час проєктування клієнтської частини важливо пам’ятати: інтерфейс повинен не лише мати гарний вигляд, а й працювати певним чином. Однак деякі дизайнерські рішення дуже важко перенести та реалізувати так, щоби вони гармонійно виглядали в коді, у верстці, а ще — коректно відображалися на різних гаджетах. Як і дизайнер, розробник добре розуміється на UI, але завдяки знанням у програмуванні здатен помітити недоліки ідеї, які заважатимуть реалізації. Саме по собі рішення може бути вдалим, але воно не працюватиме так, як задумувалося. Або ж під нього доведеться писати тонну коду, який буде важко масштабувати та підтримувати в майбутньому. Якщо дизайнер не впевнений у можливості реалізувати якесь рішення, краще проконсультуватися з розробником заздалегідь. Інакше останньому доведеться самому переробляти макет та шукати рішення, що займатиме багато часу.

Згідно з опитуванням освітнього департаменту Genesis, 95% студентів українських ЗВО відчувають нестачу практичної складової в навчальних програмах. Тому університети активно запрошують до викладання спеціалістів із індустрії. Проте читати курс на постійній основі та одночасно будувати карʼєру — складно. Щоби підсилити академічну експертизу бізнес-досвідом, освітній департамент Genesis допомагає зацікавленим співробітникам створювати навчальні дисципліни та запускати курси в університетах-партнерах. Прийти на пару до студентів та викласти матеріал — лише вершина айсберга. «Під водою» — багато годин додаткової роботи, частину якої бере на себе команда Genesis Education. Андрій Скрипник, СЕО Promova, Олег Лавренко, СТО в AMO, та Олесь Дібрівний, Unity Developer в Keiki, розповіли, як повернулися до аудиторій університетів, щоби викладати. Вони описали, яким ключовим скілам намагаються навчити своїх студентів, що в цьому процесі найскладніше та чому масштабували викладання на свою команду. Як полегшити життя розробникам-викладачам та зекономити їм до 15 годин щотижня, поділилася Каріна Плахотнюк, Education Project Specialist в освітньому департаменті Genesis. Чи можна викладати без бюрократії Менеджер освітньої програми допомагає тим, хто вже викладає в ЗВО, а також залучає нових спеціалістів із сильною експертизою. Якщо у когось з потенційних лекторів немає відповідного наукового ступеня, щоби самостійно вести курс, освітня програма запускається спільно із представником університету. «Наша команда намагається створити такі умови, щоб лектори могли сфокусуватися суто на викладенні матеріалу та перевірці знань. Для цього треба зняти зайве навантаження — від багаторівневих погоджень програми, допомоги з веденням документації до комунікації з кафедрою та студентами. Так нам вдається зекономити нашим лекторам багато годин щотижня», — Каріна Плахотнюк, Education Project Specialist. З 2019 року Genesis Education інтегрувала 20 дисциплін в освітній процес КНУ імені Тараса Шевченка, КПІ ім. Ігоря Сікорського та Києво-Могилянської академії у напрямах iOS, DevOps, Back-end, GameDev, Product & Business Analytics. Загалом до викладання долучилися близько 50 спеціалістів з екосистеми бізнесів Genesis та компаній-партнерів. Про відрахування, три формати навчання та соціальний борг У старших класах мені довелося змінити школу через переїзд у Київ. У новому закладі рівень викладання був значно нижчий, тому мені стало нецікаво, і я почав працювати на фрилансі. Повністю сфокусувавшись на перших проєктах, я розлінився вчитися. З цим настроєм вступив до КПІ на ФІОТ, де очікував, що мені все будуть закривати, як і до цього. Звідти мене відрахували після першого ж семестру, про що заступник декана повідомив лише після двох тижнів нового семестру. Я ходив на пари та навіть не знав про відрахування. Наступного року я знову склав вступні іспити та поновив навчання. Працюючи ще зі школи в розробці, я міг порівняти те, що викладають, з реальними завданнями в продакшені. Ми постійно жалілися на те, що не вистачає лекторів-практиків, які б давали актуальні знання. Коли я закінчив магістратуру 2017 року, мені зателефонувала та сама людина, яка шість років тому мене відрахувала, і запропонувала викладати мобільну розробку на ФІОТ. Я сказав, що подумаю, хоча в ту ж секунду розумів, що моя відповідь — «так». По-перше, це було цікаво. По-друге, повернути знання до альма-матер я вважав своїм соціальним боргом. По-третє, я стільки років шкодував про нестачу викладачів-практиків, відмовитись від цієї пропозиції було б лицемірством. Для мене КПІ — це особливе місце, де можна доторкнутися до чогось давнього та стати частиною великої історії. Більшість бюрократичних та організаційних питань з відомостями, розкладами, погодженням мені допомагали закривати на кафедрі. Моїми завданнями було прийти, прочитати лекцію, відповісти на запитання, перевірити знання та прийняти іспит в кінці семестру. З 2019 року з менеджментом курсу допомагала команда Genesis Education. Головний секрет усіх публічних спікерів: у той момент, коли ти починаєш готувати матеріал, тобі здається, що ти повний нуль у цій темі. Тоді шукаєш інформацію, читаєш, глибше розбираєшся. Це і було моєю мотивацією: покращувати знання в тому, що я любив. Для мене це був win-win: я навчаю й одночасно навчаюся сам. Курс, який я читав, був спеціалізованим з фокусом саме на iOS. До 3-4 курсу студенти зазвичай обирали спеціалізації (бекенд / фронтенд / геймдев), тому тих, кого цікавила саме мобільна розробка, було не так багато — до 30%. Я пропонував студентам обʼєднуватись у проєктні групи та створювати мобільні застосунки в команді, де кожен виконував свою частину роботи. Наприкінці курсу вони захищали свої проєкти. За весь час я відрахував десь трьох-п'ятьох людей через те, що вони нічого не робили. Коли ти весь семестр не ходиш, не здаєш жодної роботи, а потім приходиш на другу перездачу іспиту і питаєш, чи можна щось встигнути зробити, так нічого і не підготувавши, відповідь: «Ні, вибач, не можна». Один з найважливіших скілів розробника — швидко знаходити інформацію. Не можна знати всього, але треба мати загальне уявлення, передбачати майбутні кроки та вміти шукати відповіді. Цьому я і навчаю студентів. З початком карантину навчання перейшло в онлайн. Тоді ж проєкт Promova почав стрімко зростати, і робоче навантаження значно виросло. Ми спробували показувати лекції в записі та додатково проводили інтерактиви, Q&A-сесії та офлайн-зустрічі. Це було три різних досвіди, найкращим з яких вважаю офлайн. Раніше я багато програмував та брав участь у розробці особисто. Останні два роки роль СЕО потребує все більше менеджерського часу, і приділяти достатньо уваги технічній стороні вже не можу. Відповідно читати деякі лекції запрошую колег-розробників із Boosters, а сам закриваю інші питання та паралельно міркую над новим курсом, більш релевантним до того, чим я займаюся сьогодні. Якщо викладати те, з чим ти не працюєш постійно, це перейде в той самий формат, на який я жалівся, коли був студентом. Про масштабування, несподівані запитання та студентські дедлайни Перший досвід лектора я отримав всередині команди: розповідав девелоперам про інфраструктуру, а тестувальникам та DevOps-інженерам — про розробку. Це підвищило ефективність команди, і я почав масштабувати досвід — викладати в рамках внутрішніх і зовнішніх освітніх програм з командою Genesis Education. Згодом — вже в університетах. Один із викликів — «запакувати» у 16 лекцій предмет, який вивчають роками. Я намагаюся не давати занадто складних штук. Головне, щоби слухачі отримали загальне розуміння та контекст, що це за дисципліна, для чого вона потрібна, і що треба надалі вивчити, щоби реалізуватися в цьому домені. Прогрес завжди видно по студентах: спочатку їм взагалі нічого не зрозуміло, а з кожною наступною лекцією — лише точково. Перед запуском курсу я морально готувався, що не всім буде цікаво. Але після першої лекції не очікував, що так багато студентів будуть уважно слухати та ставити багато запитань. Якось на одній з лекцій про життєвий цикл софта ми розглядали різні підходи колективної розробки в рамках одного репозиторію. В одному з флоу від студентів прилетіло питання: а як керувати стейтментом бази даних, маючи лише одну гілку, щоби нічого не зламалося? Це дуже влучне питання рівня advance, яке мене приємно вразило. Довелося поміркувати, перш ніж дати відповідь. Питання з «домашками» — це те, що мене веселить і спантеличує одночасно. На кожному курсі ми чуємо класичні «відмазки» на кшталт «у мене боліла нога», «возив кота бабусі мого друга до ветеринара» тощо. Коли на роботі хтось з команди не вклався в дедлайн, знаєш що робити, а зі студентами — ні. З одного боку, не хочеться їх демотивувати, а з іншого — їм корисно знати, що таке дедлайн. Спочатку я викладав самостійно, а потім із командою вирішили, що було б корисним челенджем розширити викладацький склад. Так, минулого року ми прочитали два великих курси, який викладали 10 людей з AMO. Участь в наймі, співбесідах та перевірка тестових завдань — суттєва складова роботи на менеджерській позиції. Часто помічаю, що кандидати можуть виконувати певні задачі, але не мають глибини розуміння теми, не вміють працювати з оптимізацією, переосмислювати процеси. Умовно вони знають один інструмент та «затикають ним усі діри». В ІТ це працює не так. Замість чергового фреймворку важливіше розібратися в Computer Science та інших фундаментальних речах. Тому викладання для мене — це інвестиція в те, щоби вивести ІТ в Україні на новий рівень. А якщо пощастить, колись я побачу на співбесіді свого колишнього студента, який розумітиме інженерну культуру нашої компанії. Про здобуття PhD, відмову від теорії та досягнення студентів Моя історія викладання почалася ще до того, як я став розробником. В аспірантурі Державного університету телекомунікацій, де я навчався, викладання — одна з вимог. Протягом першого семестру я викладав C# та технічну англійську, з наступного року — Unity. У мене було близько шести пар на тиждень: я читав лекції для чотирьох груп, проводив практичні, лабораторні та приймав іспити. Фактично це була фултайм-робота. Паралельно я писав дисертацію за спеціальністю «Компʼютерна інженерія». Викладаючи, я швидко та глибоко занурювався в матеріал. Це дало змогу невдовзі знайти роботу в геймдеві та посилити експертизу практикою. Цього року разом з командою Genesis Education ми запустили курс з геймдеву в КПІ. В ньому я не відповідаю за організаційні моменти та не комунікую з університетом, тому стало значно легше. Щороку я переробляю курс. Причина не в тому, що інформація застаріває, а скоріше через перфекціонізм. Постійно практикуючи свій предмет, я вивчаю нові підходи, прокачую знання, і хочеться ділитися цим зі студентами. Згадую перший семестр, і стає дещо соромно за рівень матеріалу — зараз здається, що я давав недостатньо практики, оскільки ще не працював в цій сфері повноцінно. Коли зростаєш як розробник, у тебе змінюється думка, що потрібно студентам. Згодом я зосередився на практичних заняттях, адже специфіка предмета в тому, що одразу треба пробувати писати код. Курс побудований таким чином, що в кінці семестру студенти створюють власні ігри. Найцікавіше у викладанні — спостерігати прогрес студентів. Дуже радію, коли вони знаходять роботу за спеціальністю або беруть участь в геймджемах і показують там високі результати. Один зі студентів якось зробив хороший піксельний арт, і в нього вийшла дійсно крута гра. Але навіть найбільш мотивованим студентам треба не давати розслаблятися, бо вони швидко стають лінивими. Найскладніше — знайти в собі мотивацію викладати, якщо студенти цього не хочуть. Чим кращим професіоналом ти стаєш, тим більшим стає барʼєр зі студентами, адже складні речі здаються простими. Я регулярно питаю, чи підходить їм швидкість викладання матеріалу, намагаюся адаптуватися під них. Найпоширеніше питання студентів: «Я зробив так само, але воно не працює. Чому?». Також вони часто питають про нові технології, з якими я не знайомий. Річ у тім, що більшість оновлень в Unity випускаються доволі «сирими», і протягом перших кількох років їх не використовують в проєктах. Студенти дуже люблять слідкувати за ними. Як заощадити лектору до 15 годин на тиждень. Задачі менеджера освітньої програми Менеджмент освітнього процесу займає значно більше часу, ніж сам освітній процес. Він починається не з підготовки до першої лекції, а мінімум за дев'ять місяців до цього. Щоби запустити курс, компанія має пройти попередні етапи та заручитися підтримкою університету загалом та окремих факультетів. Для проходження цієї процедури в Genesis створена окрема команда. Вона знайомиться з факультетом, обговорює спільні цілі, шукає точки дотику між експертизою компанії та предметами, що викладаються. Надалі укладається договір про співпрацю з університетом та починається комунікація з гарантами освітніх програм, завідувачами кафедр та адміністраціями факультетів. Якщо все складається успішно, далі команда проходить етапи погоджень, планування та оформлення відповідної документації, перш ніж лектор зможе прийти до студентів та поділитися знаннями. Етапи запуску навчального курсу: Етап 0. Знайомство з університетом, попередні переговори та підписання меморандуму про співпрацю. Етап 1. Визначення точок дотику, де практична експертиза спеціалістів компанії доповнюватиме академічну складову університетських програм. Планування навчального року та затвердження курсу. Етап 2. Планування дисципліни та підготовка програми (вивчення ринку, створення плану, погодження з лекторами). Етап 3. Допомога з методичною документацією для ЗВО та студентів. Етап 4. Підготовка навчальних та методичних матеріалів (презентацій до лекцій, домашніх завдань, лабораторних), погодження з представниками університету. Етап 5. Організація зручних форматів комунікації між студентами, викладачем та менеджером (створення чатів, розсилок, роадмапів, налаштування платформ — GitHub, GitLab, Classroom тощо). Етап 6. Знайомство зі студентами, встановлення «правил гри», написання інструкцій. Етап 7. Запуск та ведення курсу. Етап 8. Моніторинг. Етап 9. Підбивання підсумків й закриття відомостей. Етап 10. Ретроспектива та аналіз результатів. Лектор-експерт від компанії залучається до створення актуальної програми та підготовки презентацій. Менеджер проводить глибоке дослідження, який матеріал викладається у міжнародних університетах та комерційних курсах. Оскільки спільні навчальні програми ми запускаємо з 2019 року, то можемо аналізувати попередній досвід та опитувальники студентів. З цим дослідженням менеджер приходить до лектора, і ми фіналізуємо програму. Концепція програми може валідуватися з викладачами та спеціалістами кафедри університету. Протягом останніх років заняття перейшли в онлайн. Тому завдання менеджера — подбати про запис відео та публікацію в правильних джерелах, організацію стримінгу, підключення техніки, за потреби — монтаж та корекцію звуку. Усі студенти мають вчасно отримати посилання та доступи. Менеджер бере на себе усю комунікацію зі студентами, відповідаючи на численні запитання: «коли лекція», «яке домашнє завдання», «я забув здати лабораторну, що мені робити», «у мене не відкривається посилання», «а де знайти матеріали», «а коли будуть результати тестів» та багато інших. Часто студенти питають одне й те саме, адже вони доволі неуважні. Цей шквал запитів важливо систематизувати. Якщо у викладача від компанії є потреба, менеджер може допомогти йому підготуватися до виступу, зробити кілька прогонів лекції або допомогти опрацювати фідбек студентів. Наприкінці кожного семестру команда проводить ретроспективу та підбиває підсумки. За кілька років шляхом проб і помилок ми знайшли справді зручний формат онлайн-освіти з використанням сучасних інструментів. Протягом навчального семестру, менеджер допомагає із документацією в частині, погодженій з кафедрою: ​оформлення тематичних планів, шкал оцінювання; написання анотації до дисципліни на платформі; заповнення усіх відомостей, виставлення балів, звіряння зі списками; написання невеликих звітів для кафедр чи координаторів після закінчення курсу. Якби розробник робив усе це самостійно, це б займало близько 15-20 годин на тиждень. Завдяки залученню менеджера вдається скоротити цей час до 3-5 годин. Це дає змогу залучати до викладання спеціалістів високого рівня з унікальною експертизою. Від освіти, яку сьогодні отримують студенти технічних спеціальностей, залежить те, як виглядатиме ІТ-індустрія України за 10 років. Розуміючи це, Genesis системно інвестує в освітні програми ресурси та час найкращих спеціалістів Senior- та C-level. Вони готові дати студентам те, чого самі не отримали в університетах — сучасні практики розробки та експертизу розвитку ІТ-продуктів на глобальних ринках.

Коли тільки набиваєш руку у програмуванні, важлива швидкість: чим скоріше розробник початківець опанує всі необхідні технології, тим швидше зможе братися до комерційної роботи. Розвиток розробників з досвідом дещо відрізняється. Тут ефективніше заглиблюватися в окремі аспекти розробки, відточувати уже наявні знання та заповнювати прогалини. Що почитати в першому та другому випадках? Зібрали об’ємний список із 15 книжок разом з Марією Образцовою, Frontend Developer в Universe з екосистеми Genesis. Марія вже близько 2 років працює в команді Universe. За цей час вона розвивала освітню платформу Wisey, а сьогодні працює над новим вебпродуктом. > «Head First. Програмування на JavaScript». Ерік Фрімен, Елізабет Робсон > «Розумніший спосіб вивчати JavaScript». Марк Майєрс > «JavaScript для дітей. Веселий вступ до програмування». Нік Морган > «Як влаштований JavaScript». Дуглас Крокфорд > «Javascript та jQuery. Інтерактивна веброзробка». Джон Дакетт > JavaScript.Info > «JavaScript: The Definitive Guide» by David Flanagan > Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People by Aditya Y. Bhargava > High Performance JavaScrip by Nicholas C. Zakas > «You Don’t Know JS» by Kyle Simpson > «Effective JavaScript» by David Herman > «Modern JavaScript for the Impatient» by Cay Horstmann > «JavaScript Patterns: Build Better Applications with Coding and Design Patterns» by Stoyan Stefanov > «Maintainable JavaScript» by Nicholas Zakas > «Programming JavaScript Applications: Robust Web Architecture with Node, HTML5, and Modern JS Libraries 1st Edition» by Eric Elliott > Як вчити JavaScript за книжками Для початківців ЕРІК ФРІМЕН, ЕЛІЗАБЕТ РОБСОН «Head First. Програмування на JavaScript» Англ: Head First JavaScript Programming: A Brain-Friendly Guide by Eric Freeman, Elisabeth Robson Об’ємний посібник, де зібрана ключова інформація про JavaScript: від основ до складніших тем — типів, масивів, функцій, об’єктів та DOM. Зачіпають також успадкування прототипів та тестування продуктів. Переваги: книга гарно підійде для людей, що люблять вікторини, головоломки та вправи для закріплення матеріалу; послідовна структура, що дозволяє засвоїти простіші теми, перш ніж перейти до складних. Недоліки: інформації про популярні фреймворки та бібліотеки JS майже немає; деякі матеріали можуть бути не актуальними. МАРК МАЙЄРС «Розумніший спосіб вивчати JavaScript» Англ: A Smarter Way to Learn JavaScript by Mark Myers Посібник для початківців із акцентом на розуміння та запам'ятовування правильного синтаксису. Книжка будується на постійному закріпленні теоретичних знань через велику кількість додаткових завдань. Як обіцяє Марк Майєрс, на практику йде у два-три рази більше часу, ніж на читання. Переваги: інформацію подають невеликими «порціями» — середньостатистичний учень зможе засвоїти один розділ за 10 хвилин; є сайт із вправами для кожного розділу, де можна попрактикуватися й закріпити все, про що ви дізналися; матеріал пояснюють простою нетехнічною англійською мовою. Недоліки: деякі поняття можуть бути не актуальними. НІК МОРГАН «JavaScript для дітей. Веселий вступ до програмування» Англ: JavaScript for Kids: A Playful Introduction to Programming by Nick Morgan Попри те, що книга орієнтована на дітей, вона може слугувати хорошим посібником для початківців будь-якого віку. Розповідь починається з основ, таких як робота з рядками, масивами та циклами, а далі автори переходять до складніших тем — наприклад, створення інтерактивності з jQuery та малювання графіки за допомогою Canvas. «Це зовсім базове видання, де початківці можуть ознайомитися з синтаксисом та базовими поняттями мови», — каже Марія Образцова. Переваги: мова викладання проста та зрозуміла; книжка дає достатньо знань, щоби самостійно розробити просту гру, зокрема Find the Buried Treasure, Hangman чи Snake; швидкий спосіб розібратися, чи подобається вам програмування загалом — і як процес, і як результат. Недоліки: деякі технології, наприклад, Canvas, можуть бути неактуальними для стека комерційної розробки; деякі приклади з книги не працюють так, як описано. ДУГЛАС КРОКФОРД «Як влаштований JavaScript» Англ: JavaScript: The Good Parts by Douglas Crockford Існує думка, що JavaScript має більше недоліків, ніж переваг. Однак Дуглас Крокфорд, який відіграв значну роль у розвитку JS, звертає увагу на іншу, «хорошу» частину мови — надійну, читабельну, підтримувану, придатну для створення масштабованого та ефективного коду. Так, у книжці пояснюється робота із синтаксисом обміну, функціями, методами, масивами, регулярними виразами тощо. «На початку складно зрозуміти, що саме вчити, на чому зосереджуватися. Ця книжка допомагає не витрачати ресурс на пошук базової теорії в різних місцях, а дає впорядковану й доступну інформацію», — каже Марія Образцова. Переваги: розбір вдалих прикладів та помилок — з поясненням, як їх уникати; «сухої» теорії небагато, й вона добре структурована. чимало прикладів з досвіду автора. Недоліки: деякі приклади абстрактні, їх важко пов’язати з реальним програмуванням. подекуди інформація може бути заскладною, і не вистачає авторської думки та пояснень. ДЖОН ДАКЕТТ «Javascript та jQuery. Інтерактивна веброзробка» Англ: JavaScript & JQuery: Interactive Front-End Web Development by Jon Duckett Книжка насичена візуальними матеріалами. Вони дозволяють краще відчути, як зробити вебсторінки більш інтерактивними, а інтерфейси — більш інтуїтивно зрозумілими. Автор на прикладах показує, як з нуля проєктувати сценарії JavaScript, JavaScript API, а також jQuery. Щоби ефективно опрацювати книжку, знадобляться базові знання HTML та CSS. Переваги: проста та зрозуміла мова; багато візуальних елементів роблять взаємодію з книгою цікавішою. Недоліки: трапляються приклади з помилками, яких новачки можуть не помітити. JavaScript.Info (англ. та укр.) Онлайн-підручник із сучасного JavaScript, що містить прості, але докладні пояснення з прикладами та завданнями. Є інформація про замикання, DOM, події та об'єктно-орієнтоване програмування. «Це не зовсім книжка, але сайт можна прирівняти до повноцінного посібника по JS», — каже Марія. «По структурі він як звичайне видання: розділений на три великі блоки та маленькі глави у них. Довідник влаштований так, що при послідовному читанні знання нашаровуються одне на одне — і уявлення про мову стає більш комплексним. Я багато користувалася ним, коли вчила JavaScript, але до нього можуть звертатися і мідли, і сеньйори, якщо потрібно освіжити знання», — додає розробниця. Для мідлів та сеньорів DAVID FLANAGAN «JavaScript: The Definitive Guide» Книга стане справді настільним довідником, адже охоплює всі нюанси роботи з мовою — від основних операцій зі значеннями різних типів до рушіїв. Серед інших понять, які охоплює автор — замикання, графіка та прототипування, а також суміжні з JS теми, як-от регулярні вирази й Node.js. Переваги: актуальна та сучасна інформація — автор сім разів перевидавав книгу, аби вдосконалити кожен розділ; пояснення підійдуть як для тих, хто працює з клієнтською версією JS, так і для тих, хто використовує серверну; багато релевантних прикладів. Недоліки: у книзі висвітлено ВСЮ мову: і сучасні підходи, і застарілі концепції, які уже не використовуються (однак автор говорить про це); місцями книжка заскладна та дуже деталізована. ADITYA Y. BHARGAVA Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People Книжка не висвітлює безпосередньо JavaScript, але вважається одним з найкращих видань про алгоритми та структуру даних. Вона складається з 11 розділів, де йдеться про сортування, рекурсію, хештаблиці, зв’язані списки, а також динамічне програмування. «Її корисно прочитати як джунам, так і мідлам та сеньйорам, які прагнуть зробити свої програми більш логічними», — каже Марія. Переваги: проста та зрозуміла мова, поняття введені у контекст; малюнки допомагають краще уявити структуру роботи алгоритмів та структур даних; багато прикладів. Недоліки: мало уваги приділено структурам даних, які є аналогами алгоритмів, як-от бінарне дерево, бінарне дерево пошуку, трійки тощо; тема про динамічне програмування розкрита не повністю. NICHOLAS C. ZAKAS «Нigh Performance JavaScript» Динаміка сайтів будується в основному на JavaScript — і це одна з найцікавіших частин роботи з мовою. Втім, є мінус — через це сторінки можуть завантажуватися повільніше або взагалі не працювати, що погіршує User Experience. Книжка допомагає зрозуміти фактори, що негативно впливають на продуктивність, та пропонує прийоми й лайфхаки, які допомагають усунути проблеми. Переваги: багато важливої інформації про обробку даних та об’єктів; описаний досвід об’ємний та цікавий, адже Ніколас Закас долучив до написання рок-зірок програмування — Росса Хармса, Жульєна Леконта, Стівена Левітана, Стояна Стефанова та Метта Суїні. Недоліки: деякі підходи зводяться до шаблонів програмування, які не є унікальними для JavaScript; частина порад уже застаріла. KYLE SIMPSON «You Don’t Know JS» (англ.) Серія складається з шести книг, які слід читати послідовно. Так, перша книжка, «Up & Going» охоплює основи мови, включаючи типи, значення та змінні. Друга — «Scope & Closures» — заглиблюється в роботу системи області видимості JavaScript, і в те, як працюють закриття. Останні підручники серії працюють зі складнішими поняттями. Наприклад, п’ята книга, «Async & Performance», присвячена асинхронному програмуванню та оптимізації продуктивності, а остання «ES6&Beyond» розповідає про нові можливості, представлені в ECMAScript 6 та пізніших версіях мови. «Я зверталася до одного з видань, коли розбиралася в об’єктах і класах. Теорія описана досить просто та зрозуміло. Крім того, там є нюанси, які цікаво дізнатися для загального розвитку, і які ти не вивчаєш, коли треба швидко опанувати мову, щоб виконувати робочі завдання», — каже Марія. Переваги: кожна книга написана під певний рівень знань; завдання та приклади релевантні до реальної роботи розробника; численні приклади коду з докладними поясненнями. Недоліки: подекуди інформація може бути застарілою. DAVID HERMAN «Effective JavaScript» (англ.) Девід Херман, який багато років працює над стандартизацією мови, надає 68 перевірених підходів до написання кращого коду на JavaScript. Він пояснює нюанси роботи з масивами та об’єктами, особливості ООП, функції та семантику змінних — та підкріпляє теорію конкретними прикладами. Переваги: містить інформацію, щоб заповнити прогалини у фундаментальній теорії JavaScript; насичена прикладами з особистої практики автора, а також рекомендаціями для створення застосунків різного масштабу. Недоліки: іноді пояснення написані заскладною мовою. CAY HORSTMANN «Modern JavaScript for the Impatient» (англ.) Вичерпний посібник із JavaScript ES6 та сучасніших версій мови, де зібрано практичні рекомендації та зразки коду. Книжка допомагає ефективно використати всі новинки JavaScript, уникаючи помилок і застарілого синтаксису. Книга підійде для тих, хто вже працював з іншими мовами та хоче швидко зрозуміти JavaScript. Переваги: можливість опанувати сучасний стандарт JS без занурення у старіші версії; «ігрова» система навігації з натяком на «Алісу в Дивокраї». Картинки позначають складність розділів: Білий Кролик — основи, Аліса — матеріали середнього рівня складності, Чеширський кіт — просунуті теми, Капелюшник — теми «із зірочкою» для найбільш зацікавлених. Недоліки: матеріал викладено не зовсім послідовно: спочатку деталі, потім загальна картина; інформація про відмінності JS від інших мов надається лише в третьому розділі. STOYAN STEFANOV «JavaScript Patterns: Build Better Applications with Coding and Design Patterns» (англ.) Як видно з назви, основна тема книжки — шаблони проєктування для масштабованого та якісного коду. Як класичні, так і досить специфічні. Крім того, Стефан Стоянов наводить способи обійти недоліки мови. Видання буде корисним, якщо ви — досвідчений розробник, який прагне розв’язати проблеми, пов’язані з об’єктами, функціями, успадкуванням та іншими специфічними для мови категоріями. Переваги: практичні та детальні поради щодо реалізації кожного розглянутого шаблону; автор застерігає від практик, які створюють більше проблем, ніж вирішують, та описує їх; корисна і тим, хто використовує JS для клієнтської частини, і тим, хто працює з серверною. Недоліки: застарілий синтаксис. NICHOLAS C. ZAKAS «Maintainable JavaScript» (англ.) Командна розробка вимагає уніфікованого підходу до програмування, впевнений Ніколас Закас. Колись він був солорозробником, пізніше — став Tech Leader в Yahoo! Маючи різноплановий досвід, він ділиться низкою порад — про стиль коду, програмування та автоматизацію. Рекомендації дозволяють всім охочим навчитися писати код, з яким буде комфортно працювати іншим членам команди. Переваги: видання об’єднує багато різних матеріалів у своєрідну дорожню карту та структурує їх; корисно для команд, які працюють із масштабними проєктами на JavaScript. Недоліки: деякі приклади можуть бути занадто простими для досвідчених розробників. ERIC ELLIOTT «Programming JavaScript Applications: Robust Web Architecture with Node, HTML5, and Modern JS Libraries 1st Edition» (англ.) Буває так, що внесені зміни в одній частині коди впливають на роботу застосунку в зовсім іншому місці, або взагалі його ламають. Ерік Еліот вчить писати стійкий код, з яким буде легше працювати в міру зростання кодової бази. Він показує, як додавати клієнтські та серверні функції до масштабних вебзастосунків на JavaScript без негативного впливу на решту коду. Переваги: описано багато сучасних технологій — як відомих, так і не дуже популярних; багато прикладів із фрагментами коду; ґрунтовний огляд способів створення надійної архітектури вебзастосунків. Недоліки: деякі методи та підходи описані без оцінки автора та прикладів використання, тому важко зрозуміти, до якого контексту підходить та чи інша технологія; досить вузька цільова аудиторія. Найкориснішою вона буде для архітекторів вебзастосунків. Як вчити JavaScript за книжками Чимало інформації можна нагуглити, але вона невпорядкована та непослідовна. У книжках автори цю проблему вирішують. Втім, на початковому етапі самих лише книжок недостатньо, впевнена Марія Образцова. «Я б радила поєднувати читання з пошуком актуальної інформації, переглядом статей та документації. При цьому книжку не обов'язково читати від початку до кінця. Можна просто скористатися її змістом як переліком тем до вивчення, а далі гуглити матеріали для кожної з них. Або читати окремі розділи, наприклад, про складніші концепції програмування», — каже вона. На більш просунутому етапі варто обирати літературу, що стосується верхньорівневих концепцій та речей, які змінюються не так часто, як синтаксис. «Розробники, що працюють з JS, спочатку користувалися класами. Але в якийсь момент підхід змінився — і всі перейшли на функції. Глобально мова залишилася такою ж, але програми тепер пишуться трохи інакше. Багато прикладів зі старіших книжок можуть бути нерелевантними, тож за ними ефективніше вивчати алгоритми та підходи до написання програм. Такими є, наприклад, книги Ніколаса Закаса — там мало про синтаксис, і багато про мову загалом», — говорить Марія. Вона додає, що зараз користується книгами більш вибірково та усвідомлено. «Якщо мені радять книжку і кажуть, що там добре описано певний алгоритм, то я беру і читаю конкретно про цей алгоритм. На жаль, читати книги повністю немає часу, а подібний метод дає змогу швидко та ефективно заповнити прогалини в знаннях».

Наприкінці 2022 року Apple запропонувала команді Boosters з екосистеми Genesis оптимізувати застосунок для покращення сну Avrora під Apple Watch в межах програми AppleLab. Остання дозволяє розробникам переймати найкращий досвід техногіганта — використовувати найновіші технології, консультуючись із дизайнерами та інженерами Apple. Попри те, що Avrora уже мала аналог під watchOS, застосунок розробили з нуля — за три місяці. Про всі нюанси процесу, співпрацю з Apple та особливості розробки продукту для смартгодинника розповідає Богдан Бессараб, продакт-менеджер в Boosters. За півтора року в Genesis Богдан попрацював з мобільними та вебзастосунками, а віднедавна — і з продуктами для Apple Watch. Пропозиція, від якої неможливо відмовитися Ідея від Apple була пов’язана з оновленнями технології трекінгу сну. Після релізу iOS 16 та watchOS 9 компанія дала розробникам змогу збирати та використовувати відповідні користувацькі дані, зокрема показники фаз сну. Є три типи продуктів, які можна розробити для Apple Watch: Dependent watchOS app працює в парі з застосунком на iPhone та залежить від нього у своїй роботі; Independent watchOS app може працювати самостійно на годиннику Apple Watch та не залежить від iPhone; Standalone app призначений спеціально для годинників Apple Watch та може не мати аналога на iPhone. Два роки тому ми вже розробили Dependent watchOS app. Застосунок працював як віддалений контролер для iOS-додатку та дозволяв юзерам коригувати типи контенту в апці. Зараз завдання полягало у створенні окремого продукту для Apple Watch із використанням нових можливостей від платформи. Спочатку ми думали робити Standalone, однак представники Apple порадили обрати варіант Independent. Рішення справді стало більш виграшним, адже дає кращі можливості для дистрибуції застосунку. Жорсткого дедлайну нам не ставили, однак ми розуміли: чим швидше впораємося, тим краще. Розробка продукту тривала три місяці. Працювали командою з п’ятьох людей — двох iOS-розробників, продакт-дизайнера, тестувальника та продакт-менеджера. З чого складається продукт Проєкт почали зі створення макета нового застосунку. Ми накидали основний функціонал — всього вийшло шість частин: Main Screen — основний екран. Sleep Ritual — медитації, дихальні вправи та calming sounds. Sleep Data — дані, які ми отримуємо, обробляємо та показуємо користувачу. Smart Alarm — будильник, який допомагає користувачу легко прокидатися у швидкій фазі сну. Notifications — система сповіщень у застосунку. Complications — функція на кшталт віджетів, яка дає змогу виводити користувацькі показники застосунку на Watch Face. Інтерфейс та технологічний стек обговорювали з представниками Apple — кожну частину окремо. Після п’яти ітерацій у дизайні ми нарешті затвердили фінальний макет і змогли перейти безпосередньо до розробки. Весь перелік необхідних кроків виглядав так: спроєктувати User Interface, обрати технологічний стек, обрати архітектуру та рушій, розробити застосунок, забезпечити аналітику, тестування й реліз. Особливості продуктів для смартгодинника Функціонал основного продукту потрібно було реалізувати, враховуючи обмежені можливості Apple Watch. Наприклад, на iPhone є плеєр, через який ми запускаємо Sleep Ritual. А от у годинника можливості програвати аудіоконтент немає — якщо тільки не підключити навушники або колонки. Крім того, в Apple Watch маленький акумулятор, тому ми оптимізували продукт так, щоб він не витрачав багато заряду. Зробили сповіщення, яке попереджає про оптимальний стан батареї: якщо показник падає до 30%, гаджет треба підзарядити. Водночас інші особливості Apple Watch дали змогу зробити продукт кращим. Наприклад, щоби зіграв будильник, апка має піднятися з бекґраунду у встановлений момент. На iPhone є проблема: застосунок не вийде підняти, поки юзер не зробить активну дію. Ми викручувалися, залишаючи calming sounds на нульовому звуці — так Avrora продовжувала працювати в фоновому режимі. А от на Apple Watch можна запланувати виклик апки з бекґраунду в конкретний проміжок часу. Це дає нам змогу реалізувати функцію будильника набагато елегантніше. Раніше ми не знали про цю особливість — про неї розказали представники Apple. Також за їхньою порадою ми реалізували Notifications Actions. Опція дає юзеру змогу відстежити показники сну на головному екрані, не заходячи у безпосередньо в застосунок. Так, зранку після пробудження він отримує сповіщення із визначенням рівня сну та одним з чотирьох показників (Good, Bad, Well та Poor). Технологічний стек У проєкті ми застосували MVVM архітектуру. Оскільки ми мали справу з останньою на той момент watchOS 9, могли собі дозволити попрацювати з усіма новими технологіями від Apple. Підтримувати старіші версії не було сенсу, адже на них немає нових опцій для трекінгу сну. Основний стек виглядає ось так: SwiftUI. На ньому легко створювати User Interface, зокрема кастомні графіки. Єдина проблема — навігація. Хоча ми й могли використовувати новий NavigationStack, він не розв'язував проблему ініціалізації наступної View з батьківської. Хотілося винести створення View та збір модулей в окрему фабрику або білдер. Спочатку ми придумали кастомне рішення для навігації з Routers, де ViewModel викликала потрібний метод у свого Router, а та своєю чергою «проштовхувала» тип, пов‘язаний з наступним View. На жаль, на етапі відтворення аудіо у бекґраунді, ми помітили баг — під час переходу з бекґраунду у фореґраунд аудіо відтворювалося заново. Через кастомну навігацію View губила свій State, тому від роутерів довелося відмовитися. Combine. Уся комунікація між об‘єктами реалізована саме через Combine, ми не використовували делегування. Технологія дає змогу легко керувати асинхронними стрімами й добре поєднується зі SwiftUI. HealthKit. З нього ми дістаємо усі дані щодо фаз сну та серцебиття юзера, щоб далі опрацювати їх за допомогою нашого алгоритму для визначення якості сну. CoreMotion. Технологія використовується для визначення фази сну, в якій краще розбудити користувача. Цей підхід ми обрали для MVP як найпростіший варіант, пізніше плануємо замінити його на CoreML-модель з розпізнаванням руху. AVFoundation. Використали для відтворення аудіо. Local Notification. Більшість сповіщень прив’язані до «івентів», наприклад, коли користувач виставив будильник на новий час. З цікавого — ми реалізували сповіщення, які приходять через певний проміжок часу після того, як користувач прокинувся. Це вдалося зробити за допомогою трекінгу даних про сон у бекґраунді. WidgetKit. Його ми використали для створення Complications. Тут ми зіштовхнулися одразу з декількома проблемами. Наприклад, функціонал, пов’язаний з будильником та трекінгом сну потрібно оновлювати досить часто, але, на жаль, Apple не дає такої можливості. Тому довелося адаптувати ідеї під їхні вимоги. Інша проблема — некоректне відображення зображень на деяких девайсах. Втім, це вирішилося простим зменшенням розміру картинки. Extended runtime sessions. Використовується для пробудження застосунку в момент, коли потрібно моніторити фази сну користувача та відтворювати звук будильника. Багато проблем було пов’язано з тим, що Smart Alarm неможливо зробити повторюваним, тому довелося писати кастомну логіку, щоб завести будильник під капотом. Як тестувати застосунок на Apple Watch Ця задача була досить складною, бо ніхто раніше не працював з повноцінними застосунками для Apple Watch. Виявилося, що порівняно з iOS, watchOS набагато вибагливіша. Серед особливостей, на які потрібно було зважати: інсталяція. Якщо користувач уже встановив Avrora на iPhone, ми маємо стежити, щоб застосунок автоматично завантажувався й на watchOS — за умови, що годинник під’єднаний до телефону; дозвіл та права доступу. Ми використовуємо дані з Apple Health Sleep Data, тому при тестуванні потрібно впевнитися, чи коректно застосунок запитує та використовує відповідні дозволи; адаптивність інтерфейсу. Оскільки екран годинників суттєво менший, ніж у мобільних пристроїв, потрібно переконатися, що контент буде оптимізованим для всіх розмірів та варіацій шрифтів. Крім того, варто звернути увагу на адаптивність у різних локалізаціях. Avrora підтримує шість мов — і треба перевірити кожну з них на різних розмірах екрана; взаємодія з іншими пристроями. Як зазначалося вище, аудіоконтент на кшталт Sleep Rituals відтворюється тільки у додаткових бездротових девайсах, тому окремо потрібно пересвідчитися, чи під’єднується гарнітура до годинника, чи коректно програється звук тощо; обмеженість ресурсів. Окремо потрібно перевірити, як застосунок працює під час низького рівня зарядки годинника та в різних режимах економії батареї; віджети та сповіщення. Важливо, щоби дані про користувача у віджетах вчасно оновлювалися. Цікава особливість тестування конкретно нашого застосунку — це необхідність спати з Apple Watch, щоби стежити, як саме апка буде трекати фази сну, та чи коректно працюватиме Smart Alarm. Труднощі на шляху Можливості Apple Watch передбачають низку цікавих технологій, але не всі з них можна адаптувати під себе. Наприклад, попри те, що Extended runtime sessions дає змогу викликати будильник з бекґраунду, вона майже не дозволяє кастомізувати UI. Або момент з даними щодо сну. Apple надає їх лише після того, як користувач прокинувся. Але нам було б корисніше отримувати їх у режимі реального часу. Це, наприклад, дає змогу простіше та точніше реалізувати функцію Smart Alarm, та будити людину у швидкій фазі сну. Ще один недолік — Apple Watch дає дуже обмежені можливості для дистрибуції, і майже ніяких можливостей для монетизації застосунку. Є можливість пропонувати підписки через Store Kit, але з точки зору маркетингу це не надто вдале рішення. Тому зараз важко похвалитися якимись шаленими цифрами щодо завантажень — всього продукт встановило десь три тисячі осіб. Попри те, що ми вперше працювали з Apple Watch, можна стверджувати, що, з точки зору функціонала, Avrora — найкращий застосунок для цієї платформи у ніші апок для сну. Ми пропонуємо і графіки відстеження сну, і медитації, і інші «сонні ритуали», і «віджети» — аби юзер міг розв'язувати свої проблеми зі сном найбільш комплексно. А нові технології та експерти з команди Apple допомогли зробити крутий та довершений продукт з точки зору користувацького досвіду.

Genesis виступила партнером дослідження ринку iOS-розробки в Україні, яке провів портал AIN.UA. Редакція видання опитала більше сотні iOS-розробників та проаналізувала їх відповіді. Питання стосувалися мов програмування, рівня зарплат в індустрії та задоволеності роботодавцями й продуктами, над якими вони пропонують працювати. Ми зібрали найцікавіші інсайти з дослідження та запросили експертів генезійського Mobile Community прокоментувати результати: своїми думками поділилися Орина Панченко, Lead iOS Developer в PlantIn та Роман Кириленко, iOS Developer в Quarks, партнерській компанії Genesis. Опитування було анонімним і поширювалося через сайт AIN.UA, тематичні канали для iOS-розробників та через компанії з профільними спеціалістами у штаті. Національне дослідження стосувалося саме iOS-розробників, що працюють на українські компанії, і тривало півтора місяця. Це тенденційне дослідження, яке показує головні тренди ринку. Загалом його пройшло 113 респондентів, які відповіли на 21 запитання. Мови програмування та технології, якими користуються iOS-розробники Яку мову програмування використовуєте? Найпопулярнішою мовою програмування серед iOS-розробників, звісно, є Swift, який у своїй роботі використовують майже 95% спеціалістів. На другому місці знаходиться Objective-C, яким користується 31,86%. Інші мови програмування, наприклад C, C++, JS чи Ruby використовують менше ніж 2% розробників, решта не змогли набрати й 1%, хоча загалом були згадані респондентами. Що ви використовуєте для розробки UI? UIKit досі залишається найпопулярнішим інструментом для розробки UI. Ним користується 66,67% iOS-розробників. А представлений у 2019 році SwiftUI набрав лише 26,13%. При цьому 7,21% використовують обидва інструменти, зазначаючи, що на роботі використовують UIKit через старий код, а для Pet-проектів вже використовується SwiftUI. «SwiftUI існує вже четвертий рік, і все частіше використовується. Та й в Apple UIKit практично не згадують. Це говорить про те, що поступово вся iOS-розробка буде переходити на SwiftUI. При цьому все має відбуватися органічно. Якщо, до прикладу, певний проєкт існує і розвивається наступні п’ять років, то за ці пять років він вже стовідсотково буде на SwiftUI. Якщо ми за рік почнемо наймати команду iOS-розробників, їх буде більше цікавити саме SwiftUI. До того ж, він трохи легший у використанні, ніж UIKit, відповідно, поріг входу в цю мову і в iOS-розробку буде нижчий», — коментує Роман Кириленко, iOS Developer в Quarks. З якими технологіями ще не працювали, але хотіли б? Майже третина (28,57%) всіх українських iOS-розробників ще не працювали зі SwiftUI, хоча хотіли б. Серед інших технологій, від 6% до 9% набрали AR, Combine та CoreML. Дещо відстає від них загалом трендовий зараз штучний інтелект, з яким хотіли б попрацювати 4,4% розробників. «Ми використовуємо ШІ в PlantIn, і, власне, Apple нині цю сферу розвиває і стимулює розробників використовувати ці інструменти. Під час Apple Enterpreneur Camp, де я брала участь, фахівці Apple закликали використовувати усі можливості штучного інтелекту в застосунках. До прикладу, активно розвивається фреймворк Core ML, який допомагає імплементувати ШІ на девайс без жодних запитів на бекенд», — говорить Орина Панченко, Lead iOS Developer в PlantIn. Бачення ринку Де найцікавіші для iOS розробників задачі та стек технологій? На думку українських спеціалістів, найцікавіші для iOS-розробників задачі та стек технологій пропонують компанії, чия основна діяльність — це розробка додатків для iOS. Лідерами стали MacPaw (14,29%) та Readdle (10,71%). На третьому місці опинилась Genesis (8,93%). Крім цих компаній понад 5% зміг набрати лише EPAM з 6,25%. З того що ви чули, де найвищі зарплати для iOS розробників? 11,54% розробників вважають Genesis компанією з найвищими винагородами на ринку. Другою найпопулярнішою відповіддю після Genesis стала MacPaw, за яку проголосувало 10,26%. За ними з незначним відставанням розмістилися Grammarly та Readdle, які набрали по 7,69% Пошук роботи У який спосіб шукаєте роботу? Серед способів пошуку роботи лідерами є додавання профілю в сервіси для пошуку роботи (Djinni, Recruitika, Skyworker), який будуть використовувати 71,25% респондентів, та відгуки на розміщені вакансії — 65%. «Нині існують проблеми з ринком. Коли я починав, мені не важко було знайти роботу. Для джунів і світчерів зараз найкраще — шукати компанію, яка надає інтернатуру, школу абощо. Зараз iOS-розробка має багато прошарків, технологій та інструментів, початківцю в них важко розібратись. А компанія, що має школу або стажування, допоможе зорієнтуватись, навчить фахівця саме під свої запити і бачення. Якби шукав роботу зараз, як сеньор, то найголовніше джерело — колеги з ринку. Це можуть бути проджект-менеджери, з якими я працював раніше, колишні колеги-розробники. По-перше, вони знають, як ти працюєш, що вмієш, і одразу можуть дати рекомендацію. По-друге, все ж таки, реферали — це те, що працює надійніше за все» — коментує Роман Кириленко. Згідно з дослідженням, трохи більше за половину iOS-розробників оновлять свій LinkedIn-профіль, додавши в нього нову інформацію та поставлять статус Open for opportunities. Найменшою популярністю користується пошук роботи через знайомих рекрутерів, проте й цим варіантом скористається майже третина або 28,75% спеціалістів. 15% респондентів зазначили, що будуть використовувати всі доступні методи пошуку нової роботи. Про зарплатні очікування і реальність, кросплатформні рішення, найцікавіші українські iOS-продукти читайте у повній версії дослідження на AIN.UA.

У травневому дайджесті вакансій головними стали бекенд-розробники. Чи хотіли б ви попрацювати в українському фінтеху? А із застосунком з короткими історіями? Тоді у переліку є пропозиції саме для вас. А, можливо, саме зараз ви наймаєте першу людину до бекенд-команди та шукаєте оптимальні питання на співбесіду? У матеріалі знайдете найповніший перелік питань на співбесіду. Гортайте до кінця! Back-end (Node.js) Developer (вакансія закрита) Ви працюватимете в Holy Water – це паблішер застосунків, заснованих на даних, та рольових мобільних ігор. Аби розвивати застосунок з різноманітними історіями, команда шукає Node.js Back-end Developer. У обов’язки буде входити реалізація A/B-тестування контенту на бекенді, інтеграція рекомендаційної системи та оптимізація швидкості обробки запитів. Щоби приєднатися, потрібен не менш як дворічний досвід, досконале володіння TypeScript, знання реляційних і нереляційних баз даних, а також технологій NestJS, GraphQL (Apollo), Docker та AWS. Back-end Engineer До одного з нових проєктів екосистеми Genesis шукають бекенд-розробника рівня джуніор. Аби обійняти посаду, достатньо навичок написання гнучкого та масштабованого коду та обізнаності в таких технологіях: Golang або Node.js, REST чи GraphQL, SQL, Docker, Kubernetes, Terraform та AWS. Пул завдань невеликий — розробка мікросервісів, інфраструктури та робота з CI/CD. Вакансії партнера Golang Engineer Solidgate — це B2B-продукт у сфері онлайн-платежів. Команда будує фінтех-екосистему, аби її клієнти могли безпечно та вигідно приймати оплати в усьому світі. Її посилить Golang Engineer, який архітектурно пропрацює проблеми з ідемпотентними запитами, візьме участь у проєктуванні вебрішень (Payment Page, Payment Form, SDKs тощо) й покращить підходи до розробки, а також архітектуру коду та сервісів. Йому знадобиться мінімум два роки комерційного досвіду, з яких рік — роботи з Golang, розуміння принципів побудови високонавантажених систем, вміння працювати з Docker, AMQP, а також з PostgreSQL та Elasticsearch. Загальний стек технологій продукту: Golang, Kotlin, PostgreSQL, RabbitMQ, ELK, Docker, AWS. Java/Kotlin Developer (вакансія закрита) Ще один розробник, якого шукають до Solidgate, працюватиме з командою Finance Engineering. Вона відповідає за фінансовий супровід діяльності продуктів Solidgate. Завдання відповідні: налагодити процес формування бухгалтерських балансів, забезпечити правильний порядок реалізації інвойсів, автоматизувати звірку даних з еквайрами та контроль комісій IC+. Ідеальний кандидат має п’ять років досвіду в розробці на Kotlin або Java, знає PostgreSQL або MySQL та працював із Spring Boot та Spring. Перевагою буде досвід роботи у фінтеху, а також знання AWS чи Apache Kafka. Що почитати за темою: 6 міфів про бекенд. Спростовує Back-end Developer в Boosters Бекенд та фронтенд-розробники справді постійно ворогують? Писати код треба щодня? А програмувати доведеться одними лише фреймворками? Якщо ви відповіли «ні» на всі три питання, вітаємо — ви справжній знавець, непідвладний стереотипам. Якщо хоч десь закралося «так» — пропонуємо ознайомитися з матеріалом вище. Спростували в ньому найпоширеніші міфи у спільноті, зазначили, де правда, а де вигадка, та пояснили, чому бекенд — це не так складно, як здається, а конфронтація з фронтенд-розробниками сильно перебільшена. 180+ питань на співбесіду Golang для Junior, Middle та Senior Об’ємна шпаргалка з питаннями для тих, хто буде проходити чи проводити технічне інтерв’ю. Зібрали майже дві сотні питань для різних ґрейдів, втім лякатися не варто — кандидатам ніколи не ставлять весь пул запитань. Якщо ж ви поки не збираєтеся масштабувати команду чи змінювати роботу, список допоможе побачити прогалини у своїх знаннях та вчасно їх заповнити.

Що питають на співбесіді у PHP розробників? Ми зібрали великий перелік поширених питань з теорії та практики. Зазвичай кандидатам ставлять лише невелику частину питань із цього списку. Але він буде корисним для підготовки до технічного інтервʼю для спеціалістів різних ґрейдів — Junior, Middle, Senior та допоможе виявити прогалини в знаннях. Максим Коханський, Lead Back-end Engineer в OBRIO та Ілля Козинець, Tech Lead в Sendios, партнерській компанії Genesis, поділилися, як вони проводять співбесіди, чого очікують від різних ґрейдів та на що звертають увагу. > Питання для Junior > Питання для Middle / Senior Питання для Junior Зазвичай джуніор-розробникам ставлять здебільшого теоретичні питання, адже у цих спеціалістів мінімальний комерційний досвід або взагалі його немає. «Памʼятаю, як одна з моїх перших співбесід повністю складалася з питань по документації, наче на іспиті: що це за метод, які параметри передає тощо, — згадує Максим Коханський, Lead Back-end Engineer у OBRIO. — Я не прихильник таких питань. Коли сам проводжу співбесіди намагаюся питати про те, що більше потрібно в роботі. Наприклад, значно важливіше розуміти логіку чи вміти написати мініархітектуру для декількох класів, ніж відповісти на питання, які легко загуглити, на кшталт “перелічіть методи роботи з масивами”. З теорії питаю про принципи SOLID. Хоч це абстрактна тема, але важливо в ній орієнтуватися». У практичних завданнях звертають увагу на нестандартні підходи. «Зазвичай кандидати виконують завдання стандартними способами, як написано в документації. Але один кандидат нас справді здивував, запропонувавши рішення з підключенням модульної системи в Laravel. Ми такого навіть не зустрічали. За цікавий підхід він здобув від нас плюсик. Водночас рішення має бути практичним, а не просто виглядати нестандартним. Також джуніор-розробникам обовʼязково дають тестове завдання, а також ставлять практичні питання на співбесіді. «Я даю подивитися на простий клас, в якому дуже багато помилок — як дрібних, так і великих (наприклад, клас треба розділити на три класи), і дивлюся, на що людина звертає увагу, як вона думає», — розповідає Максим. Також може трапитися питання на уважність. Наприклад, у чому різниця між PHP 6 и PHP 7? Секрет в тому, що шостої версії PHP не існує. Загальні питання 1. Як оголосити змінну в PHP? 2. Що таке масив у PHP і як його оголосити? 3. Що таке GET та POST, в чому різниця? 4. Що таке файл cookie і як його встановити в PHP? 5. Що таке клас у PHP і як його визначити? 6. Що таке наслідування в PHP? 7. Що таке поліморфізм у PHP? 8. Що таке інкапсуляція в PHP? 9. Що таке статичний метод у PHP? 10. Як оголосити статичну змінну в PHP? 11. Що таке функція в PHP і як її визначити? 12. Що таке рекурсія в PHP? 13. Як використовується ini_set()? 14. У чому різниця між == та ===? 15. Що відбувається, коли вводиш URL у браузері? 16. Який тип повернення функції, яка нічого не повертає? 17. Що таке принципи SOLID? 18. Що таке REST? Чи використовували ви в роботі і яким чином? 19. Які ви знаєте принципи ООП? 20. Які магічні методи у класу ви знаєте? Як їх застосовують? 21. Коли використовується construct i destruct? 22. Коли використовується метод invoke? 23. Як працюють методи __get i __set? 24. Обробка помилок try catch, finally, throw. Як це працює? 25. Що таке PDO? 26. Яка різниця між preg_match і preg_replace у PHP? 27. Що таке PSR стандарти? 28. Які патерни проєктування ви знаєте? З якими ви працювали? 29. Що таке юніт-тести та функціональні тести? 30. Яке призначення файлу php.ini? 31. Чи підтримується множинне наслідування в PHP? 32. Що таке stdClass у PHP? 33. Чи є різниця між isset і !empty? 34. Розрізняйте echo та print() 35. Яка різниця між $a != $b і $a !== $b? 36. Що означає ключове слово var у PHP? 37. Що ми маємо на увазі під ключами та значеннями? 38. Які відмінності між функціями die() і exit() у PHP? 39. Поясніть, як обробляти винятки в PHP? 40. Які основні відмінності між const і define 41. Яка різниця між isset() і array_key_exists()? 42. Чи можете ви розширити остаточно визначений клас? 43. Як увімкнути звіт про помилки в PHP? 44. Коли краще використовувати require та include? 45. Які різні області дії змінних? 46. Яка різниця між var_dump() і print_r()? 47. Як можна встановити нескінченний час виконання для сценарію PHP? 48. Наведіть кілька прикладів, коли вам доводилося використовувати destruct у своїх класах? 49. Як видалити масив PHP за значенням (не ключем)? 50. Які інструменти та технології використовуєте в роботі? 51. Який досвід роботи з Git? Які переваги ви бачите в роботі з Git? 52. В чому різниця між pull та fetch? 53. В чому різниця між merge та rebase? 54. Чим відрізняється composer.json від от composer.lock ? 55. Чим відрізняються require від require-dev у composer.json? 56. Як налаштувати autoload через composer? 57. Що таке трейт і як його використовувати? 58. Як зробити так, щоби сесії не зберігалися у файлі? 59. В чому різниця між self та this? 60. Що таке агрегатні функції? 61. Що таке http-запит? 62. Які групи кодів відповідей ти знаєш? Бази даних 63. Як підключитися до БД у PHP? 64. Як отримати дані з БД у PHP? 65. Які є індекси в MySQL? 66. Яке призначення транзакцій? Розкажіть про принцип роботи. 67. Чи можна скасувати транзакцію? Як це зробити? 68. Які знаєте типи звʼязків в базах даних? Чим вони відрізняються? 69. Що таке первинний та зовнішній ключі? 70. Чи може первинний ключ мати значення Null? 71. Що таке індекси? 72. В чому різниця між MyISAM vs InnoDB? 73. Що таке JOIN? 74. Які є види JOIN та в чому різниця? 75. У чому різниця між WHERE і HAVING? 76. Що таке нормалізація та денормалізація? Практичні завдання 77. Цей клас написано неправильно. Щоб ви переписали? width = $width; $this->height = $height; } } class Triangle { public $radius; public function __construct($radius) { $this->radius = $radius; } } class AreaCalculator { public function calculate($shapes) { foreach ($shapes as $shape) { if (is_a($shape, 'Square')) { $area[] = $shape->width * $shape->height; } elseif (is_a($shape, 'Triangle')) { $area[] = $shape->radius * $shape->radius * pi(); } } return array_sum($area); } } 78. Які принципи SOLID порушує цей код? $this->author->fullName(), 'title' => $this->title, 'content' => $this->content, 'timestamp' => $this->date->getTimestamp(), ]; } public function printJson(): string { return json_encode($this->getData()); } public function printHtml(): string { return ` {$this->title} {$this->date->format('Y-m-d H:i:s')} {$this->author->fullName()} {$this->content} `; } } 79. Імена яких змінних задані невірно? Чому? 80. Нижче спроба виведення значень змінних на екран. При спробі виведення яких змінних інтерпретатором буде видана помилка і чому? '; echo $b.''; echo $c; m_func(); ?> 81. Що виведе цей код? Чому? class A { public function __construct(string $a){ $a .= $a; } } class B extends A { public function __construct(int $a){ $a++; } } $b = new B(1); var_dump($b); 82. Напишіть функцію PHP для обчислення факторіала заданого числа за допомогою рекурсії. 83. Напишіть сценарій PHP, який перевіряє адресу електронної пошти за допомогою регулярних виразів. 84. Напишіть функцію PHP для сортування масиву цілих чисел у порядку зростання за допомогою алгоритму bubble sort. 85. Напишіть функцію PHP, щоб видалити всі повторювані значення з масиву. 86. Створіть клас PHP, який реалізує структуру даних черги. 87. Напишіть сценарій PHP, який генерує випадковий пароль із поєднанням літер, цифр і символів. 88. Напишіть функцію PHP для пошуку найбільшого та найменшого значень у масиві цілих чисел. Питання для Middle / Senior Під час співбесіди для ґрейдів Middle та Senior інтервʼюери вже не стільки звертають увагу на код, скільки на архітектурні рішення, патерни, які використовує розробник. Часто обом ґрейдам ставлять одні й ті самі питання, але очікування від відповідей мідла менші. «Кандидатів ретельно розпитують про попередній досвід, уточнюють, з якими проблемами стикався та як їх вирішував, в яких процесах працював, від кого приходили завдання, яким був процес рефакторингу коду тощо», — розповідає Ілля Козинець, Tech Lead в Sendios. Питання, щоби перевірити хард-скіли, стосуються загального стека, з яким працює компанія та кандидат: фреймворки, сервіси кешування (Redis, MemCashed), бази даних MySQL, брокери черг (RabbitMQ тощо), а також патернів, різних методологій, мікросервісів, CI/CD, контейнеризації. «Сильні софт-скіли — одна з ключових відмінностей сеньйора від мідла. Для нас це пріоритетніше за хард-скіли, тому ми багато питань ставимо саме по цій частині: ставлення кандидата до роботи, вміння пріоритезувати та декомпозувати задачі, здатність генерувати ідеї, вміння комунікувати, — ділиться Ілля Козинець. — Наприклад, у кандидата є ідея (процесна або технічна), яка б, на його думку, могла якісно покращити роботу. Він її презентував команді, але її не взяли в роботу. Які його наступні кроки? Він проаналізує недоліки комунікації чи просто опустить руки? Це важливо і багато говорить про кандидата». Загальні питання 89. Чому ви програмуєте на PHP? 90. Які найважливіші технічні навички для Middle / Senior PHP Developer? 91. Опишіть ваш процес виявлення та усунення помилок в існуючому коді? 92. Які патерни ви використовуєте при розробці найчастіше? Чим вони відрізняються і які проблеми вирішують? 93. Яку проблему вирішує патерн Адаптер? У чому його відмінність від патерну Декоратор? 94. Які принципи SOLID ви найчастіше порушували під час розробки та з якої причини? 95. Чи можете поділитися прикладом успішного впровадження DDD у PHP-проєкт? З якими проблемами ви зіткнулися під час впровадження? 96. Що таке Entity, Aggregate, Value Object в DDD? 97. В чому переваги або недоліки використання Value Object? Навіщо його використовувати? 98. Які ви знаєте способи комунікації між мікросервісами? 99. Як організувати транзакції на рівні мікросервісів? 100. Як був організований процес рефакторингу на вашому попередньому місці роботи? Чи був для цього окремий беклог? 101. Як аргументувати рефакторинг замовнику/керівнику? 102. На що спираєтеся при рефакторінгу? З якою метою ви робите рефакторинг і що плануєте отримати в результаті? 103. Наведіть приклад найскладнішого кешування зі своєї практики? 104. Які відмінності між Redis та Memcached? 105. Які структури даних Redis використовували на практиці? 106. Чи є вас досвід роботи з брокерами черг? 107. Чи використовували RabbitMQ? Які знаєте exchanges? 108. Для чого використовується опція durable в RabbitMQ? 109. Опишіть свій досвід написання документації? Які формати використовували? 110. Як ви зʼєднаєте скрипт, написаний на Python та на PHP? Як зробити, щоби PHP використовував функціонал Python за умови, що ви не можете використовувати функції командної строки? 111. Що таке рефлексія? 112. Що таке OPcache? Що дає та як його використовувати? 113. Які мікросервісні патерни ви знаєте? 114. Що таке stateless та statefull? Як ці сервіси працюють? 115. Шина подій — що це і як використовується? 116. В чому переваги на недоліки асинхронних викликів? 117. Абстрактний клас — що це таке і навіщо він потрібен? 118. Чи існує функція для створення копії масиву PHP в інший? 119. Поясніть різницю між exec(), system() та passthru()? 120. Максимальна кількість аргументів, дозволених у функції в PHP? 121. Поясніть різницю між shell_exec() і exec() 122. Яка різниця між інтерпретатором PHP і обробником PHP? 123. У чому саме різниця між array_map, array_walk і array_filter? 124. Які великі зміни PHP зазнав за останні кілька років? 125. У чому відмінність параметризованих та непараметризованих функцій? 126. Чому ми використовуємо extract()? 127. Для чого використовується оператор Null coalescing? 128. Чи підтримує PHP перевантаження методів? 129. Порівняйте MySQLi та PDO. Які плюси та мінуси? 130. Яка різниця між query(), PDO та execute()? 131. Що таке автозавантаження класів у PHP? 132. Коли краще використовувати require_once, а не require? 133. Чи є якась причина використовувати strcmp() для порівняння рядків? 134. Як би ви створили клас Singleton за допомогою PHP? 135. Як перевірити, чи масив PHP є асоціативним? 136. Які недоліки використання постійного з'єднання в PDO? 137. Поясніть ієрархію винятків, представлену в PHP7? 138. Який найкращий спосіб об’єднати два об’єкти PHP? 139. Як перетворити помилки на винятки в PHP? 140. Що таке оператор yield у PHP? 141. Що краще для звільнення пам’яті за допомогою PHP: unset() чи $var = null? 142. Чи має PHP потоки? 143. Як виміряти час виконання скриптів PHP? Бази даних 144. Опишіть свій досвід роботи з різними типами баз даних (MySQL, PostgreSQL, MongoDB тощо)? 145. Чи працювали ви над проєктуванням і нормалізацією бази даних? Як виглядає процес розробки нової схеми бази даних? 146. Як ви оптимізували продуктивність бази даних у своїх попередніх проєктах? 147. З якими проблемами безпеки бази даних ви стикалися, і як ви їх вирішували? 148. Як ви обробляєте міграції та керування версіями для змін бази даних у командному середовищі? 149. Як ви керуєте резервним копіюванням даних і аварійним відновленням баз даних? 150. Чи реалізували ви механізми кешування для запитів до бази даних у своїх попередніх проєктах? Поясніть переваги та недоліки різних стратегій кешування? 151. У вас є запит до бази даних, який повільно відпрацьовує. Назвіть кілька способів, як це можна виправити. Який з них ви вважаєте оптимальним? 152. Праймері індекс можна створити на одну, дві чи три колонки? 153. Як додати нове поле у велику таблицю в MySQL? 154. Що таке партиціювання, шардування та реплікація? 155. Як зберігати приватні повідомлення у базу даних? 156. Як знайти та оптимізувати «важкі» запити? 157. Що таке sensitive дані? Як вони зберігаються в базі та відображаються в логах? 158. Які ви знаєте структури даних? Які з них використовували на практиці? CI/CD 159. Чи використовували ви якісь інструменти CI/CD у своїх попередніх проєктах? Які з них і яким чином? 160. Як ви інтегрували модульне тестування та інші типи автоматизованого тестування у свій процес CI/CD? 161. Розкажіть про свій процес розгортання змін коду у виробництві? 162. З якими проблемами ви зіткнулися під час впровадження процесів CI/CD і як ви їх подолали? 163. Розкажіть про свій досвід роботи з інструментами контейнеризації та оркестрації (Docker, Kubernetes)? 164. Як відкотити розгортання, якщо щось піде не так? 165. Як переконатися, що ваші конвеєри CI/CD безпечні та вільні від вразливостей? 166. Чи можете ви поділитися будь-якими найкращими практиками з ваших попередніх реалізацій CI/CD? 167. У вас є завдання, яке передбачає міграцію бази даних, яка виконується доволі довго. Опишіть процес, як би ви це здійснили: чи варто виконувати міграцію разом з кодом? Що робити зі старим кодом? Як підтримувати стару і нову версію базу даних? Софт-скіли 168. У вас ідея, яка, на вашу думку, може вирішити важливу проблему. Ви презентували її команді, але її не оцінила/не взяли в роботу. Якими будуть ваші наступні дії? 169. У вас є дві пріорітетні задачі з однаковим дедлайном. Ви не встигаєте виконати обидві задачі до дедлайну. Якими будуть ваші наступні кроки? 170. Розкажіть про найбільший факап за свою карʼєру? 171. Щоб ви першочергово імплементували/змінили, маючи зони впливу свого попереднього керівника?

Питання грамотного менеджмента, балансу між хард- і софт-скілами, та професійного підходу до побудови процесів всередині команди хвилюють лідів усіх напрямків. Нещодавно на мітапі у MacPaw Space зустрічалися QA-ліди великих українських продуктових компаній. Керівники з AMO, Quarks, MacPaw і Uklon обговорювали найбільш гострі теми, що стосуються управління напрямом тестування. Найцікавіше із доповідей спікерів — у нашому конспекті. > Помилки QA лідів > Горизонтальна система керування тестуванням > Місія, візія і фейли > Комплексний підхід до проведення співбесід Помилки QA лідів Помилка перша. Найняти не ту людину Якщо ви єдиний QA-фахівець на проєкті, і маєте бюджет на другого спеціаліста, то саме ви будете тим, хто найматиме його. Що може піти не так? Людина виявиться не підходящою. По-перше, я б радив найняти ту людину, з якою вам особисто буде зручно працювати і спілкуватись. По-друге, ґрейд нового фахівця має відповідати вашому. Так колега зможе замінити вас у виконанні будь-якої таски за необхідності. Помилка друга. Неправильне планування Якщо ви долучаєтесь, наприклад, до великого проєкту, і вам потрібно найняти вже не одного, а 3-10-15 тестувальників, то проблема може виникнути інша. Нагірше, що може статись, — неправильно сплановане навантаження і невірно визначена кількість людей, яких потрібно найняти та який у них має бути ґрейд. Якщо ви не впевнені, що зможете все грамотно розпланувати, варто звернутись по допомогу до менеджера з досвідом. Помилка третя. Радикальні зміни Якщо ви приходите в уже сформовану команду як QA-лід, можлива помилка — одразу намагатись змінити усі процеси і підходи, які були налаштовані до вас. Спочатку покращуйте щось лише точково і спостерігайте, як все працює. Окрім цього, я б радив провести one-to-one з кожною людиною з команди, спитати її думку — що заважає, що допомагає, що можна покращити. Так ви зможете зібрати основні проблеми, пріоритезувати їх, і вже потім планувати зміни. Помилка четверта. Страх делегування обов'язків Як зрозуміти, що у вас проблеми з делегуванням? Ви ловите себе на таких думках: «лише я знаю, як краще». Пам'ятайте що, на жаль, лід із більшою ймовірністю втрачає технічні навички, тому ваші колеги скоріш за все, знають краще, що треба робити. «без мене все зламається». Це означає, що ви не довіряєте команді повністю. Такий підхід може спричинити «тепличні» умови для команди, коли лід все «розрулює». Ймовірніше, за таких умов команда припинить розвиватися. Помилка п’ята. Мікроменеджмент Мікроменеджмент — це руйнівне управління, від якого страждають усі сторони. Основна задача ліда — дивитись на ситуацію дещо відсторонено, згори, щоби прийняти максимально релевантне рішення. Вам не потрібно вирішувати проблеми за людей, бо це не закінчується ніколи. Часто мікроменеджмент виникає через недовіру до фахівців. Коли ви починаєте дуже сильно контролювати кожен крок спеціалістів, то витрачаєте свій час неефективно та заважаєте їм виконувати свої прямі обов’язки. А у людей від надмірного контролю з'являється відчуття, що вони не справляються, і їх перформанс ще більше просідає. Помилка шоста. Неприйняття рішень Мозок людини працює таким чином, що якщо якусь проблему довго не вирішувати, то починає здаватися, що вона якось вирішиться сама. Головна помилка — коли не приймаються рішення, що вже давно назріли. Як переформувати команду, і чи варто це робити, як відмовитись від певного фреймворку чи підходу до тестування, які ще наче працюють, але вже застарілі, чи варто підвищувати людину в посаді та зарплатні, чи варто звільняти людину, чи вона може змінитись і адаптуватись до вимог проєкту і компанії, чи варто назначати черговий мітинг чи можна обійтись електронною поштою? І ще мільйон різних запитань. Головний обов'язок ліда — прийняття рішень. Якщо вам здається що ваші рішення — неправильні або не найкращі, скоріше за все, ви на вірному шляху, тому що це свідчить про те, що ви рефлексуєте над ними. Інколи варто просто прийняти рішення, подивитись його на результат, відкоригувати за необхідності та рухатись далі. Горизонтальна система керування тестуванням Концепція гільдій Ще коли я лише починав працювати, мене дивувало, що в IT-галузі іноді на одного інженера — два або й більше менеджерів. Нині, в якості ліда, я потроху формую бачення, як зробити так, щоб це нормально працювало. В Quarks структура влаштована таким чином: є три великі команди — продуктова, маркетингова і tech team. В межах перших двох команд у нас є декілька автономних кросфункціональних тімок. Що вони собою представляють? Це команда, де є PM, який вирішує, що робити, які таски тощо. Також там є технічні спеціалісти: аналітики, дизайнери, фронтенд- та бекенд-фахівці, QA. Ще є команда tech team, якою керує CTO. В ній окремо є DevOps, сервісні команди, а також фронтенд,- бекенд- і QA-ліди. Я в якості QA-ліда керую як своєю командою автомейшена, так і по горизонталі всім QA-напрямком нашої компанії. Що це значить? PM в кожній кросфункціональній команді вирішує завдання, пов'язані більше з продуктовим навантаженням, який функціонал буде робитись, яка буде його пріоритетність. А я більше відповідаю зе те, як саме це має бути зроблено. Таким чином QA-інженер в команді має два керівника — PM і ліда QA-напрямку. Саме тому це називається горизонтальною системою або системою гільдій. Переваги горизонтальної організаційної структури: кожною гільдією керує лід, який розуміє специфіку роботи фахівців; кросфункціональна команда орієнтується на свої результати та процеси, їй не потрібно узгоджувати свій флоу з іншими командами; PM команди сконцентрований на продуктових задачах; система «стримувань і противаг». Ніхто не керує всім одноосібно, є декілька центрів прийняття рішень, а це мінімізує ризики; більш об'єктивна оцінка перформансу технічних спеціалістів; уніфікація підходів та стеку технологій. Основні складнощі в системі гільдій Важливо, щоб PM та QA-лід працювали в унісон, розуміли один одного, або хоча б не заважали. Кожна команда має свій темп, і це певною мірою може гальмувати уніфікацію. Треба шукати компроміс між усіма учасниками, аби уніфікація відбувалася, не ламаючи процеси нікому. PM команд мають різний рівень технічних скілів. Важливо комунікувати всі свої рішення та доносити до PM, чому ми робимо саме так. Лід гільдії повинен мати прокачані технічні і комунікативні скіли, тому що більшість проблем і труднощів виникають саме через брак комунікації і досвіду у когось із команди. Основні напрямки роботи QA-ліда гільдії Постійний контроль слідування побудованому флоу тестування. Створення єдиного центра керуванням тестуванням в компанії. Комунікація та роз’яснення процесів, інструментів та всього, що стосується QA. Уніфікація підходів. Це дає змогу суттєво заощадити час і кошти. Оцінка роботи QA в командах. Місія, візія і фейли Що таке місія і чим вона вам допоможе? Місія – певне розуміння того, чим ви будете займатись на тій чи іншій посаді. Як її сформулювати? Відповісти на питання: що ви робите, як ви це робите і навіщо. З ростом і зміною ваших зон відповідальності, зміною команди або проєкту буде трансформуватись і ваша візія. Коли я був інженером, після рев’ю я отримував фідбек про те, що треба розвиватись, шукати свій шлях, вірний вектор руху і таке інше, але що саме треба робити — було незрозуміло. Коли я став лідом, я усвідомив, що це і є моя місія — створити прозорі умови для розвитку інженерів в компанії з дотриманням справедливості по відношенню до компанії. Тобто щоби не лише люди зростали, а й компанія також отримувала профіт. Візія: тримати у фокусі Якщо з місією ви працюєте кожен день, тому що це і є ваша робота, то візія — це така собі лінія горизонту, яка майорить десь далеко, але саме вона змушує вас рухатись і приймати ті виклики, які кидає вам індустрія. Як не втратити візію в рутині? Ви маєте постійно перевіряти, наскільки ваша візія відповідає візії компанії, потребам продукту, індустрії. Її треба постійно розширяти, змінювати відповідно до обставин. Маєте сформулювати те, що ваша візія має дати сьогодні, щоб ви опинились в майбутньому там, куди ви плануєте прийти. Візія — це ваше завтра. Нині моя візія як ліда — рухатися в сторону спрощення з урахуванням тої цінності для бізнесу, яку ми можемо давати як інженери. Три фейли і три уроки, що вони принесли Люди не читають думок. Коли я починав лідити команду, у мене було море ентузіазму, багато ініціатив, я хотів все змінити. Так сталося, що, проговоривши свою місію, візію із тимлідом, я не отримав апрув від своєї команди. Насправді, я навіть не розповів їм про свої ініціативи. Мені здавалось, що все всім очевидно. Тож, коли я почав впроваджувати зміни, то зіштовхнувся із нерозумінням команди. Варто детально пояснювати команді ваш план — що і для чого, створити умови, щоб вони теж могли контрибьютити і бути залученими у реалізацію цієї стратегії. Вам потрібно мати чіткий роадмеп та надавати регулярні апдейти. Будь-які зміни потребують детального планування. Одного разу до мене прийшов один з інженерів і запропонував використати новий трендовий фреймворк. Я подумав — класно. Мені здавалось що це буде корисно і для розвитку команди, і для продукту. Але сталося зовсім по-іншому. Через деякий час частина команди, яка здійснювала цей перехід, мігрувала на інші ролі або у інші продукти. Ми опинились у ситуаціі, коли ми сидимо з новим проєктом, і в нас не так багато інженерів, які можуть використовувати його для роботи. Перш ніж робити серйозні зміни, які можуть вплинути на швидкість делівері продукту, треба оцінити наскільки ці зміни актуальні і потрібні зараз, чи зможете ви знайти спеціалістів, чи зможуть вони не лише підтримувати, а і розвивати продукт. Не толерувати те, що погано працює. Спочатку я був лідом однієї команди, потім — додалась друга, потім ще і ще. В одному продукті в мене було 5 QA-команд, які були досить розрізненими. Я побачив, що такому хаосі це не буде працювати ефективно — були проблеми з документацією, процесами, підходами, із взаємодією QA між собою. Якщо бачите проблему з процесами, не тягніть із рішенням. Може статися, що люди просто не дочекаються поки ви проблему вирішите, і підуть. Також не бійтесь обговорювати проблеми прямо із командою та менеджментом. Комплексний підхід до проведення співбесід У 2021 році Uklon почала швидко зростати: збільшилися поточні команди, одночасно створювалися нові. Нам потрібні були нові фахівці. Щобільше співбесід ми проводили, тим більше бачили, що наш підхід до інтерв’ювання кандидатів не працює. В нас був шаблон розмови, зосереджений на технічних питаннях, їх зазвичай багато в інтернеті. Рішення про найм ми приймали в залежності від професійних скілів. Здавалося б логічно, але це було нашою помилкою. Люди, яких ми обирали таким чином, відмінно підходили нам за професійним рівнем, проте не співпадали ані за цілями, ані за цінностями. Тож деякий час пішов на аналіз та зміну підходу. Я почав аналізувати: що QA-інженери роблять щодня? Приймають рішення — від малих до великих: коли почати тестування, що покривати тестами, які інструменти використовувати в роботі тощо. І я прийшов до того, що підхід кандидата до вирішення завдань для нас має бути важливішим за досвід роботи. Звісно, в новому шаблоні співбесіди технічні запитання нікуди не ділися, але вони стали мати другорядне значення. Нині основний блок запитань у нас на інтерв’ю — про прийняття рішень. Кожному кандидату я пропоную уявити певну ситуацію, наприклад: Інженер взяв задачу в роботу, але її опису немає. Як це можна виправити? Підходить дедлайн релізу, але баги не закінчуються. Що робити? Інженер працює над пріоритетними задачами, але його відволікають. Як змінити ситуацію? Відповіді на такі запитання показують: чи замислювався кандидат над процесами, в яких він працює; чи раніше приймав кандидат рішення самостійно; чи він працював зі своїми помилками; чи може він нести відповідальність за себе та команду. Технічні запитання. Копайте вглиб Оскільки технічні скіли ми у будь-якому випадку маємо оцінити, то для цього блоку співбесіди теж склали декілька вимог до інтерв’юерів: Уникати заготовленого списку запитань на співбесіді. Складати кастомізований список під кандидата — його скіли, досвід тощо. Мати заздалегідь розроблені плани співбесід для кандидатів будь-якого рівня. Під час інтерв’ю орієнтуватися на сильні, а не на слабкі сторони кандидатів. Ми визначили для такі масивні розділи, які важливі для нас: мобільне тестування, бекенд тестування і веб. В залежності від потреб, від команди, куди ми берем інженера, ми можемо спитати: Технічну частину співбесіди ми починаємо тепер окремого масивного блоку — чи то мобільне тестування, чи то бекенд-тестування або веб, — в залежності від позиції, на яку наймаємо. Далі під час розмови заглиблюємося в конкретну тему і намагаємося зрозуміти все, що кандидат про неї знає. Практикуємо щирість Ми хотіли, щоби наша співбесіда не була допитом. Кандидат в стресі не може адекватно оцінити свої знання і нормально відповісти на питання. Йому має бути комфортно протягом всієї розмови. Якщо він не знає відповіді на запитання або не розуміє його належним чином, я відповідаю на це питання, тим самим показуючи йому, що я від нього очікую. Це класно налаштовує кандидата далі. Тож в новій ітерації нашого підходу до співбесід ми вирішили, що віддаємо частину контролю кандидату, аби він: розумів хід співбесіди; отримував відповіді на свої питання міг розраховувати на якісний і своєчасний фідбек. Повний запис мітапу QA-лідів дивіться тут:

Фронтенд — це легкий вхід в ІТ чи один з найскладніших напрямів розробки? Щоб розвиватися, потрібно вивчати якомога більше бібліотек, заглиблюватися в дизайн чи в патерни програмування? Чи завжди нативні застосунки кращі за веб? Мікрофронтенд вирішить усі проблеми вебзастосунку чи додасть нових? Найрозповсюдженіші міфи спростовує Микола Носенко, Front-end Developer в OBRIO з екосистеми Genesis. > Фронтенд — це легкий старт в ІТ > Робота на фронтенді складається з однотипних задач > Для розвитку потрібно вивчати більше сучасних фреймворків та бібліотек > HTML, CSS та JavaScript — це технології, які не розвиваються та не змінюються > Нативні застосунки завжди будуть зручнішими за веб > Фронтенд-девелопер має обовʼязково добре розумітися в дизайні > Сторінки та вебзастосунки стають занадто складними > Мікрофронтенд — універсальне рішення, за яким майбутнє та яке підходить усім МІФ №1 Фронтенд — це легкий старт в ІТ. Історично склалося, що початківцям легше вивчати фронтенд, аніж бекенд чи інші види розробки. Але це зовсім не означає, що цей напрям — простий. Раніше вивчення HTML та CSS було достатньо, щоби почати реалізовувати якісь проєкти. Загалом робота фронтенд-девелопера потребувала значно менше знань у програмуванні. Але щороку цей напрям ускладнюється: як інтерфейси, так і самі рішення. Джуніор уже навряд зможе знайти роботу та бути корисним на проєкті, якщо не знає JavaScript та як мінімум один із фреймворків. Бекенд — не легший і не складніший, а просто має свою специфіку. Робота з інтерфейсом командного рядка, терміналами, базами даних може здаватися занадто складною та незвичною для світчерів. Також тут неможливо отримати фідбек та побачити результат своїх зусиль так швидко, як у фронтенді, де більшість твоїх дій повʼязана зі взаємодією з користувачем. МІФ №2 Робота на фронтенді складається з однотипних задач. Насправді у фронтенд-розробника різноманітні задачі. Це не тільки створення інтерфейсів окремих компонентів або сторінок, а ще й робота з анімацією, написання автотестів, бізнес-логіки, налаштування аналітики, інтеграція нових технологій та багато чого іншого. Також це постійна комунікація з багатьма командами: дизайну, бекенду, QA, SEO, менеджерами, замовниками та іншими. МІФ №3 Для розвитку потрібно вивчати більше сучасних фреймворків та бібліотек. Часто розробники переконані, що шлях розвитку в цій сфері полягає у вивченні якомога більшої кількості бібліотек: чим більше їх знаєш, тим краще. При цьому в них залишаються прогалини у фундаментальних знаннях, без яких складно уявити подальший розвиток девелопера. Йдеться про основи та принципи програмування, парадигми, патерни — на будь-якому складному проєкті без цих основ буде дуже важко працювати ефективно. Принципи програмування допомагають краще організовувати код, робити його зрозумілим для інших розробників. Патерни — це підходи до вирішення абстрактних проблем. Більшість із них не пов'язані з конкретним доменом або сферою знань, але допомагають розуміти програмування загалом. Вміння їх використовувати допомагає позбавитися багатьох проблем, які можуть виникати в процесі розробки, та забезпечують якість коду. Маючи ці знання, фронтенд-девелопер може швидше розвиватися вертикально або ж опановувати бекенд, фулстек чи інші сфери розробки. Крім того, такі навички допомагають розробнику обирати найефективніші інструменти та бібліотеки для його потреб. МІФ №4 HTML, CSS та JavaScript — це технології, які не розвиваються та не змінюються. Це твердження абсолютно невірне. Щороку в CSS, HTML та JavaScript виправляються недоліки та додаються нові можливості. Наприклад, з найцікавішого, що з'явилося в CSS за останній час, можна виділити: @layer — нарешті дозволяє вирішити одну з найскладніших проблем в CSS, а саме контроль над каскадом та конфліктами між селекторами. :has() — дає перевірити, чи містить батьківський елемент хоча б один із вказаних елементів. Цього дуже не вистачає в роботі. Умовні конструкції when/else — цікавий напрям розвитку, який ймовірно може стати стандартом. З останніх помітних нововведень у JavaScript — private fields та розширення синтаксису static, що наближають JS до класичних мов ООП, таких як Java, C# тощо. МІФ №5 Нативні застосунки завжди будуть зручнішими за веб. Дійсно, нативні застосунки можуть бути зручнішими для користувача ніж вебзастосунки, якщо дають доступ до певних функцій пристрою, яких не має браузер. Одна з їхніх переваг — швидкість. Однак це змінилося з появою прогресивних вебзастосунків (Progressive Web Apps) та зростанням їхньої популярності. Вони можуть працювати в режимі офлайн та мати багато функцій, які раніше були доступні лише в нативних застосунках. Після встановлення на головний екран, вони працюють швидше, ніж у браузері. Крім того, PWA значно дешевші та простіші у розробці та підтримці. Наразі їх можна публікувати в Google Play та Microsoft Store серед інших продуктів. Водночас існує багато інструментів, які дозволяють фронтенд-розробникам створювати гібридні застосунки на JavaScript для різних платформ. Наприклад, Electron можна використовувати для створення продуктів для десктопу, а React Native — для мобільних пристроїв. Цей напрям розробки також активно розвивається, постійно з'являються нові технології. Наприклад, фреймворк Tauri, що поєднує швидкість Go з легкістю розробки за допомогою HTML, CSS та JavaScript для створення десктопних застосунків. Але PWA та гібридні застосунки не є ідеальним рішенням, яке може повністю замінити нативні. Все як завжди залежить від складності застосунку та потреб бізнесу. МІФ №6 Фронтенд-девелопер має обовʼязково добре розумітися в дизайні. Фронтенд-розробник має вміти взаємодіяти з дизайном. Особливо на ранніх етапах проєкту, коли треба закласти дизайн-систему в коді для подальшого успішного розвитку продукту. Але з іншого боку, одна з цінностей фронтенд-девелопера полягає в тому, що він може поставити себе на місце користувача. Він — та людина, яка першою буде взаємодіяти з інтерфейсом. Дизайнерський досвід та фокус на правилах прийняття тих чи інших рішень можуть обмежувати його у судженнях. МІФ №7 Сторінки та вебзастосунки стають занадто складними. З одного боку, вебзастосунки з кожним роком стають все складнішими, що призводить до проблем з продуктивністю. З іншого боку, стандарти швидкості від Google надають жорсткі критерії, яким мають відповідати сайти для успішного SEO-просування. У відповідь на це зʼявляються технології, що вирішують проблеми оптимізації, які вже не можна ігнорувати в Single-page Application (SPA). З новими фреймворками можна не витрачати багато зусиль на самостійне вирішення проблем перформансу. Серед них, наприклад, Next.js, який вже став майже стандартом для створення нових продуктів на React, або новачки, такі як Astro, що пропонують поглянути на створення сайтів під новим (старим) кутом Multiple-page Application, розробляючи їх на улюблених SPA-фреймворках. МІФ №8 Мікрофронтенд — універсальне рішення, за яким майбутнє та яке підходить усім. Проблеми, для вирішення яких підходить мікрофронтенд, зʼявляються, коли вебзастосунок стрімко зростає разом з командою. Або ж йому вже стільки років, що його надто складно підтримувати та треба ітеративно покращувати. Мікрофронтенд — це підхід, що дозволяє працювати з певними частинами проєкту, незалежно від інших. Наприклад, одна команда може створювати логіку пошуку, а інша сфокусована на профілі користувача. Вони не перетинаються у виборі технологій і не залежать одна від одної. З одного боку цей підхід призводить до «зоопарку технологій», а з іншого — додає гнучкості у формуванні команд, наймі, підходах, які використовуються на проєктах. Чи ефективний такий підхід? Так, але підходить він не всім. Не варто використовувати його без потреби та конкретної проблеми, яку треба вирішити.

Genesis посіла перше місце у рейтингу найкращих роботодавців воєнного часу за версією видання Forbes Ukraine. Це перше дослідження вітчизняного ринку роботодавців під час війни, яке стало наймасштабнішим в історії рейтингу Forbes — участь у ньому взяли 28 663 респондентів. Genesis вперше брав участь у рейтингу роботодавців та набрав 87 балів зі 100 можливих. Максимальну оцінку компанія отримала в категоріях «Можливості для розвитку», «Відчуття захисту» та «Соцпакет». «Це визначне досягнення для нас — можливо, більше, ніж інші бізнес-результати. Вважаю, що для будь-якої компанії під час війни те, що вона робить для своїх співробітників, членів їхніх родин (зокрема, тих, хто на фронті) — це пріоритет. Як кофаундингова компанія ми багато ресурсів інвестуємо в розвиток бізнесів нашої екосистеми, а також у людей та їхню безпеку. Ми вдячні колегам, які віддали такі високі оцінки під час голосування, що свідчить про взаємну підтримку та довіру. Вдячні всій команді, яка з 24 лютого зробила все можливе і неможливе, щоби компанія продовжила працювати», — коментує CEO Genesis Володимир Многолєтній. З IT-галузі до рейтингу також потрапили 12 бізнесів, що становить майже чверть учасників (24%). Це засвідчує стійкість галузі під час війни та її фокус на збереженні максимально сприятливих умов праці для своїх співробітників, наскільки це можливо у воєнний час. Видання Forbes спільно з сайтом пошукту роботи Work.ua вже втретє організовують національний рейтинг роботодавців. Дослідження було відкритим — співробітники бізнесів із різних сфер могли номінувати свою компанію. Учасників оцінювали за наступними критеріями: бренд роботодавця, винагорода, умови праці, соцпакет, внесок у перемогу, інформаційна відкритість, відчуття захисту, можливості для розвитку тощо.

Сьогодні всі, хто має бажання та хист до викладання, перебувають у вигідній позиції. Завдяки різноманітним онлайн-платформам, інструментам і, власне, мережі інтернет запуск власного курсу стає складною, але цілком досяжною метою. Однак для успішного освітнього продукту потрібно не лише мати знання у своїй галузі, а й розуміння, як спроєктувати курс з точки зору проджект-менеджменту. Ключові моменти процесу ми й розглянемо в цій статті. Усі нюанси розробки власного освітнього продукту формулювала та пояснила Internal Education Lead в Genesis Вікторія Прищепа. Вікторія понад сім років створює освітні проєкти, близько трьох — займається навчанням співробітників, а нещодавно стала лідом напряму та будує систему корпоративного навчання в Genesis. Своїм досвідом також ділиться Олесь Дібрівний, Unity Developer у Keiki з екосистеми Genesis. У продукті він закриває всі завдання пов’язані з грою — від ігрових механік до аналітики та оплат, а також поєднує роботу розробником із викладанням в університеті, де свого часу запустив власний курс > Визначаємося з мотивацією > Аналізуємо ринок > Обираємо тему > Тестуємо гіпотезу > Обираємо формат > Готуємося до виступу > Оцінюємо прогрес студентів > Просуваємо готовий курс З чого почати: визначаємося з мотивацією Найперше, що потрібно для запуску свого онлайн-курсу — зрозуміти, навіщо вам викладання. Ось декілька можливих причин: ви хочете поділитися досвідом. З часом у людини виникає бажання передавати свої знання та допомагати розвиватись іншим; ви прагнете «прокачувати» особистий бренд. Викладання допомагає збільшити власну видимість у галузі, заявити про себе як про експерта та розширити коло своїх контактів; вам потрібно спростити процес онбордингу. Наприклад, ви — єдиний розробник у продукті, й збираєте свою команду. Курс зменшить витрати часу та сил на знайомство новачків з процесами, практиками та технологічним стеком проєкту; ви розробили специфічний функціонал і його треба пояснити. Якщо нещодавно ви зарелізили нову унікальну фічу, курс допоможе зекономити час на її пояснення для команди або зовнішньої аудиторії. Свій курс можна записати з будь-яким ґрейдом на будь-якому етапі роботи в компанії, впевнена Internal Education Lead Вікторія Прищепа. «Відмінними будуть специфіка та глибина інформації, якою ви прагнете поділитися. Фахівці рівня джуніор можуть підготувати теоретичний матеріал та вже готові фреймворки, тоді як мідл-розробники розкажуть про особливості роботи з продуктом конкретного спрямування. Сеньйори, зі свого боку, відфільтрують неприкладну теоретичну інформацію, дадуть глибші практичні вправи та розкажуть про унікальні речі з власного досвіду». Про свій не зовсім типовий досвід розповідає Олесь Дібрівний Unity Developer у Keiki. Маючи бекґраунд у мові програмування С#, він почав викладати розробку ігор та працювати з рушієм Unity, а потім став профільним розробником. «Мені цікаво працювати зі студентами та брати участь у розвитку молодшого покоління. Крім того, викладання стимулює власний розвиток, адже щоб пояснити матеріал, потрібно добре розібратися в темі. Тому коли в аспірантурі мені запропонували викладати основи геймдеву, я погодився. Спочатку ми робили простий 2D-платформер, надихаючись каналом Brackeys. В основному займались ігровими механіками й навіть не думали про архітектуру коду чи інші правила побудови проєкту», — говорить він. Аналізуємо ринок Перед запуском курсу варто впевнитися, що матеріал знайде своїх слухачів та буде актуальним. Ось з яких кроків може складатися аналіз ринку: Дослідження конкурентів. «Перегляньте, що пропонують освітні платформи, як-от Coursera чи Udemy. Дослідіть, до якої аудиторії вони звертаються, чим вони унікальні, які підходи використовують для запуску своїх курсів тощо», — говорить Вікторія Прищепа. Робота з відгуками студентів курсів конкурентів. «Там теж можуть знайтися цікаві інсайти. Наприклад, в цілому, тема цікава, але матеріал краще запакувати не в цілий курс, а в компактний ґайд. Якщо попит на курси конкурентів загалом високий, то, ймовірно, ваш також знайде свою аудиторію », — говорить Вікторія Прищепа. Використання моніторингових інструментів. Якщо ви визначилися з напрямом, але сумніваєтеся щодо спеціалізації, потрібно оцінити ринкові тренди. Згодяться інструменти на кшталт Google Trends та Google Keyword Planner. Вони дадуть змогу вивчити попит на конкретний термін у певний час, порівняти, ключові слова на предмет збільшення чи зменшення популярності, визначити середній обсяг пошуку слів на місяць. Від цього також можна відштовхуватися. «Коли я починав роботу над своїм курсом з Unity, аналогічних пропозицій на українському ринку майже не було. Тож я переглядав матеріали на іноземних платформах, підглядав практики та підходи там. Потім, уже маючи розробника в геймдеві, я міг чіткіше визначити, який матеріал, й у якому форматі давати, що пояснити конче необхідно, а чим можна знехтувати», — каже Олесь Дібрівний. Обираємо тему Найперше, що потрібно врахувати — це ваші компетенції, говорить Вікторія Прищепа. «Те, що ви робите на роботі кожного дня, може стати абсолютно новим знанням для іншої людини», — зазначає вона. Далі ідею варто перевірити за кількома іншими критеріями — відповідність потребам ринку, рівень складності, унікальність, новизна тощо. Ідеальна тема має бути комплексною, тобто поєднувати різну інформацію в єдину логічну структуру. Тоді автор зможе дати декілька теоретичних лекцій, практичні завдання, запропонувати кейси, вправи, додаткові матеріали тощо — і студенти краще засвоять матеріал. Наприклад, на курсі з темою «Архітектура мікросервісів» можна розповісти про відмінності мікросервісів від монолітів, архітектурні патерни та принципи, на яких вони базуються, потрібні технології, як-от Docker, Kubernetes, Amazon ECS, Google Kubernetes Engine тощо. А потім запропонувати самостійно розгорнути мікросервіс у «хмарі» або розробити систему моніторингу. Тестуємо гіпотезу Щоб не втрачати час та зусилля на продукт, який не підходитиме цільовій аудиторії, варто зробити MVP, впевнена Вікторія Прищепа. Вона радить підготувати одну лекцію на відповідну тему та протестувати її на колегах або, якщо вдасться, запросити людей, що не працюють із вами. Або можна зробити драфт курсу та запропонувати його пройти декільком людям. Орієнтуватися далі допоможе фідбек — скільки людей зареєструвалося, чи були вони активними, які питання ставили, як загалом оцінили матеріал та наскільки ваша тема актуальна для аудиторії. «Без такої перевірки ви ризикуєте витратити час, сили, кошти на продукт, який буде не релевантним для обраної аудиторії. А щоб його переробити потрібно буде витратити у два рази більше ресурсів. Звичайно будь-який продукт потрібно вдосконалювати з часом. Але з MVP ви точно знатимете, що під час запуску зробили максимум», — говорить Вікторія. Обираємо формат Рідко буває так, що курс створений повністю в одному форматі — наприклад, тільки відеоуроки або тільки текст. Зазвичай їх комбінують між собою, аби студенти краще засвоювали матеріал. Ось декілька найбільш розповсюджених варіантів. Вебінари Онлайн дає змогу взаємодіяти зі студентами в режимі реального часу: презентувати матеріал, відповідати на запитання, брати участь у дискусіях. Тут зручно ділитися екраном та показувати, як працює та чи інша технологія, розбирати кейси та обговорювати домашні завдання. Найбільший виклик цього формату — залучити аудиторію та утримати її увагу, адже зберігати концентрацію впродовж години чи більше може бути непросто. Є багато способів, як це зробити: наприклад, говорити про аудиторію «ви», «вам», «у вас», залучати слухачів до дії, розмірковувати вголос та ставити запитання, уточнювати, чи все зрозуміло. Більше про утримання уваги можна почитати тут, тут і ось тут. Оптимальна тривалість вебінару — година-півтори. Заздалегідь записані уроки Один із найбільш оптимальних форматів — він дає студентам змогу передивлятися матеріал у своєму темпі в зручний час. Якщо ви пояснюєте складні концепції чи фреймфорки, в учнів завжди буде змога переглянути лекцію ще раз, аби точно розібратися в предметі обговорення. На відміну від живого вебінару, записана лекція не вимагає від викладача викласти матеріал без помилок з першого разу, тож переписувати та вдосконалювати відео можна, поки ви не будете задоволені фінальним результатом. «Останні декілька років мої пари проходять так: я відкриваю Unity, показую, що і як я роблю, і записую все це на відео. Досвід із вебінарами показав, що користь від них менша: багато слухачів не можуть бути присутніми в певний час. До того ж мені зручно записувати лекції рано вранці чи пізно ввечері, щоб не переривати робочий день — а в такий час не всі можуть нормально сприймати новий матеріал. Якщо накопичуються питання, ми плануємо «живу» консультацію», — розповідає Олесь Дібрівний. Текстові матеріали Зазвичай різноманітні ґайди, інфографіки, статті та інструкції пропонують для додаткового опрацювання. Наприклад, коли потрібно заглибитися в документацію, розібратися в певних аспектах роботи технологій тощо. Втім, система з таких документів може стати й окремим освітнім продуктом — якщо лектор впевнений у здатності студентів до самостійного навчання. Сильною стороною подібних матеріалів стає унікальний дизайн, організація та структура. Подкасти Хороший варіант для тих, хто любить вчитися на ходу. Він не підійде для дуже «технічних» тем, які вимагають багато графіків, схем, коду та фреймворків, але вдало доповнить курс розмовами з експертами, дискусіями, порадами. Також формат підійде для запису питань та відповідей. Головне, про що треба пам’ятати — хороший мікрофон, адже комфорт слухачів у цьому випадку дуже залежить від якості звуку. Власні проєкти Формат може поєднувати всі перелічені вище та давати студентам змогу вирішувати реальні завдання. На курсах від Genesis подібним проєктом може стати застосунок, гра або власне медіа. «Наприкінці мого курсу студенти мають показати готову гру. Для цього я проводжу їх усіма етапами створення подібного продукту — від встановлення Unity до завантаження на Google Play Market. Перші шість лекцій — це основи: ми знайомимося з тим, як працює двигун, мовою програмування C#, звикаємо писати код згідно код-стайлу. Далі, коли ми вже маємо персонажа, який ходить вліво-вправо, я дивлюся, що потрібно для завершення гри. Якщо це, наприклад, RPG (Role-Playing Game — гра, де потрібно керувати одним персонажем), то потрібні вороги та NPC (Non-Player Character — персонажі, за яких грає комп’ютер), зброя, якою може скористатися персонаж, продумані рівні. Я намагаюся зробити так, щоб вони працювали над проєктом у середовищі, наближеному до робочого. Для цього ми, наприклад, користуємося системами контролю, як-от Jira та Bitbucket від Atlassian» — говорить Олесь Дібрівний. Формуємо програму На цьому етапі потрібно визначити мету, зміст, структуру, методи та засоби навчання, а також сформулювати очікуваний результат. На основі останнього ми визначаємо, які саме знання потрібно дати людям, уточнює Вікторія Прищепа. Це називається методологія створення курсу. Зазвичай курс ділиться на модулі, у кожному з яких є декілька тем. Спочатку викладається теорія, потім практика, яка підкріплюється домашніми/практичними завданнями. Вікторія радить відвести на теорію не менше 10% усього курсу, і додавати до модулів невеликі вступні лекції. Підхід дасть глядачам змогу налаштуватися на тему та ознайомитися із запропонованою термінологією. Перевірку прогресу та домашні завдання можна гейміфікувати. Наприклад, зробити загальний рейтинг слухачів чи начисляти бали-зірочки за виконані вправи. «Курс, який я веду передбачає перехресну перевірку робіт, тобто спочатку домашнє завдання студента переглядають однокурсники. Вони знаходять частину помилок, а далі вже підключаюся я — дивлюся фінальну версію через Pool Request. Наприкінці студенти уже готують презентацію свого фінального продукту — розповідають, як і над чим вони працювали протягом семестру та показують готову гру», — розповідає Олесь Дібрівний. Готуємося до виступу Ось обладнання, яке вам знадобиться, щоб записати уроки: комп'ютер (в ідеалі, з двома моніторами) зі стабільним інтернет-з'єднанням; вебкамера; мікрофон; навушники або колонки; клікер; мікшер (опціонально). Далі треба визначитися із софтом та сервісами. Щоби записати відеоряд знадобиться Zoom чи OBS Studio, відредагувати звук допоможе Audacity, якщо плануєте монтувати відео — можна скористатися Adobe Premiere Pro чи Final Cut Pro. Існують також цілісні платформи для навчання — LMS-системи на кшталт Academy Ocean. Їх не обов'язково використовувати на етапі MVP. Такі ресурси підійдуть, коли ви запускатимете повноцінний курс чи забажаєте масштабувати власні освітні проєкти. «Спочатку краще обрати простіші інструменти, а LMS використати, коли вже матимете вдосконалений після першої ітерації курс», — говорить Вікторія Прищепа. Оцінюємо прогрес студентів Виміряти його можна за допомогою тесту на перевірку знань — на початку й наприкінці навчання. Така практика допоможе зрозуміти рівень засвоєння теоретичних та практичних навичок студентів. Найкращий варіант визначити рівень студентів після курсу — це груповий чи індивідуальний проєкт, впевнена Вікторія Прищепа. Вона радить заздалегідь сформулювати критерії для його оцінки, визначити, скільки балів «важить» кожний із них та поділитися інформацією зі студентами. «Без чітких критеріїв люди не розумітимуть, що ви маєте на увазі під «успішним проєктом». Кожну оцінку варто декомпозувати та пояснити. Тобто, якщо за функціональність проєкту ви ставите від 1 до 5 балів, то людина має знати, що на 2 бали проєкт може працювати з помилками, а щоб отримати 5 — всі баги потрібно почистити». Олесь Дібрівний оцінює роботи студентів за п’ятибальною шкалою. Ось як він пояснює вибір оцінки. «Я маю три рівні, щоб відстежити прогрес студентів. У першому випадку я бачу, що завдання виконували з інтересом. Наприклад, я попросив зробити персонажа, який ходить вправо-вліво, а студенти зробили так, що він ще і стрибає. Другий тип я називаю «цього достатньо» — коли люди подивилися мої відеоуроки, скопіювали код (разом із помилками), підставили іншу графіку та здали. Третя категорія характеризується фразою «здав і здав». Тут люди просто знайшли готовий шматок коду в мережі, не розібралися, чи він взагалі робочий, і надіслали, як виконане завдання. Я вже всі ці шматки впізнаю, й можу у відповідь надіслати посилання, звідки він взятий». Просуваємо готовий курс Без просування аудиторія просто не дізнається про продукт, тому це важлива частина його створення. Є декілька варіантів, як саме розказати аудиторії про ваш курс. «Перший передбачає, що у вас уже побудований сильний особистий бренд. Тоді люди розуміють, у чому ви експерт. Тут можна розпочати з безкоштовної лекції або серії таких, і поступово просувати меседж про курс. Наприклад через особисті соцмережі чи в межах команди», — розповідає Вікторія Прищепа. Якщо ж особистий бренд ще не сильно розвинений, просування потрібно будувати повністю з нуля. «Я раджу почати з LinkedIn — це професійна соцмережа, тому, ймовірно, ваша аудиторія саме там, — говорить Вікторія Прищепа. — Можна використати робочі канали комунікації, завести блог на Medium, попросити ваших колег та знайомих поділитися інформацією про курс, записати безкоштовну лекцію. Це дасть людям змогу дізнатися про вас та поступово ставати вашою аудиторією». Особистий бренд можна розвивати також через YouTube та публікації в профільних медіа, говорить Олесь Дібрівний. «У мене є невеличкий канал, де я викладав записи лекцій для студентів, зараз планую його розвивати та оновлювати матеріали. Крім того, у мене є публікація на DOU, і зараз я готую ще одну статтю. Такі освітні матеріали добре заходять», — говорить він. Ще один варіант — звернутися напряму до освітніх платформ та запропонувати себе як експерта в певній темі. Майданчиком може стати Coursera, Udemy, Khan Academy або українські Prometheus, Projector тощо. Зазвичай платформа бере на себе організацію продакшену та просування. Єдине — перед стартом роботи варто дізнатися про всі політики платформи та зрозуміти, які матеріали вони шукають. Інакше може виявитися так, що ваш заздалегідь записаний чи продуманий курс не підійде за характеристиками платформи.