Чи справді бекенд є найскладнішим типом розробки, що робити з рутиною, що не можуть поділити розробники бекенду та фронтенду та як експериментувати на проєкті, щоб не створити «зоопарк технологій»? Ігор Чорний, Back-end Developer в Boosters, розповів про найпоширеніші міфи, які існують серед спеціалістів цієї сфери.
> Міф №1. Бекенд — найскладніший тип розробки.
> Міф №2. Keep calm and blame front-end.
> Міф №4. Розробник пише код щодня.
> Міф №5. Бекенд-розробник не має вивчати фронтенд.
МІФ №1
Бекенд — найскладніший тип розробки.
Є хибна думка, що якщо розробник від початку вивчав бекенд, йому буде потім легко вивчити фронтенд. І навпаки: якщо починав із фронтенду, опанувати бекенд вже буде занадто складно, адже це ніби зовсім інший рівень розробки. Так само вважається, що зарплати в бекенді вищі.
Це неправда. По-перше, у фронтенді є чимало інструментів, що виконують функції бекенду, наприклад, Node.js. По-друге, складність того чи іншого типу розробки сильно залежить від проєкту. Наприклад, у фінтех-компаній, робота яких ґрунтується на безпеці, справді є потужні команди бекенду зі складними завданнями та високими зарплатами. Але існують проєкти, де фронтендери отримують більші офери за бекендські. Все залежить від навичок та досвіду.
У цілому фронтендер так само може вивчити технології бекенду та стати фулстек.
МІФ №2
Keep calm and blame front-end.
Взагалі стосунки між спеціалістами фронтенду та бекенду овіяні міфами та мемами. Начебто вони конфліктують, перекладають відповідальність та не розуміють один одного. Насправді більшість команд фронтенд та бекенд регулярно комунікують та працюють в синергії.
Щоправда, пошук, на чиїй стороні баг, дійсно є каменем спотикання. Як це відбувається: фронтенд та бекенд закінчують свої частини роботи та віддають тестувальнику, який знаходить баг. Чий він? Традиційно починається «пінг-понг»: це на стороні бекенду, ні це на стороні фронтенду… Але проблему треба вирішувати, баги виправляти, і чим краще влаштована комунікація між різними частинами розробки, тим швидше все налагодиться.
Це раніше були бородаті програмісти, які весь день сиділи за компʼютером, і ніхто їх не чіпав. Зараз всюди фокус на софт-скіли. Комунікабельність, відкритість та вміння працювати в команді цікавлять топменеджмент навіть більше, ніж хард-скіли.
Спілкування із продакт-менеджером, фронтендом, саппортом — це мінімум для розробника. І часто простою комунікацією можна вирішити дуже багато проблем, знайти рішення та отримати ще більший профіт.
МІФ №3
Бекенд — рутинна одноманітна робота з фреймворками.
Так, бекенд-розробники нерідко використовують фреймворки, які полегшують роботу. Але дуже часто бувають завдання, які неможливо виконати з допомогою готових рішень, просто тому, що ніхто ще такого не робив. Наприклад, таким завданням було створення алгоритму з визначення якості сну на основі методу когнітивно-поведінкової терапії для застосунку Avrora компанії Boosters.
Написати та імплементувати унікальний алгоритм та базу даних під нього, спроєктувати, як все це буде працювати на десятках, сотнях і тисячах користувачів, а також подбати про можливість щось змінювати в ньому та масштабувати надалі — це і є той випадок, коли у вакансії пишуть «ми пропонуємо цікаві нестандартні задачі».
Подібні завдання — певний виклик: спершу не уявляєш, як її виконати, а потім знаходиш рішення і отримуєш справжнє задоволення. Вони насправді допомагають не вигоряти та розвивають розробників.
Тому тип завдань для бекенду залежить від проєкту, планів та амбіцій розробника. Десь працюють із фреймворками, десь пишуть з нуля. Хтось шукає цікаве, іншим підходить рутинне. Треті набивають руку та здобувають скіли, тому їм потрібен зовсім інший тип проєкту.
МІФ №4
Розробник пише код щодня.
Принцип «жодного дня без рядка» у сучасній команді розробки звучить як утопія. Адже є ще планування завдань по Jira, Trello, грумінги (наведення порядку в задачках), мітинги, обговорення, ретроспективи, зустрічі із менеджерами. Ще бекенд часто займається саппортом — коли треба розібратися з проблемою, залізти в логи, покопатися в аналітиках, моніторингах. Це може займати від декількох годин до декількох днів. Бекенд-девелопер може ще займатися DevOps, тоді до його повсякденних завдань додається адміністрування, проєктування, тестування. Якщо ж перед розробником стоїть складне завдання, йому потрібен час, щоб обдумати, у який спосіб це можна спроєктувати.
МІФ №5
Бекенд-розробник не має вивчати фронтенд.
Раніше не було жорсткого розділення на фронтенд та бекенд. Тоді були просто девелопери: «знаєш PHP — молодець, зроби нам ще адмінку». Згодом задачі почали ускладнюватися, зʼявилися окремі напрями розробки — бекенд і фронтенд.
Часом бекенд-розробники, які щойно закінчили курси, не бачать повного горизонту завдань, з якими доведеться стикатися, та відмовляються виконувати дрібні завдання з фронтенду: «зверстати вам сторінку з Privacy Policy? Камон, я ж бекендщик». В їхньому розумінні, це якась інша спеціалізація, не варта уваги. Вони бояться розпилятися та прагнуть розвиватися тільки у своїй ніші.
У сфері бекенду є майже бездонні джерела інформації, статей, підходів, які можна вивчати у вільний час та професійно зростати. Дійшовши до сеньойра, можна заглиблюватися в архітектуру, стати техлідом або менеджером. Але як би бекенд-розробник не заперечував цього на початку карʼєри, з роками виявиться, що він все ж таки знає фронтенд.
Знання деяких рішень та фреймворків з фронтенду може справді полегшити життя розробнику. Десять років тому Javascript був ніби темним виром — в ньому було страшно, незручно, панував хаос та шостий Internet Explorer. Але зараз є безліч фреймворків, вартих уваги бекендера — Vue.js, React, Node.js, адже вони зручні та стабільні.
Загалом розробник має навчатися безперервно, і для цього є безліч можливостей.
МІФ №6
Проєкти обмежують простір для експериментів.
Якщо бекенд-розробник багато років працює в одній компанії, це зовсім не означає, що всі ці роки він використовує обмежений набір фреймворків та технологій, а єдиний простір для експериментів — пет-проєкти. В компаніях з екосистеми Genesis менеджмент не втручається в розробку, а CTO не обмежує команду у підходах. Якщо розробник прийшов не проєкт не вчора, а добре себе зарекомендував, потестив і перевірив технологію та пояснив її переваги, з великою ймовірністю йому дадуть зелене світло. Якщо, наприклад, перехід на Golang покращить продукт — чому б ні?
З іншого боку, буває, що людина запустила сервіс з MongoDB базою даних і за кілька місяців звільнилася, а в команді дивляться продакшн-конфігурацію, та ніхто не знає, як отримати до неї доступ. Усіма новими технологіями має хтось опікуватись та відповідати за них. Це як підтримувати великий автопарк.
У великих проєктах зазвичай трапляється зоопарк технологій, сервісів, серверів, які тягнуть за собою великі витрати на інфраструктуру. Але якщо в команді є адекватний менеджмент, час та ресурси на реалізацію і підтримку — це нормально.