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