Подальший розвиток фронтенд-розробника: що потрібно знати, крім фронтенду

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Ті, хто лише готується стати фронтенд-розробником чи вже є Junior або Middle-фахівцем, часто починають вдаватися в питання, що робити далі, що вчити та як дорости до Senior-позиції з поточного рівня. Перехід на новий рівень не обмежується лише фундаментальним знанням JavaScript/TypeScript або вивченням нового фреймворку, а передбачає глобальнішу супервізію процесу, а отже нові завдання, більше комунікації, вміння розв’язувати складніші задачі. Велику роль відіграє саме «зростання в ширину» — вивчення екосистеми, в якій ви працюєте, знайомство із засобами автоматизації та занурення в суміжні технології.

В цьому матеріалі я розповім, що, на мою думку, потрібно кожному фронтенд-розробнику, який прагне до нових кар’єрних висот, а також поділюся матеріалами, що допомогли мені.

В коментарях ви також можете написати, які матеріали, інструменти та практики ви використовуєте для свого кар’єрного зростання — буду радий почитати про ваш досвід.

CI/CD, GitHub/GitLab actions, etc

На всіх проєктах, де я працював і продовжую, були пайплайни для автоматизації різних процесів: від лінтингу коду та тестів до деплою на різні оточення та релізів. Автоматизовані процеси стали невіддільною частиною розробки та певною гарантією, що код, який йде в продакшн, працюватиме як треба. В багатьох проєктах налаштуванням CI/CD і пайплайнів займається DevOps або System Engineer, але зі мною траплялися такі ситуації, коли структура проєкту змінилася і потрібно переробити частину процесів. Бувало і так, що девопси налаштували всю інфраструктуру, а розробники самі мають на її основі побудувати пайплайни під потрібний репозиторій. Будь-який досвідчений інженер має розбиратися в побудові пайплайнів на проєкті та вміти адаптувати їх під свої задачі — зазвичай під час сетапу нових репозиторіїв.

Більше про пайплайни можна прочитати тут:

Cloud-інфраструктура (Amazon Web Services, Google Cloud Platform, Azure)

Час минає, застосунки стають складнішими, тоді як все більше компаній хочуть зробити інфраструктуру простішою, але масштабованою, із додатковими сервісами для зберігання паролів, оброблення подій, сповіщень тощо. Компанії як Google, Amazon і Microsoft подбали про це і створили свої платформи для підтримки застосунків будь-якого типу.

І кожен досвідчений фронтенд-розробник має вміти базово працювати з cloud-based платформами та розуміти, як працює внутрішня частина його проєкту в інтеграції з cloud-провайдерами. Вчити все не обов’язково. Можна взяти за основу, наприклад. AWS, а в решті платформ все буде більш-менш схожим. А щоб попрактикуватися, можна створити безкоштовний акаунт і написати невеликий full-stack застосунок, інтегрувавши в нього якомога більше сервісів від певного cloud-провайдера.

Цей досвід допоможе розібратися, як працюють великі застосунки зсередини, допоможе краще зрозуміти функціонування свого проєкту і, вірогідно, змусить замислитись над можливим поліпшенням наявних застосунків. Картина взаємодії сервера, клієнта, різноманітних додаткових сервісів буде чіткішою, а це — один із перших кроків до розуміння та побудови архітектури.

P. S. Для розробників Google, Amazon і Microsoft надають сертифікації різного рівня, які ви, можливо, захочете пройти. Я сам вивчав і сертифікувався за AWS, тож поділюся корисними матеріалами по ньому:

Англійська мова

Все так. Імовірно, ви багато разів чули про важливість англійської мови, та, можливо, добре нею володієте. Але це дійсно необхідно, особливо зі зростанням рівня компетенції, адже тоді в розробника збільшується відповідальність і дедалі більше доводиться розв’язувати високорівневі задачі. Відповідно, комунікації з бізнесом і командами стає більше і професійне володіння англійською є життєво необхідним.

Найефективнішим способом буде відвідування Speaking-клубів, можливо навіть за підтримки вашої компанії, чи індивідуальні заняття з native-спікером. Чим вільнішою ставала моя англійська, тим насиченішим ставало моє розробницьке життя.

Мої поради, як покращити рівень англійської мови:

  • Споживайте якомога більше англомовного контенту. Так ви не тільки підтримаєте рівень мови, але й відкриєте багато цікавих і корисних матеріалів
  • Ходіть у Speaking-clubs. У містах, особливо великих, їх багато офлайн і онлайн. І ваша компанія, імовірно, зможе надати компенсацію уроків англійської.
  • За бажання й можливості здайте IELTS. Я сам зараз до нього готуюся і за останні місяці сильно розширив свій словниковий запас, а також підтягнув граматику.

Опанувати патерни проєктування

Патерни проєктування — це розв’язання поширених проблем під час розробки програмного забезпечення. Вміння їх застосовувати дозволить заощадити час, використовуючи відомі практики, стандартизувати код, підвищити масштабованість і якість розробленого продукту. Дуже рекомендую ресурс для вивчення патернів на кшталт цього, де можна знайти опис і реалізацію патернів майже будь-якою популярною мовою програмування.

Познайомившись із патернами, я дійсно почав писати код краще, а найголовніше — робити його більш масштабованим і не потрапляти в ситуацію, коли команді треба переписати половину програми, щоб імплементувати певну фічу 🙃. Продовжую їх вивчати та періодично повторювати.

Матеріали, що стануть в пригоді:

Архітектура фронтенд-застосунків

З підвищенням на посаді та напрацюванням досвіду фронтенд-розробнику можуть доручити задачу по сетапу чи підтримці групи репозиторіїв, що відносяться до однієї чи декількох частин проєкту.

Досвідчений фронтенд-розробник має розуміти, за якими правилами має будуватися фронтенд-застосунок, щоб він максимально задовольняв критеріям як:

  • легке розширення функціонала програми;
  • зручне внесення змін до наявного функціонала;
  • уніфікована структура застосунку;
  • швидкий onboarding нових розробників і тестувальників на проєкт;
  • зрозумілий логічно розділений код
  • під час написання нової функціональності розробник одразу бачить, де її помістити в структурі файлів.

Розглянувши декілька підходів, як-то Domain-Driven Design, Feature Sliced Design та інших, ви матимете варіативність вибору при підтримці та сетапі конкретного проєкту, що, безумовно, відобразиться на якості та швидкості роботи та покаже вас як сильного фахівця.

Корисні матеріали:

Навички ментора та інтерв’юера

Хто як не впевнений мідл і сеньйор передасть найкращі практики написання та організації коду застосунків джуніорам і стажерам. Правильне код-рев’ю, обговорення завдань, проблем і їхніх рішень допоможуть колегам швидше розв’язувати поставлені завдання та підвищать експертизу команди. Щобільше, можна передати молодшим колегам найкращі практики і таким чином зробити внесок в ІТ-спільноту, зробивши її більш усвідомленою та професійною.

Зі зростанням сеньйоріті фахівець частіше може долучатися до різних ініціатив в компанії. Одна з них — це підбір нових спеціалістів. Досвідчений розробник знає, які питання поставити для виділення сильних і слабких сторін кандидата, і разом з цим може організувати процес для швидшого онбордингу нового члена команди в проєкт.

Декілька порад від мене:

  • Станьте ментором для когось із вашої компанії. Вивчіть, до чого людина прагне, постарайтеся їй допомогти та стежте за результатом.
  • Поступово починайте брати участь в інтерв’ю. Можете попросити про це рекрутерів у вашій компанії, попросіть поради у тих, хто вже проводив співбесіди. Вони підкажуть головні моменти, на які потрібно звернути увагу

Висновок

Я перерахував всі основні навички, які розвиваю в собі як фронтенд-розробник. Насамкінець хотів би підкреслити, що все вищесказане варто розвивати безпосередньо із професійними навичками. Так, досвідчений frontend-розробник має знати HTML, CSS, JS, що таке доступність, оптимізація тощо, стежити за новинами своєї галузі та впроваджувати нові практики в життя та роботу.

👍ПодобаєтьсяСподобалось41
До обраногоВ обраному33
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я б додав знання фігми. Часто дизайнери не розуміють як робити «developer-friendly» дизайн, і потрібно на ходу його самому правити, або ж розкидати layers для адекватного експорту зображень.

4 Design Patterns You Should Know for Web Development: Observer, Singleton, Strategy, and Decorator

😂😂😂

Дякую Олексій за статтю — дуже корисна

Як бекендер, вважаю фронт дуже складною цариною, ще з часiв Java Swing. Потiм схиляли педалити на Джаваскриптi, типу, що ти, цеж теж Дава. Було таке рокiв 10 тому, аж гай шумiв. Потiм як розплодилося 125 ангуларiв, то начебто, припинилась така практика стосовно джавiстiв.
Фронтенд менi не зайшов, бо там крiм «працює», є ще «нравиця-ненравиця», «поддай гламуру», «перероби якось по-iншому, сам не знаю як, але не так»

це все вирішується наявністю дизайнера в команді, якому і будуть казати «нравиця-ненравиця». Фразу «зроби так, щоб було гарно» чув лише в одному треш стартапі, років 6 тому

Редакс це біль. Ніяк не можу пересадити команду на щось більше нове

MobX, другая философия... Рекомендую.

MobX

Пішов з фроненду не через гламур, а тошо там повна вакханалія як з точки зору арххітектури, так і з фреемворків. Наприклад лише зараз фронтам дойшло що бізнеслогіку краще окремим прошарком робити і крити юніт тестами, до цього ці клоуни пхали її в модельки або просто гамузом зі вьюшкою мішали. Таке одразу викликало відразу після бекенду.

Нмп, для девелопера, гуляти мiж беком та фронтом — то таке собi, бо вони ну дуже рiзнi за техн. стеком, життєвим циклом розробки.

Та був час коли мене проперло від джс, зовсім на короткий час, десь рік, це були часи коли тільки переходили від jQuery на перші версії Angular та ReactЮ SPA аплікушки були щось свіжим та цікавим, з часом повернувся у бєк і більше не хочу у фронт знову, зараз бєк+клауди+девопс.

Доречі саме отака велика різниця стеків насправді корисна просто для розвитку.

Згоден, Frontend — це не про стабiльнiсть)

Для розвитку, звiсно, треба все потицяти, щоб не помилитися з вибором основного напрямку.

Як бекендер який трохи на фронт лазить — підтримую і з повагою ставлюся до колег фронтендерів.
Другий абзац це не про технології, це про дизайн, менеджмент, відносини з замовником.

Підписатись на коментарі