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

Продовжуємо ділитися тим, як проходять технічні співбесіди у продуктових ІТ-компаніях. Цього разу розповімо, які питання ставлять iOS-розробникам різних ґрейдів. Артур Майорський, iOS Team Lead в Universe, поділився своїм підходом до проведення інтервʼю, пояснив, чому не питає у кандидатів про ООП та іншу фундаментальну теорію, як формуються вимоги до вакансії, та чому найефективніше будувати розмову навколо технічних інтересів. > Як проходить співбесіда iOS Developer > Питання для Junior iOS Developer > Питання для Middle iOS Developer Як проходить співбесіда iOS Developer До всіх iOS спеціалістів є набір стандартних базових вимог, як от знання Swift та фреймворків (UIKit або SwiftUI). Водночас у кожної компанії є чимало нішевих запитів: наприклад, досвід роботи зі сканерами чи ML, відеостримінгами чи картами тощо. На ці теми зазвичай і питають кандидатів. В Universe, як у деяких інших продуктових компаній, немає стандартних шаблонів із питаннями. Коли зʼявляється необхідність найняти людину, ми формуємо для неї набір завдань та прогнозуємо роботу на 6-12 місяців. На основі цих завдань і формуються вимоги до позиції та теми для інтервʼю. Таким чином дві вакансії Junior iOS Developer можуть бути абсолютно різними. Наприклад, якось шукали одну людину під нову апку, а іншу — для створення A/B тестів на онбордингу застосунку, і один кандидат зовсім не підходив на позицію іншого. Перше, що я дізнаюся на співбесіді — чим технічно цікавиться кандидат. Я намагаюся це дізнатися з перших питань: що він вивчав, що читав, що дивився, які були цікаві завдання на попередній роботі. Визначивши їх, ставлю технічні питання з цієї теми, щоби дізнатися, наскільки глибоко людина може самостійно розібратися в цікавих для неї речах. Наступний етап — перевірити знання у менш захоплюючих, але важливих аспектах програмування. Це база, з якою постійно стикаєшся, і важливо не просто закривати завдання, а розуміти, що і чому ви робите. Як правило, я беру одну тему, ставлю базове питання і прошу людину своїми словами розказати, що вона знає про це. Наприклад, робота з памʼяттю в iOS або зі стандартним компонентом UITableView. Далі уточнюю: що це таке, як воно працює, де зберігається тощо. З кожним новим питанням я заглиблююсь, щоби зрозуміти, на якому рівні знань людина. Коли я визначаю глибину, я перестрибую на іншу тему. У такий спосіб зачіпаю близько пʼяти базових тем, по кожній з яких можна говорити хвилин по 10. Усі питання я завжди беру з контексту розмови. За таким принципом я проводжу інтервʼю з Junior та Middle розробниками. Спиратися в співбесіді на інтереси кандидата, на мій погляд, ефективно. Для компанії важливо найняти людину, яка зможе розвивати потенціал і зростати разом із проєктом. Якщо ж робочі завдання не відповідатимуть його інтересам, це буде неможливим. Питання для Junior iOS Developer Більшість «хардових» питань ми перевіряємо тестовим завданням. Наприклад, Junior iOS Developer має відтворити онбординг одного з наших застосунків (набір екранів, які зʼявляються при першому запуску та пояснюють, як ним користуватися) з використанням певного стека. Загалом за тестовим завданням одразу можна оцінити технічну базу підготовки. На співбесідах ми не питаємо принципи ООП чи фундаментальну теорію. Якщо людина не знає супербазових речей, це помітно одразу. Якщо ж знає — це насправді ні про що не свідчить. Намагаюся ефективно витрачати час на співбесіду, ставлячи питання, які справді скажуть щось про людину. Деякі з питань — кейсові. Наприклад, «як створити кнопку, яка буде пульсувати? Кандидат пропонує ідеї, і ми заглиблюємося в деталі. Це може звучати, як просте питання, яке знає кожен розробник, але на останніх пʼяти співбесідах ніхто не запропонував оптимального рішення. Водночас у нас немає вимоги, щоби кандидат відповів правильно на всі питання. Якщо він вміє вчитися, зможе швидко заповнити прогалини. Часом я можу підняти тему, яка не часто застосовується на практиці. Наприклад, є популярне питання на співбесідах: «Що таке copy-on-write». Часто розробники знають про цей механізм тільки те, що поверхнево прочитали в статті, готуючись до інтервʼю. Одразу видно, якщо вони ніколи не стикалися з цим на практиці. Дізнатися, чи розуміє людина, як цей механізм реалізований, — просто. Треба знати назву однієї функції та вміти описати, як вона працює. Водночас якщо кандидат не знає — це не страшно. Це питання не належить до категорії «цікаве» чи «важливе», проте показує глибину знань та кругозору людини, вміння вчитися, закопуватися в різні теми. Намагаюся знаходити подібні питання «із зірочкою», виходячи з інтересів кандидатів. Нижче перелік запитань, з яких можна почати заглиблюватися в різні теми. Swift та UIKit 1. Чим відрізняється структура від класу? 2. Що таке Optional у Swift і як вони використовуються? Які проблеми можуть бути повʼязані з ними? 3. Які основні переваги використання guard у порівнянні з if let? 4. Що таке протоколи у Swift і як вони використовуються? 5. Що таке Auto Layout? Чому він важливий для розробки iOS застосунків? 6. Що таке value-type та reference-type у Swift? Коли їх використовувати? 7. Чому Apple надає перевагу використанню value type за замовчуванням? Що не так із використанням reference type? 8. Для чого використовується ключове слово mutating? 9. В чому різниця між Array і Set? 10. Що таке замикання (Closure)? Поясніть, що таке trailing closures? 11. Чи використовували клас URLSession? Як це працює? 12. Що таке дженерики? Як ви використовуєте їх у своєму коді? 13. Як ви використовуєте Enum та Pattern Matching для створення читабельного коду? 14. Як ви реалізуєте error handling у Swift? 15. На що варто звернути увагу при роботі з UITableView та UICollectionView? 16. Як реалізувати навігацію між екранами у застосунку? 17. Поясніть життєвий цикл iOS застосунку? 18. Як передати дані від одного контролера до іншого? 19. Розкажіть про цикли життя UIViewController в UIKit? 20. Яка різниця між frame та bounds у UIView? 21. Як реалізувати тестування UI в iOS? Архітектура 22. Які основні компоненти архітектури MVVM використовуються в iOS розробці? 23. Що таке Dependency Injection, і як воно впливає на тестованість коду? 24. Як ви реалізуєте асинхронну обробку даних в iOS, і чому це важливо? 25. Поясніть різницю між MVC і MVVM? Які плюси та мінуси у кожного з шаблонів? 26. Що таке Singleton і в яких випадках варто використовувати його в iOS розробці? Робота з пам'яттю в iOS 27. Як уникати memory leakage у вашому коді? 28. Які інструменти використовуєте для виявлення проблем з пам'яттю та їхнього вирішення? 29. Як можна керувати циклами утримання (retain cycles)? Які проблеми можуть виникати, пов'язані з ними? 30. Як використовувати ARC? Як це працює? 31. Як оптимізувати роботу зі структурами та об'єктами для ефективного використання пам'яті? Робота з мережею 32. Як створити мережеві запити в iOS застосунках і обробити відповіді? 33. Як використовувати URLSession для виконання HTTP-запитів? 34. У чому різниця між GET та POST запитами? Коли використовувати один чи інший? 35. Як обробляти та парсити JSON-відповіді у застосунку? 36. Як обробляти аутентифікацію та авторизацію в застосунку? 37. Як кешування допомагає уникнути проблем зі збільшенням кількості запитів на сервер? 38. Що таке RESTful API? Чому вони використовуються в розробці застосунків? Бази даних 39. Як використовувати Core Data для виконання запитів до бази даних? 40. Як керувати версіями бази даних при змінах у застосунку? 41. Як провести міграцію даних при оновленні застосунку? 42. Як налаштувати взаємодію з віддаленими базами даних? 43. Як проводити асинхронні операції з базою даних для збереження продуктивності? 44. Як використовувати індексацію для прискорення запитів до бази даних? Робота з анімацією та інтерфейсом користувача 45. Поясніть, як застосунок розуміє, на який елемент інтерфейсу натиснув користувач? 46. Опишіть досвід використання Core Animation для створення анімації? 47. Розкажіть, як створити переходи між екранами? 48. Які проблеми з продуктивністю можуть виникнути при використанні складної анімації? Як їх вирішити? 49. Опишіть реалізацію взаємодії користувача з жестами (наприклад, swipe, pinch, rotate)? 50. Як реалізувати анімацію взаємодії з таблицями та колекціями? Питання для Middle iOS Developer Принцип проведення співбесіди для Middle iOS Developer не відрізняється від Junior: дізнатися, що найбільше цікавить кандидата в розробці, та поставити низку технічних питань, щоби зрозуміти глибину знань. Різниця лиш у тому, що питання можуть бути складніші, а відповіді — розгорнутіші. Думаю, такий підхід допомагає зрозуміти, чи справді знання кандидата відповідають ґрейду. Є низка питань, на які цікаво подискутувати, наприклад, використання Singleton, Force Unwrap, Unowned. На них немає правильної відповіді, та можна зрозуміти будь-яку позицію. Наприклад, іноді людина не хоче ризикувати та використовувати Force Unwrap, а іноді готова взяти відповідальність, іноді це обґрунтовано, а іноді — ні. Загалом, майже в кожній темі можна довести, що це працює не так, як написано в документації. Кейси 51. Застосунок відображає галерею фотографій, і користувачі скаржаться на повільне завантаження. Як вирішити цю проблему? 52. У застосунку користувачі можуть редагувати дані в офлайн-режимі, а після підключення до мережі вони мають синхронізуватися з сервером. Як реалізувати цей механізм, враховуючи можливі конфлікти та помилки з'єднання? 53. Застосунок виконує багато асинхронних запитів до різних API. Як забезпечити керування потоками та ефективну обробку помилок? 54. Застосунок має працювати однаково добре на iPhone та iPad з різними розмірами екрана. Як оптимізувати дизайн для різних пристроїв? 55. Під час роботи виникла проблема з конфліктом версій залежностей. Як би ви шукали, в чому проблема? 56. Користувачі скаржаться, що застосунок витрачає багато заряду батареї. Як зменшити вплив на життєвий цикл батареї? 57. Застосунок обробляє конфіденційні дані користувачів. Як гарантувати безпеку? 58. Застосунок отримує дані з декількох різних API. Як би ви керували цим та вирішували проблеми несумісності? 59. Команда вирішила додати новий функціонал. Як спланувати розробку та інтеграцію нової фічі, щоби зберегти сумісність з існуючим кодом? 60. Застосунок має підтримувати різні версії iOS. Що треба зробити, щоби інтерфейс виглядав і працював належним чином на різних версіях? 61. Потрібно додати кастомну анімацію при переході між певними екранами. Як це реалізувати? 62. Ви хочете додати анімації до взаємодії з об'єктами у списку. Як це реалізувати? Теми для дискусій 63. Чи використовуєте ви Force Unwrap, Optional Chaining чи Guard Statements? Які переваги та недоліки є у кожному підході? 64. Як ви ставитеся до використання Singleton? Які є переваги та ризики? 65. Як ви оцінюєте використання ключового слова mutating у Swift для методів структур? Як це впливає на безпеку коду? 66. Що би ви обрали для реалізації анімації — Core Animation чи UIKit? Чому? 67. Як визначити, коли використовувати замикання, а коли — делегати? 68. Що обрати для паралельного виконання завдань — GCD чи Operation? 69. Як ви ставитеся до використання ключового слова final для обмеження поведінки та перевизначення класів та методів? Які є ризики? 70. Як ви ставитеся до використання лінтерів? Як це впливає на єдність стилю коду та загальну якість? 71. Як ви ставитеся до використання замикань для обробки асинхронних операцій у Swift?

Український стартап NewHomesMate, раніше знаний під назвою Propertymate, розробляє маркетплейс для пошуку та купівлі житла в новобудовах на американському ринку. Заснований у 2018 році, стартап встиг зробити декілька півотів, залучити інвестиції та розширитися на п’ятнадцять міст у США. Наразі на платформі виставлено понад 140 000 будинків, а 2023-го NewHomesMate виріс за доходом більше, ніж утричі. У новому випуску рубрики ми поговорили з Софією Вишневською, кофаундеркою та COO NewHomesMate. Вона розповіла про болі, з якими зіштовхується кожен, хто запустив свій стартап, та поділилася своїм «фаундерським» поглядом на труднощі. Кожен фаундер вірить у свій продукт і прагне його вдосконалювати, тож завжди знайде, що варто покращити. Через це він має постійно обирати, куди правильніше вкладати кошти — і визначати пріоритети часто буває складно. На перших етапах розвитку стартапу першочергове завдання — пропрацювати базу, тобто знайти ключову особливість продукту, яка генеруватиме прибуток. У цей час кошти зазвичай йдуть на розробку продукту і тестування гіпотез. Деякі з них можуть привести до дво- чи навіть трикратного зростання. Чим зріліший стартап — тим складніше. Під час scale чи growth stage гроші розподіляються також на інфраструктуру та операційні витрати — і трекати результат вкладень уже не так легко. Крім того, тести стають дорожчими. Наприклад, у нас є гіпотеза, що для зростання бізнесу потрібно сформувати сейлз-команду з чітким компенсаційним планом. Подібний тест вимагає багато часу, зусиль та витрат, а результат буде видно лише у довгостроковій перспективі. Стартапи вирізняються серед інших бізнесів технологічною складовою та швидким масштабуванням. Відповідно, компанія, яка ще не знайшла Product Market Fit, може бути операційно прибутковою, але це не означає, що вона успішна. Тому необхідно знайти продукт, який чітко збігається з потребами ринку, а для цього доведеться багато експериментувати й помилятися. На початку в нас також було багато поневірянь. До того, як стати тим NewHomesMate, який знають зараз, ми двічі змінювали напрям роботи. Перший прототип був B2B-платформою автоматизації продажів для забудовників. Однак цикл продажів нерухомості у США занадто довгий і забюрократизований, тому ідея не спрацювала. Тоді ми перепрофілювалися на продукт, спрямований на рієлторів. Однак він теж не спрацював, адже рієлтори займаються здебільшого вторинним ринком. Утім, ми не зупинилися. Під час пошуків бізнес-моделі ми познайомилися з багатьма людьми зі сфери, зрозуміли їхні болі, розібралися, як функціонує ринок, вивчили культурні відмінності між американцями та українцями. Так, мета забудовників — швидко та легко продавати нерухомість. Проблема покупців — вони не можуть знайти оптимальне житло та не розуміються на процесах покупки нерухомості. Ми відчули, що знайшли той самий метч. Гіпотезу перевіряли швидко: за три години створили лендинг, запустили рекламу на $100-200 та зробили коротке опитування користувачів. Воно показало, що люди дійсно зацікавлені у подібному сервісі — і ми знайшли свою бізнес-модель. Незрозумілі умови — це стрес та виклик для будь-якої людини. Але фаундеру потрібно завжди залишатися гнучким та мислити поза рамками. Тому часто зовнішні фактори стають каталізаторами до критичного мислення та суттєвих змін. За складних умов народжуються й залишаються найкращі. Мені подобається метафора: якщо наближається хвиля, то ти або зловиш її, або потонеш. Так, свій Product Market Fit ми знайшли саме під час пандемії. 8 березня 2020 року ми закінчили акселераційну програму Techstars зі своїм попереднім продуктом, а наприкінці місяця, коли настав час починати фандрейзинг, все закрилося на карантин. Тоді здавалося, що стартап «помре». Але далі ми помітили, що люди почали виїжджати з мегаполісів у менші міста. Люди шукали, де жити, але вторинний ринок завмер — ніхто не продавав своє житло. А от первинний ринок почувався краще, тож у жовтні 2020-го ми остаточно переорієнтувалися на пошук та придбання новозбудованого житла. Зараз, під час світової рецесії, ринок нерухомості також почувається не найкраще. Втім, забудовники все ще хочуть здавати свої будинки, тож багато з них пропонують знижки та вигідні умови для покупки. Ми побачили, що про ці умови мало хто знає — вони губляться десь у різних імейлах та повідомленнях. Тож ми додали нову фічу — почали збирати акції та знижки на одній платформі, щоби юзери могли легко ними користуватися. У школі та університеті мені подобалися більшість предметів. Я завжди була людиною, яка цікавиться багатьма сферами, тож специфічної доменної експертизи у мене немає. Через це я завжди трохи заздрила людям, що мають конкретне покликання. Однак для фаундера набагато важливіші допитливість та внутрішня мотивація діяти. Тому навіть коли потрібно виконати марудне завдання, наприклад, заповнити даними таблицю в Excel, я можу себе змотивувати та отримати задоволення від процесу або результату. Нині, завдяки інтернету, ми маємо купу ресурсів, аби опанувати необхідні навички онлайн, а те, чого не вийде навчитися швидко (наприклад, юриспруденція чи бухгалтерія), можна віддати на аутсорс. Крім того, фаундери завжди набагато швидше ростуть, аніж окремі люди в команді. Вони роблять суттєві стрибки у різних доменах, вчаться нових підходів, аби краще розуміти бізнес та сферу. Зараз ми плануємо завантаження проєктами, там немає розподілення на домени. Також допомагають налаштовані процеси та комунікація в команді. У нас багато сінків: є загальний з хедами усіх напрямів та окремі з кожним з хедів напрямів. Завдяки цьому я знаю, що відбувається у кожному напрямі, тож за потреби можу втрутитися й розібратися. Робочий день фаундера справді важко назвати нормованим, а на вихідних не завжди вдається повноцінно відпочити. Ба більше, цього літа я вперше за п’ять років взяла справжню відпустку й не займалася роботою в жоден з 10 днів. Але є нюанс: мені подобається працювати. Для мене це не тягар, а улюблена справа, якою я займаюся з задоволенням. Я взагалі не дуже вірю, що фаундер може чітко розмежовувати роботу та особисте життя, особливо у перші п’ять років життя його стартапу. Я намагаюся активно проводити вихідні, бо знаю: якщо залишуся вдома, то буду працювати. Відпочити та перезавантажитися мені допомагають заняття різними видами спорту, зокрема йога, зустрічі з друзями, музика, хобі (нещодавно я проходила курс акторської майстерності) тощо. Подібні прості речі дуже гарно збалансовують. Звісно, іноді мене накриває втома та апатія, але зазвичай ці періоди не тривають більше кількох днів. Корпоративна культура завжди починається з фаундерів. Якщо ж засновник не діє відповідно до цінностей, правил та норм, які транслює, підтримувати корпоративну культуру не вийде. Наприклад, не можна вимагати швидкої комунікації, якщо ви самі з’являєтеся у месенджерах не часто. Особисто я намагаюся відповідати якомога оперативніше й очікую, що так чинитимуть й інші. У стартапів немає змоги довго та ретельно перевіряти кожного кандидата. Коли горить вакансія — ви швидко берете людину, пробуєте з нею працювати, а якщо вона не підходить, то швидко звільняєте. З нашого досвіду, такий підхід покращує культуру й розуміння рівня, який очікують від працівників. Коли стартап масштабувався, транслювати культуру має не лише фаундер, а інші ключові особи, як-от топменеджери чи ліди напрямів. Тому ключові позиції варто закривати ретельніше й шукати тих, хто отримує задоволення від вашого темпу роботи. Розпізнати чи відповідає людина корпкультурі буває дуже важко. Я досі цього вчуся. Ставлю відповідні питання, прошу навести приклади з власного досвіду, наприклад, розповісти, про кейси невдач у проєктах, куди людина була залучена. З українцями в цьому плані простіше, а от американці (ми наймаємо і за кордоном також) дуже добре вміють себе продавати, тож з’ясувати, наскільки людина впишеться у стартап буває справді важко.

Остання підбірка актуальних вакансій у 2023 році — для технічних спеціалістів різних ґрейдів і спеціальностей. Відкриті позиції для сеньорів у Holy Water та Genesis Accelerator, для мідлів — у PlantIn та Solidgate. Обирайте те, що вам підходить найбільше та не зволікайте подавати резюме у році, що закінчується. Middle iOS Developer До команди діджитал паблішера книжок Holy Water шукають iOS-розробника, який долучиться до створення нових застосунків та покращення поточних продуктів компанії. Нині додатками від Holy Water користуються вже 10 млн юзерів у всьому світі. Гра з історіями My Fantasy очолила список застосунків, які найчастіше завантажували у 2022 році в США. А книжковий застосунок Passion нині показує ріст х2 квартал до кварталу. Від майбутнього члена iOS-команди очікують досвіду роботи зі Swift від 3 років, чіткого розуміння архітектурних рішень MVVM, MVP, MVC, Clean architecture. Окрім цього, потрібно вміти створювати нативний якісний UI, використовуючи UIKit та/або SwiftUI, а також вміти спроєктувати архітектуру, яка легко підтримується, масштабується, відповідає всім вимогам бізнесу. Senior React Native Developer Holy Water також відкрила вакансію сеньорного розробника React Native. Він будуватиме архітектуру для всіх продуктів компанії, оптимізувати поточні проєкти з боку швидкості завантаження і розміру та покращувати процеси у команді React Native. Що потрібно аби отримати офер? Мати досвід розробки додатків на React Native з використанням TypeScript від 4-х років, досвід створення проєктів з нуля на React Native та ведення їх як головний розробник до завершення, досвід використання маркетингових SDK, таких як appsflyer/firebase/amplitude та інших. Вітаються бажання працювати в продуктовому стартапі та вміння швидко адаптуватися. Middle Full-Stack Developer Якщо ви досвідчений фронтендер або фулстек-розробник, то маєте шанс приєднатися до нового напрямку R&D PlantIn, стартапу, що створює застосунок для розпізнавання рослин на основі ШІ. Продукт має вже понад 20 млн користувачів та перше місце в категорії «Education» в США на платформах Apple та Android. Серед задач нового співробітника анонсують підтримку та оновлення сайту myplantin.com, оновлення внутрішніх платформ Expert Help platform та Content management platform, розробку нових платформ для управління контентом/датасетами/вебсайтами, пов’язаними із додатком PlantIn. Що очікують? 2+ роки комерційного досвіду в якості front-end розробника, досвід роботи з React.js та високий рівень самостійності у виконанні завдань. Досвід роботи з Node.js та Strapi буде перевагою. Senior Back-end Engineer Genesis Accelerator — команда всередині екосистеми, що працює із перспективними цифровими продуктами, в які інвестує Genesis. Щорічно фахівці акселератора тестують 100+ продуктів у пошуках тих,  хто має потенціал дизраптити ринок. Нині команда в пошуці досвідченого бекендера, який допомагатиме бізнесам розвиватися і зростати. Серед його задач будуть такі: підтримка і подальший розвиток чинної системи рішень для автоматизації процесів в маркетинговій команді, проєктування та розробка нових рішень для автоматизації процесів в маркетинговій команді, дослідження ринку для формування і впровадження візії розвитку відділу автоматизацій в Genesis Accelerator. Від кандидата очікують від трьох років комерційного досвіду, глибокі знання JavaScript і TypeScript (Node.js, Nest.js), практичний досвід роботи з інфраструктурою AWS (AWS Lambda), сильні навички в роботі з реляційними базами даних (PostgreSQL, Prisma), чітке розуміння процесів CI/CD і систем контролю версій (GitHub) та базове розуміння принципів SOLID. Вакансія компанії-партнера Golang Engineer Solidgate — партнерська компанія Genesis, що створює B2B-продукт у ніші онлайн-платежів, шукає Golang-розробника із мінімум 2 роками комерційного досвіду. Він братиме участь у розробці Web-рішень (Payment Page, Payment Form, SDKs etc), займатись постійним покращенням архітектури коду та сервісів, підходів до розробки, архітектурно працювати над проблемами з ідемпотентними запитами, покривати власний код юніт-тестами й метриками та проводити код-рев’ю. Аби обійняти цю посаду, кандидат має розуміти принципів побудови високонавантажених систем, знати Docker, AMQP (бажано RabbitMQ), мати досвід роботи з PostgreSQL, ElasticSearch та розуміти мікросервісну архітектуру.

Цьогоріч платформа для вивчення іноземних мов Promova часто потрапляла у новинні стрічки: спочатку компанія зробила ребрендинг, потім запустила режим для людей з дислексією, а нещодавно стала учасником національної програми Future Perfect. Наразі застосунок завантажили 12 мільйонів користувачів. За цими здобутками стоїть команда зі 120 людей, яку очолює Андрій Скрипник. Спеціально для блогу Genesis він розповів про свій професійний шлях, історію трансформацій Promova, гучні партнерства та підходи до управління командою. Робота замість навчання До сьомого класу в мене були двійки з інформатики. Всі практичні завдання ми прописували в зошиті, до комп’ютерів нас особливо не підпускали. Втім, виходячи з класу одного дня, я побачив, як на екрані компа одного хлопця розлітаються різнокольорові кубики. Виявилося, що це 3D-графіка. Я захотів навчитися робити щось подібне. Згодом мені стало цікаво не просто моделювати 3D-фігури, а створювати інструменти для цього. Тоді я почав занурюватися в програмування. У старших класах ми з родиною переїхали з Херсона до Києва. Програма нової школи була слабшою від тієї, за якою я навчався раніше. Мені швидко стало нудно, тож я почав працювати розробником на фрилансі. Після школи вступив до КПІ на ФІОТ (Факультет інформатики та обчислювальної техніки). І якщо в школі вчителі без проблем закривали усі предмети, то в університеті так не вийшло. З першого курсу мене відрахували. Наступного року я заново здав ЗНО поновив навчання, намагаючись при цьому грамотно поєднувати його з роботою. Я впевнений, що важливість вищої освіти — це не міф. По-перше, вона дає більш ґрунтовний погляд на професію, інженерні та алгоритмічні знання, без яких важко досягти ґрейду сеньйора. Навряд чи кількамісячних курсів достатньо, щоби, наприклад, навчитися створювати продукт з нуля. По-друге, освіта відкриває двері для роботи в міжнародних компаніях — магістерський диплом стає своєрідною проєкцією набутих знань. По-третє, у вас є змога розшити коло своїх зв’язків, познайомитися з новими людьми та навчитися ефективно взаємодіяти з ними. Від стажера до СТО Свій професійний шлях я починав із фрилансу. Ще у школі брав невеликі замовлення на UpWork — не стільки заради грошей, скільки для досвіду. Далі були Cyber Sport Arena та StarLadder TV — один з найбільших кіберспортивних операторів у регіоні. Пізніше я зрозумів, що хочу робити свої продукти, тож разом з командою ми розробляли інді-ігри. Щоб фінансувати проєкт, ми робили сайти на замовлення. Влітку після третього курсу мені потрібно було проходити практику. Університет вимагав документи з робочого місця, а показувати фрилансерські чи аутсорсні проєкти бажання не було. Натомість я прагнув одержати справді «офісний» досвід для практики. Тоді я нагуглив один розробницький форум і знайшов там повідомлення трирічної давнини. Його автор якраз пропонував практику студентам третіх-четвертих курсів. Я написав йому, і, на диво, отримав відповідь. З цього почалося моє стажування в Concepter, а автором повідомлення виявився Іван Чуба, CTO цього стартапу. Ключовим продуктом компанії на той момент був iBlazr — портативний світлодіодний спалах для смартфона. Під час стажування я за два тижні розробив апку для цього пристою під Windows Phone з нуля, хоча раніше не працював з цією операційною системою. Втім, я уже багато чого вмів — проєктувати фронтенд і бекенд, програмувати під iOS і трохи під Android. Технологічний стек, яким я володів, містив мови програмування Objective-C, С#, C++, C, Java, Java Script, PHP, а також уже не актуальні на зараз Delphi, Pascal та скриптові мови на кшталт Lua. Всім сподобалося, як я працював, тож мені запропонували приєднатися до Concepter на фултайм. Я став відповідати за всю софтверну частину (окрім Android), і досить довго залишався єдиним розробником у компанії. Згодом ми почали розробку першого софтверного продукту — це був тайм-трекер. Для нього найняли нових людей, а я став їхнім тимлідом. Пізніше технічна команда збільшилася до 10 людей — і я органічно став СТО. По суті, у нас було два СТО: я керував розробниками, що створювали софт, а Сергій Щербаков очолював команду, яка займалася хардвером. Три назви одного застосунку У 2015 році я познайомився з Михайлом Галяном, CEO компанії Boosters. Згодом ми зустрілися ще раз — уже в 2019 році, коли я приєднався до Genesis розвивати застосунок для покращення іноземних мов. Тоді ми назвали його Ten Words, він складався з чотирьох екранів. Користувачу пропонували вивчати по 10 нових слів щодня за допомогою різноманітних квізів. Попри непоганий бекграунд, я не можу сказати, що досконало розумівся на всіх бізнес-доменах. Спершу я заповнював прогалини у знаннях — вивчав аналітику, маркетинг тощо. З останнім дуже допомагали Михайло Галян та Валерія Вакульська: у них була відповідна експертність, тож ми багато консультувалися. Поступово у продукт додавали більше фічей, онлайн-уроки, елементи гейміфікації. Проєкт уже виходив за межі десятьох слів, тож отримав нову назву — Words Booster. Ще за кілька років ми почали перехід від застосунку до повноцінної платформи, тож знову зробили ребрендинг. Навіть якщо у вас невеликий продукт, не варто думати, що ви впораєтеся з ребрендингом швидко. Вважати, що він передбачає лише зміну назви та редизайн — безвідповідально. Це завдання набагато ширше й складніше, а рішення лежить у площині комунікації, тестів, дизайну, функціональності тощо. Ми не врахували цього на старті, тож ребрендинг Promova тривав рік. Втім, все було недарма — бренд добре впливає на конверсії та перформанс продукту. Завдяки ребрендингу ми покращили продуктові та фінансові метрики, побудувати маркетинг 360, запустили всередині команди CRM та Growth. Promova для кожного Близько 20% людей у світі мають дислексію. Режим для таких користувачів у Promova покликаний полегшити процес опанування нових мов. Варто зазначити, що цей проєкт — приклад реалізації внутрішньокомандної ініціативи. Ідея належить нашій Head of Brand & Global Communications Альоні Козуб. Важливо, що вона не лише запропонувала ідею, а й взяла відповідальність за її реалізацію. Promova стала першим застосунком для вивчення мов, який адаптував свій контент під потреби людей з дислексією. У застосунку використовується Dysfont — спеціалізований шрифт, який дає змогу полегшити сприйняття тексту. На жаль, єдиного рішення, яке розв’язувало б усі проблеми, немає. Це пов’язано з тим, що кожна людина з дислексією має індивідуальні труднощі. У когось текст «пливе», у когось «стрибає», комусь складно розпізнавати великі та маленькі літери, а хтось плутає p, q, b і d. Однак дизайнер шрифту Мартін Писний, з яким ми співпрацювали, врахував найпоширеніші проблеми. Йому діагностували дислексію у віці семи років, тож він розуміє всі особливості сприйняття тексту. До того ж до початку співпраці шрифт ще проходив етап бета-тестування й мав схвальні відгуки користувачів. Зараз Dyslexia Mode використовують тисячі юзерів, фідбек досить позитивний. У майбутньому ми плануємо адаптувати Promova і для користувачів з вадами зору, адже навчальні продукти мають бути доступні широкому загалу. Англійська для українців Цьогоріч Promova відкрила для українців безкоштовний преміумдоступ на три роки у межах національної програми популяризації англійської мови Future Perfect, яку створили за ініціативи Президента України. Коли ми остаточно узгодили всі деталі щодо реалізації проєкту, моєю першою думкою було: «Ого, скільки роботи!» Втім, не можу сказати, що мав додатково заохочувати команду. Усвідомлення того, наскільки важливий для країни проєкт ми робимо, мотивувало краще за будь-що. Ми планували роботу у зворотному напрямку. Уявили, що виходить новина — «Promova доступна всім українцям». Що це має означати? Треба розповісти про платформу, як вона працює, та як отримати безкоштовний доступ — тому потрібен спеціальний лендинг під цей проєкт. Далі ми продумали механізм активації преміуму. Як зрозуміти, що ті, хто звертаються за безкоштовним доступом — саме українці? Значить, маємо інтегруватися з «Дією» та написати код, який надає доступ саме через «Дія.Підпис». Дані ми не збираємо — одержуємо лише підтвердження громадянства. Серед інших завдань — змінити комунікацію на платформі, додати згадки Future Perfect, протестувати навантаження на сервери. Наразі (за місяць після старту) проєктом зацікавилися 174 000 українців. Premium-доступ через «Дія.Підпис» одержали понад 60 000 осіб, причому 24% заявок надійшло з-за кордону. Ретеншн користувачів програми у 2,5 раза вищий, ніж у інших регіонах. Всередині компанії З 2019 року структура команди Promova змінювалася тричі. Спочатку у нас була пласка структура, коли всі підпорядковувалися безпосередньо мені. ​​З часом, коли над продуктом працювало уже понад 20 осіб, з’явилися три великі напрями — веб, app та маркетинг. Під час подальшого масштабування функції та ролі почали дублюватися. У вебі та застосунку одна і та ж фіча могла бути реалізована по-різному. Тому згодом ми переглянули структуру. App та web об’єднали, а команду маркетингу перебалансували. Наразі маємо продуктову та маркетингову команди з кросфункціональними відділами всередині. Наймати людей нам допомагає загальна система відбору Genesis з п’ятьма обов’язковими етапами, зокрема, баррейзингом. На співбесідах я перевіряю софт- та хард-скіли, фідбеки та відповідність культурі. Ми намагаємося балансувати відповідність та різноманітність у корпкультурі, адже, якщо всі мають однаковий бекграунд й схоже мислять, то ви не зможете знайти нові шляхи розвитку продукту, а якщо кардинально по-різному — конфліктні ситуації будуть траплятися занадто часто. Також важливо, щоб людина не була токсичною та вміла працювати у команді. Для цього я ставлю кілька питань-зачіпок і спостерігаю, як людина розповідає про успіх і про невдачі. Якщо про успіх вона говорить через «я», а про невдачі через «ми», це поганий знак. Якщо трапляються невдачі, ми діємо за відпрацьованим алгоритмом. Спочатку треба зробити все можливе, аби негативний вплив від помилки не розповсюджувався. Далі йде етап виправлення. Третій та четвертий крок — запровадити процеси чи дії, аби ситуація не повторилася в короткостроковій чи довгостроковій перспективі. І лише останнім етапом ми розбираємося, хто відповідальний за факап, і що він зробив не так. Якщо помилок припустився я сам — завжди відверто звертаюся до команди із вибаченнями й прошу допомоги. Специфіка позиції СЕО така, що факап має значний вплив, і без команди виправити ситуацію не вийде. Візія Promova — стати компанією-лідером на ринку вивчення іноземних мов за якістю продукту і за доходом. Для нас рівноцінно важливі обидва складники. Якщо говорити суто про продукт, то ми прагнемо до першості як найкраща платформа з персоналізованими інструментами та методологією навчання, яка допомогла мільйонам користувачів вивчити іноземні мови. Наразі в застосунку 10 мов, а у світі їх понад 200, тому тут також є куди рости та розвиватися.

У мультимодульній архітектурі кожен модуль може відповідати за окрему функцію, набір функцій чи компонент. Відповідно, кожна модульна команда має власний набір обов’язків, структуру та планування. Завдяки цьому розробникам у великих проєктах простіше підтримувати та оновлювати кодову базу, а продукти можна легко та швидко масштабувати. Досвідом створення мультимодульної архітектури у великому проєкті ділиться Олександр Рябцев, Senior Mobile Engineer у Wix. Під час DOU Mobile Meetup, що відбувся у вересні, він розповів, чому вирішили будувати таку систему, як організували роботу розробників та побудували процеси. > Архітектура мультимодульного застосунку > Реалізація Business Modules > Як модулі працюють з Engine > Як модулі комунікують між собою > Як все збирається у One App > Які результати одержали Архітектура мультимодульного застосунку Мультимодульну архітектуру обрали, аби реалізувати Wix One App Mobile. Це інтерпретація всього продукту Wix в мобільному застосунку. Відповідно, створити сайт, наповнити його контентом, побачити аналітику можна просто в смартфоні. Розробка подібного застосунку вимагає ретельного підходу до архітектури. Ось декілька причин, чому ми зупинилися саме на мультимодульній. Окремі модулі — окремі команди. Кожна команда самостійно планує робочий графік, ухвалює рішення щодо моделі роботи, обирає графік релізів тощо. Незалежні й швидкі релізи. Команди працюють автономно, не можуть блокувати процеси одна одній, і, відповідно, швидше релізять продукт або фічу. Легке масштабування. Мультимодульна архітектура дає змогу декільком командам працювати над одним додатком одночасно. Масштаб в 4-5 команд можна виростити до 40-50 команд. Підхід дає змогу перетворити продукт на мега-апку на кшталт Telegram чи Facebook, де основні фічі проєктують «внутрішні» розробники, а «зовнішні» мають змогу робити кастомні. Архітектуру спроєктували на базі фреймворку React Native. Найголовніше в ній — це декілька леєрів. Нижній, Native SDK — це, по суті, мобільний пристрій на iOS або Android. Верхній — це бізнес-логіка, яка написана на JavaScript + React. Обидва леєри об’єднує React Native — «обгортка» з нативними view та бібліотеками. Подібних «обгорток» може бути багато. Наприклад, робота з камерою, запис відео чи фото, робота з Key Storage чи нотифікаціями. Ще одна перевага React Native — JS-бібліотеки, які дають змогу використати усе різноманіття вебінструментів. Розглянемо нижче схему — Wix-інтерпретацію React Native. У верхній частині є два рівні: бізнес-логіка, фічі та sharing code. Як бачимо з назви, sharing code є спільним для бізнес-модулів і допомагає створювати фічі в єдиному стилі й з єдиною інфраструктурою. Над продуктом працюють два типи девелоперів. Одні займаються бізнес-фічами, а другі, infra-девелопери — платформами та інструментами для розробки. Якщо об’єднати все, окрім бізнес-логіки, одержимо єдину платформу, яка називається Engine. За неї й відповідають infra-девелопери. Загалом, завдання Infra-команди полягає у тому, щоб забезпечити: незалежну розробку. Розробники одного модуля не мають залежати від розробників іншого. Натомість вони фокусуються на своїх фічах та незалежно обирають стиль програмування, формат тестування тощо. незалежні релізи. Infra-команда має зробити так, щоб кожна модульна команда комфортно розробила фічу та «донесла» її до релізу. операційну систему для бізнес-модулей. Тут буде доречно порівняти наш Engine з операційними системами iOS або Android. Це, по суті, версія платформи зі своїм SDK, яким користуються модулі. Реалізація Business Modules Кожен з них має такі характеристики: маленький застосунок всередині One App; повністю самостійна та незалежна логіка; тільки JS, жодного нативного коду; можуть комунікувати між собою; реалізують інтерфейс Module. Ось, наприклад, декілька наших модулів. Всього їх понад сотню. mobile-apps-restaurants mobile-apps-groups mobile-apps-stores mobile-apps-auth mobile-apps-notifications Усі модулі поділяються на два типи. Перші спрямовані на конкретний бізнес. Наприклад, модулі для ресторанів передбачають фічі, пов’язані з меню, бронюванням столиків, онлайн-замовленнями тощо. Інша група модулів — авторизація, сповіщення тощо — розроблена загалом для всього застосунку. Нижче наведено приклад класу, який імплементує інтерфейс Module. Всі методи опціональні, тобто модуль не обов’язково буде їх реалізувати. Наприклад, в цьому класі модуль може описати, які методи або компоненти він надає для використання іншим модулям або платформі. export default class TableReservationsOwner implements Module { components() { return [{ id: ScreenId.ReservationDetailsScreen, name: 'Reservation Details', description: 'Screen to fill contact details', }]; } methods(): MethodDefinition[] { return []; } consumedServices(): ConsumedServicesDefinition { return { ownerShortcuts: () => ([ { id: ShortcutId.ReservationsShortcut, label: 'Table Reservations', iconAssetPath: 'icons.general.reservations', screenId: ScreenId.MainReservationsAdapterScreen, }, ]), }; } deepLinks(): DeepLinkDefinition[] { return []; } data(): DataDefinition { return {}; } } А ось приклад нашого package.json, а також dependencies, які використовує один модуль. Є два типи — dependencies та devDependencies. Перші — це бібліотеки, необхідні для цього модулю. У нашому прикладі це Redux та Formik. Під devDependencies маються на увазі dependencies на сусідні модулі, до яких дотичний один конкретний. Йдеться про authorization-модулі, notifications, engine, а також UI-бібліотеки. { "name": "mobile-apps-table-reservations", "dependencies": { "formik": "^2.0.0", "@reduxjs/toolkit": "^1.0.0", ... }, "devDependencies": { "mobile-apps-stores": "^1.0.0", "mobile-apps-owners-platform": "^2.0.0", "mobile-apps-auth": "^1.0.0", "mobile-apps-notifications": "^1.0.0", "mobile-apps-ui-lib": "^7.0.0", "mobile-apps-engine": "^30.0.0" ... }, } Як модулі працюють з Engine Окремі бізнес-вертикалі, наприклад, Wix Groups, Wix Stores, Wix Blogs, можуть комунікувати між собою, але не напряму, а через Engine, який захищає їх від різноманітних помилок. Якщо модулі незалежні, їх можна «замокати» та ефективно протестувати свій модуль. Також є змога дуже швидко збілдити локально свою вертикаль, не підвантажуючи інші 100+ модулей. Подібна схема дозволяє застосувати lazy loading і, відповідно, не вантажити весь бандл одночасно, а почати з найнеобхіднішого. Тоді Engine підвантажує додатковий JS-бандл в оперативну пам'ять уже після того, як юзер авторизувався та обирає, на який екран перейти далі. Це суттєво пришвидшує застосунок. Без застосування lazy loading завантаження всього JS-бандлу на старті займатиме багато часу, адже React Native доволі важкий. Також варто звернути увагу на бінарники. Їх модуль може отримати разом з Engine. Згадаємо про аналогію з операційною системою: Engine має свою версію. Коли вона створюється, бінарники компілюються й складаються окремо. Це гарантує, що кожний модуль при розробці буде використовувати одну й ту саму версію Engine, що й інші модулі, що суттєво покращує стабільність застосунку. Одночасно з завантаженням Engine «під капотом» скачуються й бінарники. Далі розробник запускає бінарник у симуляторі, накатує свій JS-модуль — і може починати роботу. Бінарник створюється і тестується один раз, і це гарантує, що всі модулі використовують один той самий файл. Підхід пришвидшує розробку, покращує безпеку й робить проєкт стабільнішим. Engine з точки зору файлової системи схожий на звичайний React Native-проєкт. Найголовніший файл у проєкті — package.json. { "name": "wix-one-app-engine", "main": "./main.js", "dependencies": { "react": "18.2.0", "react-native": "0.71.12", "typescript": "4.9.5", "react-native-navigation": "7.37.1", "react-native-webview": "11.26.1", "@react-native-community/netinfo": "^7.1.12", "lodash": "^4.17.21", "react-native-mmkv": "2.7.0", "remx": "^3.0.611" }, "androidDependencies": { "androidSdkVersion": 33, "androidMinSdkVersion": 24, "flipper": "0.191.0" } } Як бачимо, Engine містить усі ключові інструменти, що за замовчуванням необхідні для розробки на React Native, такі як React, React Native, TypeScript тощо. Також він містить бібліотеку навігації, яка необхідна кожному модулю, або WebView або Lodash. Модуль може використовувати ці інструменти або ж свої — архітектура це дозволяє. Модуль додає новий інструмент у свої dependencies — й тоді Engine додасть його до загального бандлу. Як модулі комунікують між собою Комунікація відбувається через Engine у три способи. Component. В класі module.js, який імплементує інтерфейс Module, модуль A описує, що він буде доставляти в engine компонент типу BlogPost. Модуль B, своєю чергою, бере цей компонент з engine через Module Registry і перевикористовує його у своєму коді. // Expose components module.ts components() { return [{ id: 'blog.components.BlogPost', generator: () => require('./screens/BlogPost').default, }]; } // Use components const BlogPostComponent = engine.moduleRegistry .component('blog.components.BlogPost'); return ( ); Broadcast (event). Тут так само. Модуль A оголошує, що буде робити broadcast в певному каналі, а модуль B підписується на цей broadcast у своєму коді. Коли у модулі А щось трапляється, він надсилає broadcast, який буде опрацьовувати модуль B. Все йде через engine, не напряму. // Register broadcast from module.ts registerBroadcasts(register) { broadcasts.addBroadcast( 'core.newNotification', register('core.newNotification', 'new notification'), ); } // send broadcast event broadcasts.sendBroadcast({ notification }); // register to event engine.moduleRegistry.addListener( 'wix.core.newNotification', ({ notification }) => { // notification received }), ); Invoke (method). Модуль A описує в module.js метод, який він робить публічним, і який можна викликати іншим модулям. Далі модуль B може викликати цей метод через engine, передати певні props і одержати результат. // Expose method from module.ts methods(): MethodDefinition[] { return [{ id: 'media.uploadMedia', generator: () => require('./methods/uploadMedia').default, }]; } // invoke method from other module through Engine const result = await engine.moduleRegistry.invoke('media.uploadMedia', { uploadId: media.uploadId, }); // ModuleTyped way const result = await engine.modules.media.methods.uploadMedia({ uploadId: media.uploadId, }); Як все збирається у One App Нагадаю, що це мобільна інтерпретація всього Wix. Відповідно до схеми нижче, One App — це конфіг-файл, який дає інструкції engine, що потрібно взяти певні модулі, версії й скласти усе до купи. Ось приклад package.json файлу для OneApp, де є, наприклад, platformModule. Так, у нас платформа — це також модуль, але дещо особливий, бо його найперше бачить користувач. Саме звідти юзер обирає, яким модулем користуватися далі. { "dependencies": { "mobile-apps-engine": "30.0.0", "mobile-apps-owners-platform": "1.0.0", "mobile-apps-blog": "1.0.0", "mobile-apps-groups": "2.0.0", }, "oneAppEngine": { "ownerApp": { "platformModule": "mobile-apps-owners-platform", "modules": [ "mobile-apps-owners-platform", "mobile-apps-blog", "mobile-apps-groups", "mobile-apps-engine" ], "tabs": [ "dashboard", "inbox", "manage" ], "quickActions": [ Як результати одержали Найперше — це можливість працювати декільком командам паралельно і незалежно. Крім того, мультимодульна архітектура дає можливість створювати окремі платформи для різних завдань. У нашому випадку маємо окремі апки для власників сайтів, для агенцій, для юзерів власників сайтів на Wix тощо. Ще один суттєвий результат використання подібної архітектури — можливість, за аналогією зі створенням вебсайту, створювати власні застосунки, або Branded App. Такий забрендований застосунок, що складається з модулів, які обрав власник сайту, можна завантажити в App Store або Google Play Market.

Scrum — найпопулярніший Agile-фреймворк для розробників. Згідно з дослідженням, ним користуються близько 84% організацій у світі. Чи підходить він усім бізнесам? Scrum справді прискорює розробку або ж численні церемонії та додаткові ролі ускладнюють життя інженерів? Ця методологія працює лише цілісно чи може бути адаптована до вимог продуктових команд? Чи можна оцінювати його ефективність за кількістю релізів? Сергій Матчук, Product Lead команди Kismia в Quarks, партнерській компанії Genesis, спростував найпоширеніші міфи про Scrum та поділився, як адаптувати цей фреймворк до цілей продуктової команди. > Scrum — цілісний фреймворк, який не працює при неповній імплементації всіх складових > Впровадження Scrum потребує збільшити кількість менеджерів > Scrum передбачає забагато церемоній, які забирають більше часу ніж сама розробка > Система оцінки завдань у Scrum створена для посилення контролю над розробниками > Реліз — останній етап та спосіб вимірювання ефективності у Scrum > Scrum підходить усім командам МІФ №1 Scrum — цілісний фреймворк, який не працює при неповній імплементації всіх складових Методологія Scrum першочергово націлена на організацію процесу розробки проєкту. Цей фреймворк дає команді можливість ефективно і планово релізити зміни у продакшн, і робити це швидко, але він не забезпечує позитивного впливу на продукт. Для ефективних результатів він має бути адаптований до цілей і специфіки бізнесу. Складовими класичного Scrum є кросфункціональні команди, відповідні ролі, церемонії, артефакти та правила. Його автори наголошують, що усі компоненти методу не підлягають змінам та працюють лише цілісно. Тож як його тоді адаптувати? Як це працює в Quarks Quarks створює продукти та технології у сфері social discovery, серед яких флагманом є Kismia, міжнародна платформа для онлайн-знайомств. Щоби ефективно розвивати цей комплексний кросплатформенний продукт, команда Kismia експериментувала з інструментами та обрала окремі практики з базових складових фреймворку Scrum: Створили три кросфункціональні команди, які відповідають за окремі платформи (iOS, Android та Web), є автономними та самостійними. До кожної команди входить два розробники та QA. Також у сервісному форматі з командою працює бекенд-інженер який закриває потреби всіх команд. У команді немає ролі продакт-овнера, але є роль продакт-менеджера який відповідає за розвиток платформи та взаємодію з командою інженерів і продуктовими спеціалістами, такими як дизайнер, продакт-аналітик. Окрім цього в Quarks є інші продуктові та технічні команди, з якими регулярно взаємодіє команда Kismia. Застосували спринти — короткі ітерації тривалістю два тижні, протягом яких створюється готовий до релізу інкремент продукту. У кожної команди свій релізний цикл і процес. Як його організовувати визначає сама команда. Організували єдиний продуктовий роудмап. У кожної кросфункціональної команди є свій беклог з точки зору платформи. В межах спринту ним керує сама команда розробки, беручи до уваги пріоритети від продуктового менеджера та продуктовий роудмап. Визначили зрозумілу ціль — завдання, на якому команда фокусується протягом спринту. Альтернатива цілі спринту — запуск експериментів, про які домовляється команда розробки та продуктовий менеджер. Водночас усі команди мають один контекст, бачення та єдиний вектор розвитку. Попри те, що команда Kismia імплементувала не цілісний фреймворк «з коробки», а його окремі складові, такий підхід забезпечує ефективну роботу команди, системний цикл релізів та запуск експериментів на трьох платформах. МІФ №2 Впровадження Scrum потребує збільшити кількість менеджерів Канонічний Scrum передбачає, що до кросфункціональної команди обовʼязково має входити продакт-оунер та скрам-майстер. Продакт-оунер відповідає за пріоритезацію завдань, які треба виконати протягом спринту, а також за цінність продукту, комунікацію зі стейкхолдерами, збір вимог та донесення до команди бачення кінцевого продукту. Скрам-майстер слідкує за дотриманням практик та правил методології. Як це працює в Quarks Найважливіша концепція Scrum — ідея автономних та самоорганізованих команд. Фактично усі додаткові ролі, церемонії та артефакти створені саме для того, щоби зробити їх більш самостійними. Водночас команда розробки у продуктових компаніях зазвичай добре розуміє цілі та бізнес-контекст. Досвідчений спеціаліст може самостійно організувати процес розробки та взаємодію з QA чи іншими інженерами. Він добре розуміє бізнес-контекст, ціль та ролі в команді, тому йому не потрібен посередник, який водитиме його «за руку» та вирішуватиме усі питання. Залучаючи до команди таких сильних людей, Quarks змогли відмовитися від зайвих ролей — продакт-овнера та скрам-майстра. У такому підході значно складніше наймати, адже до кандидата висувається більше вимог — комунікаційні навички, продуктове мислення тощо. Проте це працює ефективніше. Зокрема, можна уникати «менеджерських трикутників». Коли в одного інженера виникає питання до іншої команди, він не іде до свого менеджера, щоби той звернувся до іншого менеджера, а спрямовує свої питання одразу на колегу з технічної команди. Це більше розвиває спеціалістів, дає їм свободу та автономність. Команда розробки максимально залучена до продуктового процесу, розуміє цілі, пріоритети, обмеження та залежності. Отримуючи всі відповіді на етапі планування та при формуванні продуктових вимог, вони самостійно планують скоуп спринту, запускають його, і рухаються протягом двох тижнів. Продуктовий менеджер керує беклогом і пріоритетами. Він відповідає за продуктову частину продукту, а саме за експерименти, що мають позитивний вплив на продукт, його цінність для користувача та бізнесу. МІФ №3 Scrum передбачає забагато церемоній, які забирають більше часу ніж сама розробка Зазвичай до церемоній Scrum входять: рефайнмент, планування спринту, дейлі-стендапи, спринт-ревʼю та ретроспектива. Рефайнмент. Зустріч, на якій учасники опрацьовують беклог продукту та розбирають завдання. Планування. Відбувається на початку кожного спринту для визначення цілі та завдань, які команда має виконати протягом наступного періоду. Дейлі-стендапи. Щоденні короткі зустрічі, що відбуваються протягом спринту. Кожен член команди розповідає про свій прогрес, завдання і будь-які проблеми, які заважають роботі. Спринт-ревʼю проводять у кінці кожного спринту. На ньому команда підбиває підсумки та презентує результати стейкхолдерам. Ретроспектива. Зустріч для аналізу минулого спринту, виявлення проблем та можливостей покращити процеси. Проходять у кінці спринту. Часто розробники скаржаться, що такі зустрічі проходять неефективно: обговорення можуть тривати годинами, що призводить до виснаження команди. Як це працює в Quarks Церемонії не мають відбуватися лише заради дотримання правил Scrum. Важливо берегти час команди, а не збирати усіх з будь-якої нагоди, щоби послухати менеджера. В Quarks усі зустрічі та церемонії мінімізовані за тривалістю та кількістю учасників. Наприклад, рефайнмент займає не 2 години, а 30-40 хвилин. Команди розробки щодня проводять дейлі-стендапи, вони проходять без менеджерів. Основна зустріч, з якої починається підготовка до спринту — рефайнмент. На ній розробники розбирають плани на наступний спринт чи ітерацію, і впевнюються, що до завдань немає питань. Окремої зустрічі з планування, на яку збирають всю команду, не проводять. Після рефайнменту відповідальні за платформи дивляться оцінки завдань, сформований скоуп, пріоритети менеджерів та запускають спринти. Ретроспективи проводять періодично, щоби виявити проблеми у процесах на стику взаємодії. Команда самостійно вирішує, коли провести таку зустріч та може її пропустити, якщо ні в кого немає зауважень щодо ефективності роботи чи результатів спринту. Щоби Scrum працював повноцінно, важливо мати хорошу технологічну базу — йдеться про CI/CD, пайплайни та внутрішні інструменти для підвищення ефективності та автоматизації. Якщо вони якісно налаштовані, частково зникає потреба у додаткових процесах, ролях та церемоніях. МІФ №4 Система оцінки завдань у Scrum створена для посилення контролю над розробниками Одна з практик Scrum — оцінка складності завдання під час планування спринту. Це допомагає команді розробників прогнозувати, скільки часу та ресурсів знадобиться для виконання конкретної роботи. Є чимало підходів, як оцінити завдання, один з яких — сторипоінти. Часто вони не виражені у конкретних годинах чи днях, а відображають відносну складність чи обсяг роботи порівняно з іншими завданнями. У деяких компаніях за кількістю виконаних сторипоінтів оцінюють загальну ефективність команди. Вважається, коли число запланованих та виконаних завдань відрізняється, це свідчить про неякісне планування або проблеми у процесах. Як це працює в Quarks Кількість сторипоінтів не має бути інструментом контролю чи звітності перед продуктовим менеджером або іншими стейкхолдерами. Це інструмент, який допомагає команді правильно запланувати навантаження та підтримувати динаміку розробки. Якщо виникають проблеми з ефективністю в команді чи окремих людей, за сторипоінтами можна шукати проблеми у процесах. Проте щойно команда розробки в Quarks вийшла на певний рівень ефективності, це стало їхнім внутрішнім інструментом. МІФ №5 Реліз — останній етап та спосіб вимірювання ефективності у Scrum Вимірювання результату спринту — те, чого продуктовій команді не вистачає у Scrum. Традиційно останнім етапом та фінальною точкою в спринті вважається реліз. Як це працює в Quarks Натомість у продуктовій розробці це тільки початок процесу, адже в результаті релізу нового функціоналу чи змін команда збирає нову інформацію, інсайти, робить висновки, а потім вирішує, чи має цінність той функціонал, який зробила. Експерименти та тестування гіпотез складають основу роботи продуктової команди. Водночас лише 30% ідей мають цінність для бізнесу і користувачів та залишаються в продукті назавжди. Тому командам точно не варто фокусуватися виключно на кількості та частоті релізів. Scrum допомагає системно випускати релізи, але він не впливає на те, скільки з них матимуть вплив на продукт та наскільки він буде успішним. В Quarks ефективність того чи іншого процесу у команді оцінюють за: динамікою релізу змін (Time to market); якістю продукту з точки зору наявності дефектів чи проблем; ефективністю змін та впливу на продукт; задоволеністю команди: наскільки їй комфортно працювати в такому процесі. МІФ №6 Scrum підходить усім командам Scrum — найпопулярніший Agile-фреймворк, проте насправді він підходить далеко не всім командам. Наприклад, деяким сервісним компаніям завдання від замовника можуть приходити частіше ніж раз на спринт. Також Scrum не підійде тим командам, де є залежності в процесах та потреба додаткової взаємодії або комунікації. Ці проблеми вирішуються такими фреймворками, як Safe чи lEss, але вони додають ще більше церемоній та додаткових ролей. Scrum не буде ефективним в забюрократизованих компаніях, де команда не зможе бути повністю автономною, а чекатиме на погодження від стейкхолдерів. Загалом, цей фреймворк може бути дієвим для багатьох проєктів, але важливо враховувати контекст та потреби. Якщо методологію неможливо адаптувати, варто розглянути інші підходи. Як це працює в Quarks Обираючи будь-який фреймворк, важливо, щоби не команда адаптувалася під нього, а навпаки: підібрати такі практики, з якими всім буде комфортно працювати та досягати цілей. Як і всі інші процеси, цю методологію треба регулярно переглядати та безперервно покращувати через зворотний фідбек команди. Ключове завдання менеджера — зібрати сильну команду, надати їй весь необхідний контекст й інструменти для роботи та допомогти стати автономною. Якщо це вдалося, можна далі експериментувати з методологіями та обирати ті практики, які допоможуть команді бути ефективнішою. Отже, варто памʼятати, що Scrum народився в 1990-х роках. Деякі з його концепцій просто неможливо імплементувати сьогодні. Наприклад, mobling programming — групове програмування, коли в команди є один монітор та одна клавіатура, які передаються по колу, а код пишеться колективно. Або ідея co-located-команд — коли усі мають сидіти за одним столом в одній кімнаті, щоби уникати зайвих листів та чатів та вирішувати усі питання одразу. Кожна команда має брати лише найкращі практики, які відповідають її поточним проблемам та цілям, та уникати сліпого впровадження церемоній та ролей заради дотримання правил.

Принципи SOLID та як їх застосувати — те, що питають розробників на більшості співбесід. Це набір правил, який в теорії дозволяє створити відмовостійкий масштабований та легкий у підтримці продукт, код якого буде репрезентативним. Водночас є низка сценаріїв, коли ці принципи не застосовуються та суперечать деяким шаблонам проєктування. Єгор Ілющенко, Back-end Engineer у Legit з екосистеми Genesis, поділився кейсами та прикладами, а також розповів про поширені помилки в інтерпретації цих правил. > Що таке SOLID > Навіщо потрібні принципи SOLID > Принцип єдиної відповідальності (SRP) > Принцип відкритості/закритості (OCP) > Принцип заміщення Лісков (LSP) > Принцип розділення інтерфейсу (ISP) > Принцип інверсії залежності (DIP) > Як засвоїти принципи SOLID Що таке SOLID Концепція SOLID була сформована Робертом Мартіном, вона допомагає забезпечити гнучкість, розширюваність та підтримку коду. Кожна літера у слові SOLID представляє один з цих принципів: S — принцип єдиної відповідальності (Single Responsibility Principle, SRP). Введений Робертом Мартіном у книзі «Agile Software Development: Principles, Patterns, and Practices» 2002 року. Мартін підкреслив важливість створення класів, які відповідають лише за один напрям дій. O — принцип відкритості/закритості (Open/Closed Principle, OCP). Вперше описаний Бертраном Меєром у книзі «Object-Oriented Software Construction» 1988 року. Він визначив, що класи повинні бути відкритими для розширення, але закритими для модифікації, щоби сприяти гнучкості та легкості розширення коду. L — принцип заміщення Лісков (Liskov Substitution Principle, LSP). Сформульований Барбарою Лісков 1988 року. Її робота «A Behavioral Notion of Subtyping» визначила умови, за якими один об'єкт може замінити інший без змін поведінки програми. I — принцип розділення інтерфейсу (Interface Segregation Principle, ISP). Введений Робертом Мартіном, він розширив ідеї використання малих та специфічних інтерфейсів для зменшення залежностей. D — принцип інверсії залежності (Dependency Inversion Principle, DIP). Сформульований Робертом Мартіном, визначає важливість того, щоби модулі низького рівня не залежали від верхніх модулів, а обидва типи залежали від абстракцій. Набір принципів SOLID визначив основи для створення легко зрозумілих, підтримуваних та розширюваних систем. Навіщо потрібні принципи SOLID SOLID розширює список базових принципів об'єктно-орієнтованого програмування. «Якщо ООП розповідає нам, що таке класи, і що вони можуть, то SOLID пояснює, яким чином краще їх поєднувати між собою, будувати та компонувати систему, — пояснює Єгор Ілющенко, Back-end Engineer Legit. — Фактично цей набір принципів допомагає інтегрувати принципи ООП, підштовхує розробників до використання абстракцій та правильної побудови залежностей в системі. Набагато простіше працювати з кодом, що підготовлений до розширення і перевикористання загалом, — таким чином нам достатньо фокусуватися на власному коді замість того, щоби розпиляти увагу на вивчення коду, що існує». Загалом SOLID націлений на якість коду. Він допомагає створювати код, який буде легко перевикористовувати, масштабувати та підтримувати. Гарним показником якості застосунку є те, наскільки просто і зрозуміло з ним працювати іншим розробникам. Хороший код сам себе репрезентує, пояснює деталі складових продукту, слугуючи не тільки інструкцією для машини, а ще й документом для розробника. «Як саме мають бути реалізовані ці принципи, вирішує техлід або СТО проєкту, тому підходи до їхнього застосування різняться. Водночас незалежно від архітектури та інтерпретації, модуль, написаний по SOLID в одній системі, буде не сильно відрізнятися від модуля, написаного за цими принципами в іншій системі, адже обидва будуть наближені до однакової структури якості», — каже Єгор. Розглянемо кожен принцип детальніше та розберемо приклади. Дисклеймер: наведені прикладу коду написані винятково в демонстраційних цілях. Принцип єдиної відповідальності (SRP) Цей принцип стверджує, що кожен клас або модуль має бути відповідальним лише за одну конкретну задачу, отже, мати лише одну причину для зміни. Це допомагає зменшити залежність між різними частинами коду. «Вивчаючи структуру великої системи, ми маємо обмежений контекст сприйняття і бачимо інформацію лише в певному радіусі. Якщо вся логіка буде описана в одному файлі, код займатиме десятки тисяч рядків, і ми нічого не зрозуміємо. Щоби ми могли сприймати систему, ми розбиваємо її на складові — пояснює Єгор. — Про це нам каже SRP. Цей принцип полягає у тому, щоби розділяти елементи системи за зоною їх призначення, щоби один модуль не мав більш ніж однієї зони відповідальності. У такий спосіб їх простіше вивчати, а також, чим менше відповідальностей має модуль, тим менше причин його змінювати, і тим менше потенційних причин його зламати. Принцип SRP допомагає подолати поширений антипатерн GodObject, коли один об'єкт у системі виконує велику кількість функцій або має занадто велику кількість властивостей. Іноді його називають «Singleton на стероїдах» або «Монолітний обʼєкт». На прикладі нижче — клас, що відповідає одразу за все. Відповідно, зміна в одній з частин класу поставить під загрозу всі інші. class ResponsibleForEverything { public function buildSelf() { /// } public function readDb() { /// } public function writeDb() { /// } public function mapObjects() { /// } } В ідеалі розробники мають писати класи так, щоб їх не довелося часто змінювати. Отже, цей клас варто розбити на декілька. Відповідно тепер, якщо нам треба змінити логіку відправки імейла, це не вплине на інші функції. class ResponsibleForBuild { public function buildSelf() { /// } } class RespnsibleForDb { public function readDb() { /// } public function writeDb() { /// } } class ResponsibleForMail { public function sendMail() { /// } } У цього принципу є і зворотна сторона. Розробники можуть помилково вважати, що кожен клас повинен робити тільки одну функцію від самого початку. Це може призвести до надмірної грануляції, якщо не забезпечується баланс між атомізацією та зручністю в управлінні класами. Натомість наслідування цього принципу полягає у двох напрямах. З одного боку варто розділяти великі класи, які містять багато функцій, а з іншого — уникати дрібних однотипних класів, розмазаних по коду, які важко обʼєднувати за сенсом. «Декомпозуючи код, важливо балансувати, щоби кожен модуль був якомога стрункішим, але сприйняття системи залишалося звʼязним. Інколи ООП сприймається занадто буквально, і це перетворюється на підхід «розділю цей клас на ще три, бо так рекомендує SOLID». Такий код читати важко», — Єгор Ілющенко. Принцип відкритості/закритості (OCP) Згідно з цим принципом, програмні сутності (класи, модулі, функції) повинні бути відкритими для розширення, але закритими для модифікації. Це допомагає зробити систему більш гнучкою, забезпечити можливість додавати нову функціональність, не торкаючись старого коду. Наприклад, клас для обробки платежів має легко розширюватися для додавання нових методів оплати. «Open/Closed — досить неоднозначний принцип, багато розробників неправильно інтерпретують його. Коли я вивчав ці принципи, не розумів, як саме закрити систему від змін і думав, що суть в тому, щоб закрити поля модифікатором private. Насправді ж його суть полягає у правильній побудові модулів, щоби розширення логіки не вимагало переписування старого коду», — каже Єгор. Приклад порушення принципу Open/Closed: class ClosedForExtensionChangesIsOnlyOptionToEdit { public function getStats($userId) { $stats = []; if ($userId) { $mysqlStat = getUserStatsFromDb($userId); $stats[] = $mysqlStat; } return $stats; } } Тепер уявімо, що нам треба додати до статистики дані з thirdParty ресурсів. class ClosedForExtensionChangesIsOnlyOptionToEdit { public function getStats($userId) { $stats = []; if ($userId) { $mysqlStat = getUserStatsFromDb($userId); $stats['mysqlStat'] = $mysqlStat; $user = getUserFromDb(); if ($user->thirdPartyId) { $thirdPartyStat['thirdPartyStat'] = getUserStatFromThirdParty($user->thirdPartyId); } } return $stats; } } У такій реалізації щоразу, коли потрібно розширити логіку, ми маємо лізти в оригінальний клас, розбиратися в ньому і вносити зміни. Як це «лікується»: Interface UserStatScraperStrategy { public function getStatKey(); public function getStat($userId); } class MysqlUserStatScraperStrategy implements UserStatScraperStrategy { public function getStatKey() { return 'mySqlStat'; } public function getStat($userId) { return getUserStatsFromDb($userId); } } class ThirdPartyUserStatScraperStrategy implements UserStatScraperStrategy { public function getStatKey() { return 'thirdPartyStat'; } public function getStat($userId) { return getUserStatFromThirdParty($userId); } } class OpenForExtension { public function __construct( private $statScrapingStrategies, ) {} public function getStats($userId) { $stats = []; foreach ($this->statScrapingStrategies as $strategy) { $stats[$strategy->getStatKey()] = $strategy->getStat($userId); } return $stats; } } new OpenForExtension([ $mysqlUserStatScraperStrategy, $thirdPartyUserStatScraperStrategy ])->getStat(1); Тепер, щоби отримати дані, наприклад, з MongoDB, нам достатньо створити імплементацію читання в окремому файлі і додати до залежностей OpenToExtension. Код самого класу OpenToExtension змінювати не доведеться. Interface UserStatScraperStrategy { public function getStatKey(); public function getStat($userId); } class MysqlUserStatScraperStrategy implements UserStatScraperStrategy { public function getStatKey() { return 'mySqlStat'; } public function getStat($userId) { return getUserStatsFromDb($userId); } } class ThirdPartyUserStatScraperStrategy implements UserStatScraperStrategy { public function getStatKey() { return 'thirdPartyStat'; } public function getStat($userId) { return getUserStatFromThirdParty($userId); } } class MongoUserStatScraperStrategy implements UserStatScraperStrategy { public function getStatKey() { return 'mongoStat'; } public function getStat($userId) { return getUserStatFromMongo($userId); } } class OpenForExtension { public function __construct( private $statScrapingStrategies, ) {} public function getStats($userId) { $stats = []; foreach ($this->statScrapingStrategies as $strategy) { $stats[$strategy->getStatKey()] = $strategy->getStat($userId); } return $stats; } } new OpenForExtension([ $mysqlUserStatScraperStrategy, $thirdPartyUserStatScraperStrategy, $mongoUserStatScraperStrategy ])->getStat(1); Розробники можуть помилково вважати, що мають робити код максимально розширюваним, додаючи зайвий рівень абстракції. Це може вивести до збільшення складності коду та ускладнити його розуміння для інших розробників. Також важливо розуміти, що OCP не означає відмову від змін або відсутність рефакторингу. Це скоріше прагнення створити код, який легко розширюється, але не піддається частим змінам. Принцип заміщення Лісков (LSP) Цей принцип каже, що підкласи базового класу повинні легко займати його місце без додаткових змін в коді. Це гарантує, що використовуючи поліморфізм під час внесення змін у систему, ми не «вистрілимо собі у ногу». «Суть цього принципу не в тому, що ми можемо замінити батьківський клас дочірнім, а в тому, яким вимогам повинні відповідати дочірні класи. Якщо «батько» виконує функцію певним чином, то будь-яка «дитина» має зважати на це і не перекривати стару функціональність новою логікою. Наприклад, якщо у нас є базовий клас сповіщень. Він записує файл в системі, фіксує згадку в лог, що було відправлено повідомлення, а потім відправляє його, наприклад, на пошту. Якщо ми створюємо дочірній клас, в якому реалізується така ж функція відправки, але без логів. Виходить, що ми порушуємо принцип Лісков, адже підставляючи «дитину» на місце батька, ми втрачаємо логіку логування» — пояснює Єгор Ілющенко. Наприклад, у нас є код: class OldParent { public function notifySubscribers() { //log time //get subscribers //notify subscribers via email } protected function getSubscriberIds() { //giveIds } } Все було добре, але раптом нас попросили зробити кнопку, яка замість імейла відправить смс-повідомлення. class NewChild extends OldParent { public function notifySubscribers() { //get subscribers from parent //notify subscribers via sms } } Через місяць до нас приходить продакт-менеджер і каже, що бюджет на відправку смс-повідомлень раптово витратився, і треба дізнатись, чому так сталося. Щоби визначитись, де все пішло не так, ми дивимося логи, але ми не бачимо жодної згадки про відправку смс. Здогадуєтеся, чому? Саме через порушення принципу Лісков: ми замінили стару реалізацію новою, забувши проконтролювати відповідність нової логіки до стандартів старої. Всі підтипи базового класу повинні бути взаємозамінними з «дітьми» без ризиків і необхідності поглиблення в деталі — про це і каже правило Лісков. Правильний клас виглядав би так: class NewChild extends OldParent { public function notifySubscribers() { //log time //get subscribers from parent //notify subscribers via sms } } Принцип Барбари Лісков завʼязаний на ідеї наслідування, від якої розробники намагаються відійти в останні роки, адже це передбачає прямі залежності від реалізації замість абстракцій. Тому це правило застосовується менше за інші. Принцип розділення інтерфейсу (ISP) «Залежність від багажу, який вам не потрібен, може спричинити проблеми, яких ви не очікували», — пише Роберт Мартін, описуючи цей принцип. Він вчить, що обʼєкти не повинні залежати від методів інтерфейсів, які вони не використовують. Приклад порушення ISP — створення одного великого інтерфейсу з багатьма методами, щоби передбачити всі можливі потреби. Клієнти, що залежать від цієї абстракції, можуть не потребувати її в повному обсязі, через що тягнутимуть зайвий багаж за собою. Щоби цей дизайн відповідав ISP, потрібно створити менші інтерфейси, які охоплюватимуть лише поведінку, яку використовує кожен із клієнтів. Отже, замість одного загального інтерфейсу варто створювати декілька простих та мінімалістичних, які відображатимуть потреби клієнтів та не міститимуть зайвого функціоналу. Принцип інверсії залежності (DIP) Цей принцип каже, що низькорівневі модулі не повинні залежати від високорівневих, і обидва повинні залежати від абстракцій. Також вказує на те, що абстракції не повинні залежати від деталей, а деталі мають залежати від абстракцій. Розглянемо приклад: class IWorkWithThirdParty {} class MysqlSomething { public function __construct(public IWorkWithThirdParty $view) {} public function checkData() { //get3party data //readDb //give result } } class Command { public function __construct(private MysqlSomething $mysqlSomething) {} public function __invoke() { return $this->mysqlSomething->getData(); } } Тут порушено два ключові принципи: залежність від реалізації та залежність модуля MysqlSomething від сервісного рівня, що знаходиться вище і виступає прошарком між view і доменним рівнем. Переробимо це відповідно до DIP: interface PassCheck { public function passCheck(); } interface GetIds { public function getIds(); } class IWorkWithThirdParty implements GetIds { public function getIds() { // } } class MysqlSomething implements getIds { public function getIds() { // } } class ExternalDataConsistencyChecker implements PassCheck { public function __construct(private array $idSources) {} public function check() { $idVariations = []; foreach ($this->idSources as $idSource) { $idVariations[] = $idSource->getIds(); } if (VARIATIONS_IS_NOT_EQUAL) { return false; } return true; } } class SyncExternalDataCommand { public function __construct(private PassCheck $idConsistencyCheck) {} public function __invoke() { if (!$idConsistencyCheck->passCheck()) { //pass check } } } Тепер всі модулі залежать тільки від абстракцій. Вся логіка, що не стосується бази, винесена нагору в сервісний рівень. Ієрархія залежностей від абстракцій вибудована коректно: згори вниз. Як засвоїти принципи SOLID Початківці, які тільки починають вивчати принципи SOLID, можуть зіткнутися з низкою проблем. Розуміння. Перша зустріч може бути складною, оскільки ці правила вимагають нового способу мислення щодо структури коду та взаємодії об'єктів. Застосування. Навіть зрозумівши ці принципи у навчальних прикладах, може бути важко визначити, як саме застосовувати їх в конкретних робочих ситуаціях. Внесення змін. Якщо значний обсяг кодової бази вже написаний без урахування SOLID, застосування цих принципів може викликати суперечності зі структурами, що існують. Збільшення часу розробки. На етапі навчання та адаптації впровадження SOLID може спричинити складність коду або збільшення часу розробки. Проте у довгостроковій перспективі використання SOLID допомагає створити більш підтримуваний, гнучкий та розширюваний код, зменшуючи загальний технічний борг. Розробники повинні розуміти, що освоєння SOLID — це тривалий процес. Підвищення рівня навичок відбувається з часом. Поступове вивчення та постійна практика допомагають зрозуміти ці принципи та навчитися застосовувати в роботі. Вносячи зміни в існуючий код, важливо вміти адаптувати правила до реальних сценаріїв та змінювати код поетапно, не переписуючи його повністю. «Загалом не варто зациклюватися на застосуванні принципів. Вони не гарантують, що ваш код — хороший, і з ним зручно працювати. Початківцям краще концентруватися на загальних методиках якості коду, таких як відсутність повторення, простота умов if, обмежена кількість аргументів тощо. Якщо написати код з урахуванням загальних стандартів якості коду, ви несподівано відкриєте, що він цілком підпадає під SOLID», — рекомендує Єгор Ілющенко. Є низка шаблонів проєктування, з якими важко дотримуватися принципів SOLID: Singleton, Active Record, Template Method, Multiton, Builder, Facade. Деякі з них порушують принципи SRP, ISP та LSP. Проте в деяких сценаріях їхнє використання цілком обґрунтоване, а комбінація різних шаблонів може сприяти більш сучасній та підтримуваній архітектурі.

З 27 листопада по 1 грудня 2023 року освітня екосистема TRMNL4 проведе тиждень лекцій T4.Startups Week, де власники стартапів на ранніх стадіях зможуть дізнатися більше про побудову стійкого технологічного бізнесу. В межах програми досвідчені ІТ-підприємці та інвестори з мережі TRMNL4 поділяться практичними порадами щодо розробки та перевірки ідей стартапів, побудови високоефективних команд, досягнення ключових показників ефективності та інших питань, які цікавлять засновників на стадіях pre-seed. Учасники матимуть змогу поставити питання та обмінятися ідеями зі спікерами. «Уявіть, що ви засновник стартапу, який тільки почав свій шлях. Ви не знаєте, на чому зосередитися: на ідеальному продукті чи швидкому зворотному зв'язку з користувачами, на простих і швидких процесах чи орієнтованих на масштабування, на бутстрепінгу чи пошуку інвестицій. Ми запросили п'ятьох експертів, аби вони поділилися своїми hard lessons із фаундерами-початківцями», — розповідає Тетяна Ладанова, керівник програми для стартапів TRMNL4. В межах програми спікери обговорять такі теми: «Нестандартний бік стартап-шляху: уроки ранньої стадії»; «Розвиток стартапу від перших етапів до досягнення найкращих показників»; «Магія операційної діяльності стартапу: процвітання на кожному етапі»; «Growth Mindset. Що інвестори шукають у командах»; «Складний вибір, успішний бізнес. Прийняття рішень у стартапах». Програма лекцій розроблена спеціально для засновників стартапів на стадії pre-seed, але фаундерам більш зрілих стартапів також буде цікаво дізнатися про нюанси побудови технологічних компаній та досвід успішних бізнесів. Програма безоплатна для учасників, але необхідна реєстрація.

16 листопада, в день закриття щорічної технологічної конференції Web Summit, на головній сцені заходу пройшов фінал конкурсу стартапів PITCH. За результатами голосування журі та глядачів переміг бразильський стартап Inspira — розробник ШІ-асистента, який допомагає юристам систематизувати інформацію та оптимізувати рутинну роботу. Стартап, заснований під час пандемії, отримав перше фінансування у розмірі 960 000$ в pre-seed раунді у 2021 році. Рішення, яке пропонує ринку Inspiria, покликане демократизувати юридичну сферу та зробити юридичну інформацію більш доступною для всіх. «Нині ми спостерігаємо стрімкий ріст інвестицій у legaltech. Тому ця перемога для нас — найкоротший шлях до нових ринків і можливостей» — сказав співзасновник стартапу Енріке Ферейра під час нагородження на сцені Web Summit. Бразильський стартап переміг у декількох етапах відбору серед 105 компаній з усього світу, заздалегідь обраних для участі у конкурсі. Поряд з Inspira за головний приз змагалися українські Easy Peasy Insurtech (платформа для страхування), EQ.app (застосунок для покращення ментального здоров’я), екостартап S.Lab та Uspacy (платформа для організації цифрового робочого простору).

У останній місяць осені пропонуємо перелік вакансій для продакт-менеджерів. Пропозиції — на різний смак, напрям і ґрейд. Обирайте, з чим цікавіше працювати — застосунком для вивчення іноземних мов, фінтех-продуктом або ж апкою для розпізнавання рослин з ML-технологіями. У нашому новому дайджесті знайдеться пропозиція для кожного. Chief Product Officer Професіонала на одну з ключових управлінських посад шукають до компанії Boosters, флагманський продукт якої — застосунок для вивчення іноземних мов Promova. Платформа дає змогу опановувати мову самостійно або ж відвідувати розмовні клуби, групові заняття чи індивідуальні онлайн-заняття з менторами. Крім того, Promova взяла участь у національній програмі Future Perfect та безкоштовно навчатиме українців англійської мови. Розвиток подібного продукту — амбітний виклик, з яким впорається людина, яка керувала проєктами в технологічних бізнесах, запускала та масштабувала диджитал-продукти. Важливі стратегічне мислення та здатність розв'язувати проблеми. Серед зон відповідальності — управління продуктовою та інженерною командами, аналіз ринку та розробка продуктової стратегії, а також розвиток своєї команди. Product Manager Genesis Accelerator розвиває перспективні ІТ-продукти у секторі B2C: інвестує в проєкти на ранніх стадіях, нарощує масштаби та допомагає створювати успішні компанії з продуктами для мільйонів користувачів у всьому світі. Це вакансія для фахівця-початківця. Він працюватиме з продуктом у сфері Fashion. Робочі обов’язки стандартні: аналізувати конкурентів, генерувати продуктові гіпотези, перевіряти їх через A/B-тести та планувати завдання. Ідеальний кандидат уже працював на аналогічній посаді мінімум пів року, знає ключові метрики та їхні взаємозв'язки, розуміється на UI/UX-частині продукту, володіє англійською на рівні Upper Intermediate. Перевагу нададуть фахівцю, який знає, як сформулювати грамотне ТЗ для команди розробки. Product Manager (вакансія закрита) Також у Genesis Growth Accelerator шукають продакта рівня мідл. Вимагають два-три роки релевантного досвіду. На позиції він буде проводити користувацькі дослідження, генерувати продуктові гіпотези, проводити А/В-тести, а ще — координувати роботу дизайнерів, розробників та аналітиків. Найкраще з цим завдання впорається фахівець, що професійно володіє MS Excel та Power Point, розуміється на базовій статистиці та теорії ймовірності, вміє швидко рахувати й робити висновки. Чудово, якщо він ще й знає SQL або Python, зіштовхувався з REST API та працював з системами аналізу й візуалізації даних, як-от Google Analytics, Amplitude, Mixpanel, Tableau, Power BI. Product Marketing Manager (вакансія закрита) Компанія PlantIn розробляє застосунок для догляду за рослинами на основі ML-технологій. Команда посилює вебнапрям та шукає фахівця, який його розвиватиме. Основне завдання — взаємодіяти з маркетинг-командою, аналізувати поведінку користувачів, генерувати продуктові гіпотези та A/B-тести, досліджувати ринок та конкурентів. Очікують, що кандидат має два чи більше років досвіду в роботі з B2C-продуктом, успішно проводив A/B-тести, працював з інструментами аналітики та дизайну, а також знає англійську мову. Вакансії партнерів Product Manager Продакт-менеджера шукають до Codefinity — освітньої платформи для навчання програмування. Платформу заснували у 2021 році, і з того часу її завантажили вже сотні тисяч людей по всьому світу. Що потрібно: один-два роки досвіду на посаді продакт-менеджера, бізнес- чи дата-аналітика, орієнтованість на результат та знання всіх етапів життєвого циклу розробки. Робочі завдання передбачають дослідження користувачів, аналіз метрик, співпрацю із саппортом, а також розробку ТЗ для технічної та дизайн-команд відповідно до бізнес-візії. Product Marketing Manager Ще один фахівець приєднається до Codefinity, аби вдосконалити наявні та створити нові воронки для залучення користувачів. Для цього йому знадобиться досвід роботи у продакт-менеджменті або маркетингу з фокусом на User Aquisition, вміння оптимізувати рівень конверсії, здатність аналізувати дані та робити висновки, які потім можна буде використати для рішень у продукті. Product Owner Solidgate — це B2B-платформа у сфері онлайн-платежів. Команда будує фінтех-екосистему для швидкого, безпечного та вигідного приймання оплат в усьому світі. Шукають Product Owner, який розвиватиме сервіси для зменшення ризиків, пов’язаних з фродом з боку платників. На позиції кандидат очолить продуктово-технічну команду Chargeback Prevention та відповідатиме за Discovery-стадію. Щоб приєднатися, потрібно мінімум три роки комерційного досвіду, півтора з яких на позиції PO або Product Manager, досвід побудови успішних IT-продуктів, в ідеалі — масштабних та складних проєктів. Технічний бекграунд, англійська рівня B1, обізнаність у UI/UX стануть перевагами. Що почитати про продакт-менеджмент? Матеріали, щоб розібратися в продакт-менеджменті Позиція продакт-оунера з’явилася у 90-x роках разом з методологією Scrum. Суть його роботи — зібрати вимоги стейкхолдерів, обрати ключові з них та донести команді. Залежно від бізнесу, він може керувати продакт-менеджером, або підпорядковуватися йому. Останній, своєю чергою, відповідає за повний життєвий цикл продукту. Його мета — створити прибутковий продукт, синхронізувавши роботу усіх департаментів. Детальніше — у двох наших гайдах: про роль продакт-оунера та позицію продакт-менеджера. Що дратує продакт-менеджерів. 9 болів від фахівця з Keiki Продакт-менеджери першими знаходять болі користувачів, та роблять все, аби їх позбутися, та вдосконалити продукт, з яким працюють. Однак вони й самі мають чимало складних моментів у роботі: нечіткі посадові інструкції, відповідальність за команду, невизначеність на шляху до ідеальних показників та інше. За посиланням — детальний перелік розповсюджених болів. 7 міфів продуктового ІТ. Спростовує CTO Продуктове IT, як і про інші типи ІТ-бізнесів, має низку упереджень. Наприклад, є думка, що через гонитву за бізнес-показниками доводиться поступатися якістю. А що таке якість? Здавалося б, відповідь очевидна, але ні — можна сперечатися. Або ще один стереотип — рішення диктують цифри в аналітиці, а програміст — це просто «робочі руки». Так, без data-driven рішень вдалого продукту справді не вийде, але аргументована думка розробника не менш важлива, й також впливає на фінальний результат. У тексті — ще більше таких прикладів та спростувань.

Українська EdTech компанія Headway, партнер Genesis, увійшла до переліку європейських стартапів, які є найбільш перспективними у сфері цифрової освіти — The Europe EdTech 200 від міжнародної аналітичної компанії HolonIQ. The Europe EdTech 200 щорічно представляє список із двохсот найбільш молодих, швидкозростаючих та інноваційних компаній Європи у сфері цифрової освіти. Мета — привернути увагу інвесторів до стартапів та продемонструвати перспективні європейські компанії учасникам EdTech ринку. Перелік містить 10 категорій: Content, («Контент»), Management systems («Системи менеджменту»), Advanced Technology («Передові технології»), Tutoring and Test prep («Репетиторство та підготовка до тесту») та інші. Headway потрапив до рейтингу компаній для «Онлайн навчання». Список формується на основі даних Impact Intelligence Platform, а також якісних оцінок від підрозділу HolonIQ Intelligence Unit та експертів із ринку за п’ятьма параметрами: Ринок — якість і відносна привабливість конкретної категорії ринку, в якій конкурує компанія. Продукт — якість, унікальність і його вплив. Команда — досвід та різноманітність лідерів. Капітал — фінансовий стан компанії та її здатність забезпечувати достатнє фінансування. Динаміка — позитивні зміни розміру, швидкості та впливу компанії з часом. «Радий бачити Headway у цьогорічному списку The Europe EdTech 200. Це вкотре доводить наскільки цінними для світу є технології, які ми розробляємо тут, в Україні», — коментує CEO та засновник Headway Антон Павловський. Крім Headway, HolonIQ включили до переліку й інші перспективні EdTech компанії родом з України. Серед них: Classtime — платформа для інтерактивного дистанційного навчання, Buki — ресурс для пошуку репетиторів у 7 країнах, Gios — інтерактивні курси з математики та All right — платформа для дітей із вивчення англійської мови. HolonIQ — міжнародна компанія, що спеціалізується на аналітиці глобальних даних в сферах освіти, охорони здоров’я, енергетики та екологічної стійкості. Компанія була заснована в 2018 році, має офіси в Нью-Йорку, Лондоні та Сіднеї. Серед клієнтів HolonIQ: Amazon, Apple, Unicef, Lego та інші. Headway — EdTech стартап, що створює продукти з мікронавчання. За дослідженням ринку від GP Bullhound, компанія входить до переліку найкращих стартапів Європи з потенціалом досягти капіталізації в $1 млрд у найближчі два роки. Також входить до списку найвпливовіших компаній у світі, що трансформують цифрове навчання та навички спеціалістів — GSV 150. У 2023 компанія отримала нагороду Allstars Awards — Allstar Company Challenge, а CEO та засновник Антон Павловський став Entrepreneur of the Year. Компанію створили у 2019 році. За 4 роки вона зросла з 3 до понад 200 людей у команді та відкрила офіси у Києві, Варшаві, Нікосії та Лондоні. Продукти Headway допомагають розвиватися 80+ мільйонам людей у світі через лаконічні формати освітнього контенту: самарі, курси, ігри, інфографіки. Флагман — Headway app — застосунок № 1 у світі у ніші книжкових самарі. Його завантажили понад 30 млн користувачів у світі. У 2023 році застосунок отримав відзнаку Editors’ Choice від App Store та потрапив на головний екран App Store у США як App of the Day п’ять разів.

Раніше, до широкого розповсюдження інтернету, всі розробники були фулстеками. Застосунки та сайти були простими, тож фактично кожен міг розробити та вдосконалити продукт самотужки. Коли технології розвинулися, з’явився поділ на фронтендерів та бекендерів, а коли інструменти розробників стали ще потужнішими — роль фулстека знову повернулася до переліку затребуваних вакансій. Про позицію єдиного розробника у продукті, його навички, обов’язки та кар’єрний шлях розповідає Антон Пінкевич, Full Stack Team Lead у Universe, компанії з екосистеми Genesis. > Хто такий Full Stack Developer > Коли компанії наймають Full Stack Developer > Як з’явилася роль Full Stack Developer > Обов’язки Full Stack Developer > Навички та знання Full Stack Developer > Переваги напряму > Недоліки напряму > Види фулстек-розробників > Чотири міфи про фулстек-розробників > Як стати фулстек-розробником Хто такий Full Stack Developer Full Stack Developer — це програміст, який розуміється і на користувацьких інтерфейсах, і на серверних компонентах. Він може самостійно реалізувати MVP або навіть нескладний повноцінний продукт. Кожен такий розробник володіє певним набором мов програмування, фреймворків, утиліт та бібліотек для фронтенду та бекенду — це його стек. Робота з базами даних чи операційними системами, відправка проєкту на прод, його оновлення також входять до обов’язків фулстек-розробника. «Моя кар’єра фулстек-розробника розвивалася в два етапи. Спочатку був власний проєкт, а потім великий бізнес. У 2015 році ми з командою запускали онлайн-магазин чаю. Я уже тоді займався програмуванням, тож взявся за технічну частину проєкту. Стек обирали з нуля, тож я мав змогу експериментувати з усім, що було цікаво. Пізніше я потрапив до Universe — як фронтенд-розробник рівня сеньйор. Ми разом з командою з трьох бекендерів працювали над запуском нового напряму. Пізніше бекенд-команда розпалася, а у наймі кількох окремих спеціалістів уже не було бізнес-потреби. Мене запитали, чи впораюся із підтримкою серверної частини — і я погодився, адже мав відповідний досвід. Так я вдруге став фулстеком, уже на боці крупного IT-бізнесу», — розповідає Антон Пінкевич, Full Stack Team Lead в Universe. Коли компанії наймають Full Stack Developer Подібна вакансія може з’явитися в кількох випадках. Наприклад, це стартап, якому необхідно швидко запуститися. Або ж продукт уже розробили, і наразі потрібна тільки підтримка. Тоді замість команди з фронтенд- та бекенд-розробників бізнесу простіше найняти одну людину, яка швидко розбереться у логіці продукту та оперативно вноситиме зміни. «Стартапу чи маленькому бізнесу завжди краще наймати фулстека. Здебільшого, одна людина цілком впорається з потрібним навантаженням. Коли стартап виростає, а бізнес-модель стає більш зрозумілою та виправданою, можна наймати більшу команду», — говорить Антон Пінкевич. Як з’явилася роль Full Stack Developer На початку доби інтернету диджитал-продукти були простими та статичними. Для верстки інтерфейсу, налаштування серверів та розміщення проєкту на хостингу не потрібно було місяцями вивчати актуальні технології. Одна людина цілком могла спроєктувати повноцінний застосунок чи сайт, тож всі розробники за замовчуванням були фулстеками. Пізніше інтернет почав поширюватися серед користувачів, і конкуренція між виробниками ПЗ стала зростати. Аби виділитися серед інших, розробники придумували більш інтерактивний дизайн та комплексну функціональність. Урешті-решт, застосунки та сайти стали настільки складними, що одна людина уже не могла впоратися з підтримкою всього продукту. Тоді з’явилися спеціалізації. Користувацьким інтерфейсом та скриптами на стороні клієнта почали опікуватися фронтенд-розробники, а серверну частину взяли на себе бекендери. Посиленню спеціалізації сприяла поява фреймворків та бібліотек на кшталт Ruby on Rails, Django та AngularJS. З часом до роботи над проєктами залучали все більше людей, тож виробництво продуктів та сервісів дорожчало. Не стояв на місці й розвиток технологій. Спочатку обертів активно набирали jQuery, CSS3, HTML5. Пізніше популярним став стек LAMP (Linux, Apache, MySQL, PHP / Python / Perl) з відкритим вихідним кодом усіх компонентів. Рішення для хостингу також ставали доступнішими. Згодом численність та різноманітність технологій знову дали змогу окремим програмістам брати на себе повний цикл створення застосунку. Обов’язки Full Stack Developer Роль фулстека передбачає всі аспекти створення вебзастосунків — від проєктування архітектури до інтеграції продукту з базою даних та його підтримки. «Це дуже схоже на роль СТО, але з меншим масштабом, — каже Антон Пінкевич. — Запити від бізнесу можуть бути різними — і аналітика, і верстка, і оптимізація. А вже що робити і як саме, розробник обирає самостійно». Якщо детальніше, то фулстек: пише код для фронтенд- та бекенд-частини; забезпечує інтеграцію продукту з базою даних; налаштовує серверну частину, зокрема, створює API для взаємодії з іншими службами й застосунками; підтримує адаптивний дизайн застосунків; виявляє та виправляє помилки в продукті та оптимізовує його продуктивність; стежить, щоб проєкт був готовий для тестування; розгортає продукт на серверах та підтримку його роботи в продуктивному середовищі; оновлює продукт та відповідає за його функціональний розвиток на основі вимог. Навички та знання Full Stack Developer Такий фахівець має хоча б поверхово розумітися на кожному шарі технологічного стека. Йдеться не лише про володіння мовами програмування фронтенду та бекенду, а й обізнаність у базах даних, серверних налаштуваннях, сучасних фреймворках, системах контейнеризації тощо. Втім, однаково добре розумітися і на фронтенді, і на бекенді не вийде. Фулстек-розробник не може бути майстром у всьому, зазначає Антон Пінкевич. «Подібних людей просто не існує. Навіть у досвідченого фахівця якісь навички будуть сильнішими, а якісь слабшими. У мене, наприклад, фронтенд прокачаний на максимум, а от у плані бекенду ще є куди зростати», — говорить розробник. Пріоритети для розвитку в конкретний момент варто визначати, залежно від бізнесу, в якому працюєте чи хочете працювати. «Наприклад, у фінтех-продуктах фронтенд часто дуже простий, він може складатися з однієї адмінки. А от «під капотом» — складна інфраструктура, яку підтримують саме бекендери. Якщо це освітній продукт з акцентом на клієнтську частину, все навпаки. Бекенд тут можна легко закрити з допомогою BaaS (backend as a service), а от для фронтенду потрібен досвідчений фахівець», — пояснює Антон Пінкевич. Хард-скіли Ось низка навичок, якими варто оволодіти будь-кому, хто прагне стати фулстек-розробником. HTML та CSS. HTML потрібен, щоб наповнити сторінку контентом, CSS — для того, щоб гарно її оформити. Ці два інструменти дозволяють спроєктувати все, що побачить користувач. JavaScript. Це мова-«монополіст» у фронтенді, якою можна писати програми майже будь-якої складності — від бота для відправки повідомлень до багатошарових ecommerce-проєктів. JavaScript повністю інтегрується з HTML, CSS й серверною частиною, підтримується основними браузерами та суттєво знижує навантаження на сервер. Angular, Vue, React або ж Next.js. Перші три — це взаємозамінні фреймворки, тож фулстек-розробнику достатньо знати хоча б один із них. Вони потрібні, аби вебсторінка була функціональною, а не лише відображала інформацію. Next.js дає можливість писати фулстек-застосунки «з коробки». Git. Система контролю версій допомагає відстежувати зміни у коді, повертатися до попередніх версій та працювати над кількома гілками розробки паралельно. Мови бекенду. Від мови бекенду залежить спеціалізація фулстек-розробника. Вибір мов доволі великий, розглянемо декілька найбільш популярних. PHP. Ця потужна та гнучка мова стала однією з найпопулярніших мов у бекенді завдяки тому, що її використовували популярні CMS, як-от WordPress. Його використовують, щоб надати динамічності та інтерактивності вебсайтам. Найперше варто вивчити фреймворки Laravel або Symfony. Java. Мова, яка уже стала класичною у програмуванні. Зазвичай її використовують для створення ігор, застосунків для операційної системи Android, а також серверних застосунків. Найперше варто вивчити фреймворки Spring або Hibernate. Python застосовують в аналізі даних, при машинному навчанні, веброзробці, геймдеві та багатьох інших сферах. Ключові фреймворки Django, Flask та FastAPI. Node.js. Відносно новий інструмент, який дає змогу виконувати JavaScript-скрипти на сервері, уже став популярним серед стартапів. Окрім роботи із серверними скриптами для вебзапитів, також використовується для створення клієнтських та серверних програм. Саме Node.js перетворила JavaScript на розповсюджену мову програмування з великою спільнотою розробників. Він має бути знайомий із фреймворками Adonis.js та Express.js. інші мови — C#, Scala, Go, Ruby. HTTP і REST. Аби системи легко обмінювалися даними, а застосунок можна було б швидко масштабувати, фулстек-розробник повинен базово розумітися на протоколах взаємодії мережі та користувача. Бази даних. Фулстек може підібрати оптимальну систему для зберігання даних та оптимізувати роботу з ними. Для цього він вивчає реляційні, як-от MySQL або PostgreSQL та не реляційні БД на кшталт MongoDB, Cassandra чи Redis. Базові знання DevOps дають змогу закрити увесь стек веброзробки. Ключове тут — знати основи системного адміністрування, Docker та Kubernetes для запуску застосунків, AWS MS чи Azure для хостингу застосунків. Софт-скіли Упередження про те, що для вдалої кар’єри розробнику потрібні лише хард-скіли потроху залишається у минулому. Саме «гнучкі» навички можуть стати визначальним фактором під час влаштування на роботу. Ось декілька ключових: вміння брати на себе відповідальність та шукати рішення; робота в команді; розуміння, як працює бізнес; гнучкість та адаптивність; вміння домовлятися; тайм-менеджмент. Ґрейди Попри упередження, що всі фулстеки — це сеньйори, їх кар’єрний шлях також підпорядковується певним ґрейдам. «Фахівець рівня джуніор не може завершити фінальну задачу самостійно, йому потрібне деталізоване ТЗ. Втім, навіть у своїй невеликій зоні відповідальності, він уже має набір інструментів та безліч варіантів, як саме вирішити завдання. Мідл здатний закривати завдання самотужки, якщо з ТЗ чітко зрозуміло, що саме має отримати бізнес. У сеньйора завдання складніші та абстрактніші, на цьому етапі в роботі з’являється більше невизначеності», — говорить Антон Пінкевич. Переваги напряму Кар’єрні можливості. Хочеться перемкнутися на чистий фронтен або бекенд? Запросто. Прагнете зростати до СТО? Будь ласка. Мрієте запустити свій продукт? Робота фулстек-розробника підготує вас до цього. Гнучкість та швидкість. Комунікаційних ланцюжків менше, ніж коли за фронтенд та бекенд відповідають різні люди, а отже процес розробки суттєво пришвидшується. Менше рутини. Проєкти, завдання та шляхи їх реалізації можуть бути дуже різними, тож фулстек-розробник має менше ризиків вигоріти через рутину. Недоліки напряму Знань ніколи не буде достатньо. Сфера IT постійно розвивається, з'являються нові технології, а тренди змінюються. Щоб створювати актуальні продукти, потрібно постійно тримати руку на пульсі. До того ж фулстек не може стати майстром у всьому — тож якийсь з напрямів його роботи, ймовірно, буде «провисати». Вузькоспеціалізовані фахівці завжди будуть кращими у своїй ніші. Навряд чи вам вдасться повністю зануритися у ту чи іншу мову чи технологію, тож ви завжди будете вміти менше, ніж розробник конкретного напряму. Складні завдання та високе навантаження. Оскільки одна людина має підтримувати всю архітектуру, більш-менш спокійних днів у вашій роботі буде небагато. Завдання будь-якої складності та напряму буде адресуватися саме вам — і з усім доведеться розбиратися самотужки. Види фулстек-розробників Для фронтенд-частини розробники зазвичай вчать приблизно один набір технологій: JavaScript та один з фреймворків. Тому спеціалізація визначається за мовами бекенду. У переліках вакансій можна побачити PHP Full Stack Developer, Java Full Stack Developer, Node.js Full Stack Developer, Python Full Stack Developer. Втім, технологічних стеків набагато більше, ніж мов програмування. Розглянемо, наприклад, MEAN, MERN та MEVN. Основні компоненти стеків — MongoDB, Express.js, Node.js, до яких доєднуться фронтенд-фреймворки Angular, React, Vue. Крім того, є LAMP — набір з чотирьох технологій: операційної системи Linux, вебсервера Apache, сервера баз даних MySQL й мови програмування PHP. Стек RoR чи RoRM призначений для Ruby on Rails. Залежно від запиту, до абревіатури може додаватися буква M, яка означає MySQL чи MongoDB. Останнім часом розробники звернули увагу також на «андеграундний» стек Bun + Elysia + HTMX. В основі — перспективний інструмент Bun, який прагне замінити Node.js. Це швидке середовище виконання JavaScript, бандлер, транскриптор та менеджер пакунків, подібний до Node.js та Deno. Чотири міфи про фулстек-розробників Фулстек-розробнику потрібні лише технічні знання. Фулстек-розробник також має вміти працювати в команді разом з дизайнерами, тестувальниками та продакт-менеджерами, планувати, оцінювати завдання, визначати пріоритети та грамотно розподіляти час, аналізувати дані та ухвалювати рішення тощо. Фулстек розробники вміють писати код будь-якою мовою. Завдання фулстека — спроєктувати клієнтську та сервісну частину. Для цього не потрібно знати безліч мов. Достатньо працювати з JavaScript з ключовими фреймворками фронтенду й одну чи дві мови бекенду. Фулстек — це завжди сеньйор. Насправді ні, все залежить від вимог проєкту. Якщо, наприклад, для підтримки продукту достатньо початкових знань в обох ключових напрямах, то позицію можна обійняти й з ґрейдом джуна. У всіх фулстеків — однакові навички. У реальності існує багато варіантів стеку, а розробник обирає стек відповідно до своїх завдань та проєктів. Наприклад, один програміст може використовувати Python та Django, другий — JavaScript та Node.js, третій — Ruby on Rails. Не варто забувати й про спеціалізації: мобільний, веб- чи SaaS-розробник будуть користуватися стеками відповідно до своїх професійних інтересів. Як стати фулстек-розробником «Я б радив розпочинати кар’єру з фронтенду, адже тоді ви самотужки зможете надати клієнту чи користувачу фінальний продукт у будь-якій ніші. Фахівці з бекенду більше затребувані у B2B-секторі, тож подібних бізнесів суттєво менше», — говорить Антон Пінкевич. Він додає, що для початку варто вивчити конкретний фреймворк. Наприклад, Next.js або ж React. «Останній зараз дуже популярний, зустрічається у вимогах приблизно 80% вакансій. Коли вже зрозуміло, як він працює, можна «закопуватися» далі — розбиратися з JavaScript, в багатопотоковостях, вебворкерах у браузерах тощо. Далі я б радив заглиблюватися у софтверну розробку, починати вчити бази даних та мови бекенду, такі як PHP чи Python», — — каже розробник. Коли ви добре засвоїте більшість основних інструментів для обох напрямів, то зможете претендувати на сеньйорні посади.