Основні завдання бекенд-розробників — проєктування, створення та підтримка спільної для різних платформ частини продукту. Висококваліфіковані бекендери ухвалюють рішення щодо дизайну системи, визначають технічні стандарти, забезпечують масштабованість та зручність обслуговування, а також відповідають за захищеність продукту від кіберзагроз. Утім, на цьому шляху є багато того, що ускладнює процеси та заважає роботі.
Про найбільш розповсюджені болі бекенд-розробників розповідає Олександр Михайлюта, Backend Engineer у Headway, партнерській компанії Genesis.
Якщо попросити бекенд-розробника пояснити те, чим він займається, то розповідь, ймовірно, буде дуже спрощеною, й навряд чи відображатиме суть роботи. Проблема в тому, що так відбувається з більшістю друзів та знайомих.
Коли мене запитують про роботу, я часто відповідаю, що пишу код у Headway. Зазвичай цього достатньо, і люди не питають подробиць. Насправді ж поняття бекенд-розробка передбачає досить широкий пул різних завдань, які можуть відрізнятися відповідно до запитів бізнесу, технологій, мов програмування та конкретних навичок кожного фахівця. Одні спеціалізуються на базах даних, другі — на нюансах використання фреймворків, треті — на інфраструктурі чи продуктових метриках.
Особисто я відповідаю за частину, що безпосередньо впливає на досвід навчання користувачів: елементи, з яких складаються інтерактивні навчальні курси в Nibble (один з продуктів Headway), підбір рекомендованого контенту, розробку внутрішніх інструментів для контент-команди. А ще — трохи займаюся DevOps, частково працюю з фронтендом та формую технічну команду. Буває так, що хочеться детальніше розповісти про свою роботу — можливо, ми з людиною знайдемо точки перетину для подальшої співпраці. Однак детальні розповіді найчастіше призводять до непорозумінь.
Попри прескринінг, чудове резюме та тестове завдання, знайти людей, які дійсно заметчаться з командою — справжній челендж. Ми у Headway цінуємо відповідність культурі подекуди навіть більше, ніж хард-скіли. Та зазвичай, під час найму, ми маємо принаймні одного кандидата на тиждень, який не проходить співбесіду — попри хороше тестове, супровідний лист та навички комунікації. Причина зазвичай криється у важливому для Headway софт-скілі — здатності до рефлексії, тобто вмінні аналізувати свій досвід та робити висновки.
Річ у тім, що наша команда спілкується досить неформально, а співробітникам дають максимальну свободу у виборі дій та підходів для досягнення спільної мети. Так ми можемо залишатися гнучкими, адаптивними, не перетворюватися на бюрократичну машину та якомога довше мати дух стартапу. Через це важливо, аби людина вміла працювати у команді, відстоювати свою думку, якщо потрібно, та працювати над помилками, якщо рішення, яке вона ухвалила, було хибним.
Натомість я часто зустрічаю іншу модель роботи: коли розробники думають, що їхнє завдання — просто написати код, передати його далі й перейти до іншого завдання. У продуктових командах підхід трохи інший: технічні фахівці активно залучаються в проєкт та беруть на себе більше відповідальності. Але і знайти людей з подібним мисленням важче.
Структура нашої команди передбачає, що розробники можуть долучатися не лише до написання коду та проєктування фічей, а й до QA та DevOps. Так, тести мають бути автоматизованими, а код пишеться з урахуванням його запуску в інфраструктурі. Також розробники можуть брати участь у формуванні аналітики та зборі даних.
У чому тут виклик? Кожен хоче швидко виконати свою частину роботи та запустити її в прод. Але тут виникає когнітивне викривлення. Наприклад, ми працюємо над невеликою фічею, але для якісної реалізації потрібно зробити багато роботи: написати тести, продумати інфраструктуру, налаштувати аналітику, встановити алерти, а потім все це треба протестувати. Тому обсяг роботи, який на перший погляд здається невеликим, може займати більше часу, ніж планується на початку.
Утім, подібний підхід має свої переваги. По-перше, люди краще розуміють загальні принципи роботи продукту. По-друге, так фахівець може розвивати різні навички, не обмежуючись одним напрямом у розробці. По-третє, це хороший ґрунт для підсилення одне одного у команді. Наприклад, є людина, яка чудово працює з документацією, любить її писати та структурувати знання. Вона може відповідати за цю частину роботи. Однак тій же людині менше подобається продумувати інфраструктуру — і тоді підключається хтось, кому це до вподоби.
Шляхів для вдосконалення продукту багато, і завжди хочеться зробити більше, аби користувачі могли якомога швидше скористатися новими та вдосконаленими фічами.
Проте обсяг роботи, який може зробити команда, завжди обмежений. Такого роду проблеми можна вирішувати за допомогою грамотного планування та пріоритезації. Архітектура що добре підходить під задачі та високі стандарти якості коду, може вивільнити багато часу для команди. Наприклад, в Nibble ми приділяємо багато уваги автоматизації, зокрема тестуванню, моніторингу, логуванню та інтеграції CI\CD.
Продукти Headway — це і вебзастосунки, і апки на iOS та Android з мільйонами користувачів по всьому світу. Певна кількість юзерів вимикає автоматичне оновлення застосунків. І хоча їх меншість, це впливає на процес розробки, адже тоді виникає поняття «хвіст версій».
Наприклад, ми вже випустили апдейт, але у деяких користувачів застосунок не оновився — і вони все ще користуються старою версією шестимісячної давнини. На відміну від вебзастосунків, які оновлюються централізовано, продукти в мобайлі оновити не завжди можливо, тому стара версія буде залишатися та працювати за старими флоу. Тому коли ми випускаємо нові фічі або змінюємо архітектуру, то враховуємо й наявність старих версій. Через вимогу зворотної сумісності розробка може затягнутися, а це той додатковий час, який легко не врахувати на початкових етапах планування.
Один із способів розв'язати проблему — перемкнути нову версію застосунку на інший API-поінт чи бекенд. Інший поширений підхід — версіонування API. Так можна контролювати, які версії API використовуються, і поступово відключати застарілі. Є ще радикальний варіант — запакувати вебзастосунок в додаток для телефону. Це гарантувало б актуальність фіч, але знизило б швидкодію на пристроях користувачів. Ми, як компанія, не готові йти на подібний компроміс, бо хочемо, щоби застосунки були нативними, працювали швидко й відповідали очікуванням юзерів на всіх платформах.
Після запуску Headway мав типову для всіх стартапів мету — вижити. Ми швидко перевіряли купу гіпотез без жодних гарантій, що це злетить. Тому вийшло так, що бізнес-логіка в частині платежів і аналітики здебільшого зосереджувалася на бекенді, тоді як продуктові функції реалізовувалися на клієнтському боці в iOS, Android і вебверсії.
Такий підхід сильно пришвидшив розробку та зменшив витрати часу на синхронізацію між розробниками, але призвів до того, що однакові функції були по-різному реалізовані на різних платформах, часто без належної документації. Через це у нас виникли труднощі зі змінами певної логіки. Довелося оперативно з цим розбиратися та уніфіковувати процеси на всіх платформах.
Таке трапляється, якщо є необхідність проєктувати системи в стиснуті дедлайни. Це один з найбільших викликів для розробника. Нині ми чітко розуміємо поточні бізнес-задачі й усвідомлюємо, куди будемо рухаємося впродовж трьох-п’яти років. Намагаємося закладати в архітектуру та код рішення, які будуть ефективними як зараз, так і в довгостроковій перспективі, аби уникнути «пастки поганого коду», коли нові функції додавати все складніше. Інакше процес розробки сповільнюється, додавати нові фічі стає дедалі складніше, а якість та стабільність продукту падають.
Утім, навіть за хорошого планування можуть виникати несподівані виклики — і це нормально. Так, інколи ми працюємо над експериментами, які хочемо протестувати, але не впевнені що фічу залишимо в продакшні в довгостроковій перспективі. Якщо гіпотеза показує класні результати, стає зрозуміло, що ця фіча з нами надовго. Тоді архітектуру потрібно переробити, а код — переписати.