что такое web разработка
Как стать веб-разработчиком с нуля, почему это актуально и что нужно знать
Профессия веб-разработчика жива, пока живы сайты. Разберёмся, как прийти в неё и что нужно знать новичку. От ситуации на рынке до обучающих ресурсов.
Текст подготовлен на основе вебинара «Как стать веб-разработчиком с нуля за три месяца» с участием Михаила Овчинникова из компании Badoo.
Для полного погружения в профессию у Skillbox есть курс «Веб-разработчик», где теория становится знаниями, практика — навыками, а работа — оплачиваемым призванием.
Ведущий инженер-программист в Badoo Development LLC, специалист по разработке высоконагруженных веб-сервисов.
Ситуация на рынке
Рассматривая общую картину рынка, можно выделить наиболее востребованные направления в IT-сфере:
Почему стоит идти в веб
1. Веб-разработка — это интересно
Стоит изучить одну технологию либо фреймворк и начать с ними работать, как через два-три месяца на рынке появится что-то совершенно новое и все начнут использовать именно это. С вебом не соскучитесь.
2. Веб-разработка — это творчество
Веб-разработка постоянно пополняется молодыми специалистами с новыми идеями, а сама сфера — новыми инструментами, возможностями и сервисами.
3. Веб-разработка — это развитие
Senior-программистов с десятью годами стажа можно встретить довольно редко: либо из них вырастают управленцы, либо они учатся новому. Бурный рост профессии формирует широкое информационное поле и крепкое сообщество.
Поэтому, если вы молоды, полны энергии, имеете чувство вкуса, да ещё и с любовью относитесь к программированию, веб-разработка — для вас.
Сколько зарабатывает веб-разработчик
Изучив сайты поиска работы, мы увидим диапазон зарплат веб-разработчиков:
Многое зависит от страны, региона, выбранного языка и компании, предлагающей вакансию.
Чем занимается веб-разработчик и что нужно для того, чтобы им стать
Сегодня программирование востребовано как никогда. Информационные технологии развиваются с колоссальной скоростью, и компаниям постоянно требуются новые специалисты. Одна из «древнейших» IT-профессий – веб-разработчик. Последние годы проектирование онлайн-проектов стало самым востребованным направлением среди программирования. Фриланс, создание сайтов и IT-индустрия в целом чаще всего ассоциируются с написанием строчек кода, однако веб-разработка – вовсе не однообразный набор текста, а сложный и интересный процесс, в котором участвуют специалисты разных уровней.
Тут и возникают логичные вопросы: кто такой веб-разработчик? Насколько перспективна профессия? Не поздно ли еще стать одним из них?
С чего все начиналось
Изначально веб-сайты оставляли желать лучшего: интерфейс невзрачен, инструментов для работы по пальцам пересчитать, а языки программирования плохо адаптированы под сетевой кодинг. Однако разработчики понимали: за интернетом будущее, и сейчас именно они в ответе за интеграцию технологий в массовую культуру.
В девяностые специалисты начали активно развивать веб-программирование. Появились JavaScript, Flash и каскадная разметка страниц (CSS), а полноценный браузер Mosaic показал, как с ними работать. Несмотря на большой прогресс, основной код писался на разных языках: C, C++, Perl. Несложно представить, какая получалась неразбериха из-за отсутствия единого синтаксиса.
Но вскоре появился PHP. Этот язык был нацелен на серверную часть разработки и помогал превращать статичные HTML-страницы в динамические. Теперь пользователь видел не просто текст, а привлекательные скрипты и красивые анимации без долгих загрузок.
Из перспективной технологии сайтостроение перешло в мощный продающий инструмент. Крупные компании сразу заметили потенциал: собственный ресурс добавлял статусности, популярности и собирал людей из разных уголков страны. Личный сайт хотели многие компании мира, и веб-разработка стала полноценной профессией с достойной оплатой труда.
Кто такой современный веб-разработчик
Суть не изменилась: веб-разработчик проектирует и создает интернет-ресурсы. Однако сам процесс претерпел большие изменения. Теперь исполнителей делят на три категории:
Процесс веб-разработки
Прошло много лет с момента появления фундаментальных истин веб-программирования. Теперь PHP постепенно уходит в забвение, уступая место Java, JavaScript и Python. Браузеры имеют единые стандарты, и разработка больше не превращается в сущий кошмар.
Появились контейнерные технологии Kubernetes, на передовую вышел Linux с огромной библиотекой открытого программного обеспечения. Базы данных превратились в полноценные хранилища быстрого доступа, а скрипты преобразовались в сложные, но красивые интерактивные элементы.
Появилось множество инструментов и сред для написания кода, а проводить тестирование стало намного проще. И профессия не стоит на месте: по ходу работы специалисты осваивают новые языки (массовое помешательство на Go), оптимизируют процессы и учатся универсализму. Означает ли это, что сегодня стать веб-разработчиком проще, чем десять лет назад? И да, и нет.
Кто может стать веб-программистом
Веб-направления – самые востребованные отрасли программирования. По данным на 2020 год, первые три позиции занимают backend, fullstack и frontend.
Веб-разработчик любого уровня всегда сможет найти работу. Даже новичок не останется без заказов и как минимум сможет успешно фрилансить. Однако программирование требует определенных навыков. Например, для освоения frontend-разработки нужно:
Познать backend гораздо сложнее. Каждое предприятие использует определенный язык, и разработчик должен его досконально понимать. Поэтому backend не ограничивается JavaScript – он изучает PHP, Java, C#, Python, Ruby или Perl. Под каждый язык создаются фреймворки, и специалист обязан разбираться в них хотя бы на базовом уровне.
Также требуется понимание базы данных Oracle, MySQL или любой другой, а также контейнерных технологий (Kubernetes или Docker). И самое важное: придется учить английский, иначе вы не сможете читать актуальные мануалы и сотрудничать с открытым сообществом.
Процесс обучения веб-программированию требует желания, усидчивости и определенных стартовых навыков. Молодым людям, с юного возраста осваивающим ПО или популярный язык (Паскаль, Delphi), будет проще познать сайтостроение. Однако научиться веб-разработке может каждый – в интернете множество платных и бесплатных курсов, а при знании английского доступны оригинальные туториалы.
Заключение
Веб-разработчик – самая востребованная профессия в сфере программирования. Направление активно развивается, а специалисты зарабатывают хорошие деньги. С точки зрения доступной информации сейчас лучшее время для освоения веб-программирования, поэтому не бойтесь JavaScript или сложных английских терминов – результат вас приятно удивит!
Веб-разработчик Frontend и Backend: чем занимаются и как ими стать
Рассказываем, какие навыки нужно приобрести, чтобы стать веб-разработчиком, создавать и обслуживать сайты.
У frontend- и backend-разработчиков в вебе разные сферы ответственности, но в чём-то они пересекаются. Начинающие программисты не всегда знают, какая область разработки им интереснее, а может, и вовсе не хотят выбирать.
Чтобы вы чётко понимали, каким путём идти, Skillbox проводит курс «Профессия веб-разработчик». За год практики и общения с преподавателями вполне реально определить будущее и начать двигаться к своим целям. Сейчас же мы рассмотрим основные моменты направлений веб-разработки.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Чем занимаются
веб-разработчики
Они создают сайты, сервисы и веб-приложения — все те, которыми мы пользуемся ежедневно. Специалисты работают над видимой и серверной частями, чтобы мы могли полистать ленту с утра, отправить деньги другу, выучить язык или просто развлечься.
То есть от разработчиков напрямую зависит, как бизнес взаимодействует с пользователем. Результат их работы влияет на реальный мир, повседневные дела, развитие и появление новых технологий. И, конечно, на успех самого бизнеса.
Какие бывают
веб-разработчики
Давайте посмотрим, что представляет из себя веб, какие бывают разработчики и за что они отвечают.
Backend
Когда вы переходите по ссылке, браузер делает запрос на сервер, где расположен этот сайт. Сервер находит нужный файл и передаёт его на компьютер пользователя, а браузер интерпретирует команды в визуальные элементы, чтобы мы могли видеть сайты такими, какие они есть.
Иногда серверу нужно сначала скомпилировать файл. То есть какая-нибудь страница запускается на сервере, выполняет команды, и только потом данные передаются пользователю.
Это называется серверной частью, или Backend. Именно в ней обрабатываются данные, которые пользователь вводит в форму; здесь же происходят взаимодействие с базой данных, загрузка файлов и так далее.
Backend-разработчики пишут сайты на PHP, Ruby, Python, ASP.NET и других языках, чтобы мы могли:
Без серверной части сайты представляют собой пустую, пусть и красочную оболочку.
Разработчики также занимаются защитой и производительностью. Они следят, чтобы проект был защищён от нападений хакеров, а большое количество одновременно находящихся на сайте пользователей не влияло на скорость работы.
Frontend
Frontend — это то, что мы видим: текст, картинки, кнопки, формы и так далее.
Frontend-разработчик использует HTML, CSS и JavaScript, чтобы дать пользователю возможность взаимодействовать с сайтом:
Серверная часть будет бессмысленной, если она не будет нигде отображаться.
Frontend-разработчики контролируют визуальную часть сайта, чтобы он корректно отображался на всех устройствах, шрифты не плясали, а изображения не нагружали страницу.
Fullstack
Таких специалистов ещё называют разработчиками полного цикла. Они совмещают навыки работы с Frontend и Backend, чтобы создавать сайты. Они знают обо всём, хоть и не так узко и глубоко.
Как стать
веб-разработчиком
Основы веба
Теперь поговорим о том, как же стать разработчиком. Для начала нужно выучить HTML — язык гипертекстовой разметки. Это что-то вроде скелета, на который потом будут крепиться мышцы и кожа.
Чтобы красиво подавать страницы пользователям, понадобится CSS — каскадная таблица стилей. Это отдельный файл с параметрами элементов. Например, информация о том, что все ссылки должны быть чёрными, а картинки — отбрасывать тень.
Разобраться в этих языках несложно. Чтобы ускорить процесс, скачайте в интернете PSD-макеты сайтов и попробуйте собрать их на HTML и CSS.
Движение и реакции
Дальше вам понадобится JavaScript — он заставит скелет сайта двигаться и реагировать на действия пользователя. Например, выводить всплывающее окно, если пользователь нажал на кнопку.
Реализовать на JavaScript можно что угодно, но работодатели предпочитают тех, кто владеет фреймворками — специальными библиотеками, которые упрощают работу. Любой код легко сократить, если подключить фреймворк, поэтому постарайтесь выучить основные.
Начинать лучше с jQuery — он простой, но богатый. Дальше изучайте и другие, которые понадобятся для выполнения новых задач.
Выбираем направление
Если вам интересно заниматься именно внешним видом, то продолжайте идти в направлении Frontend. Даже HTML требует времени, чтобы полностью им овладеть. Не говоря уже о CSS, в котором понадобится овладеть позиционированием, наследованием, адаптивной вёрсткой и многим другим.
Ну, а если уже всё это освоили, но хотите работать ещё и с серверной частью, то учите PHP — он достаточно простой, поэтому подойдёт новичкам, и в то же время очень мощный. Он помогает реализовать практически всё.
Изучать PHP достаточно долго, потому что он предоставляет огромные возможности:
Дальше обратите внимание на любой язык запросов — MySQL, PostgreSQL, MSSQL и им подобные. Они созданы, чтобы получать и вносить информацию в базу данных. Это оптимизирует работу сайта, особенно если на нём хранится большое количество статей, карточек товаров, учётных записей и так далее.
Писать для веба можно на многих языках, поэтому не зацикливайтесь на одном, если он вас не цепляет. Но основы PHP лучше изучить и frontend-разработчикам, чтобы разбираться в нём и понимать, какой код и куда нужно вставить.
Если вы совместите все эти знания, то станете разработчиком полного цикла — будете создавать как визуальную, так и серверную часть. Так ваш код будет максимально согласован между собой, чего не всегда удаётся добиться, когда работает команда.
Зарплаты
Если рассуждать логически, то fullstack-разработчики должны получать более высокую зарплату, потому что заменяют нескольких программистов. Но спрос на них значительно ниже. Работодатели предпочитают нанимать узких специалистов, которые решают конкретные проблемы.
Современная веб-разработка: выбери себе приключение
Привет. Недавно я делал доклад для студентов о том, какие шишки можно набить, занимаясь современной веб-разработкой. Как связаны друг с другом различные решения, которые мы принимаем в процессе разработки, как выбор технологий влияет на размер команды, как размер команды влияет на подходы к тестированию, как подходы к тестированию связаны со структурой всей компании.
Получилось что-то вроде квеста с распределенным выбором: от того, какой язык программирования выбрать и до того, кого лучше нанимать в команду, которая сделает самый полезный продукт ever. Предлагаю вам почитать этот пост, выбрать свои варианты, дополнить квест и обсудить то, что наболело.
upd — немного дополнил текст до ката.
От идеи до прототипа
Предположим, что я и мой друг Валерка решили сделать стартап. Uber for X, или там еще что-нибудь в таком духе. Собрались в баре, обсудили эту идею, клёвая тема. Надо сделать. Три месяца не спали, не ели, не выходили из дома. Разрабатывали. Запустили и поняли, что это никому не нужно.
Печаль. Попробуем еще раз. На этот раз мы изучили рынок, посмотрели, какие потребности у пользователей, какие проблемы. Мы сделали какой-то прототип совсем на коленке, быстро и бесплатно за два вечера. Прототип взлетел. Круто, идем дальше.
Выбираем технологии
Теперь мы можем брать и делать из прототипа большое приложение, развивать его. Но для этого надо более серьезно подойти к выбору технологий, которые мы будем использовать.
По порядку. На каком языке писать? Можно взять модный функциональный: Haskell, Erlang, Lisp (очень модный среди дедушек старше 70). Либо очередного убийцу JS, который очень клевый, компилируется в JS, имеет все нужные фичи. Но скорее всего, нам некого будет нанимать через год, потому что очередной убийца JS не взлетит, и придется переучиваться заново или переписывать проект.
Попытка номер два. Можно взять что-нибудь проверенное временем. Например, PHP. Это неплохой язык, его модно иногда критиковать, у него есть свои минусы, но на нем легко делать бизнес-логику, он достаточно быстрый, неплохо масштабируется, можно нанять людей когда угодно и где угодно. Но он не очень производительный. Поэтому нам нужно либо много железа, либо писать свой компилятор, как сделали Facebook или ВК.
Еще варианты? Можно взять Perl, но тогда будет некого нанимать ещё вчера. Ещё?
Java. Java — норм. Как язык не очень, на мой субъективный взгляд, но JVM — отличная виртуальная машина, все ок, быстро работает, но железа все равно нужно много. А ещё пока мы на Java писали абстрактный билдер фабрики стратегий вместо того, чтобы делать фичи, пользователи ушли к конкурентам.
Ладно, у нас есть еще Python. В принципе, у него всё ок. Но мы запускаем приложение на Python, оно использует одно ядро из 56, в остальном… все ок. Либо можно взять что-то современное: Go, Rust, еще что-то. Но они слишком низкоуровневые, и мы просто долго делаем фичи… Какой-нибудь язык нам всё равно придется выбрать. Пусть в итоге это будет JS, сойдет.
База данных
База. JS без документной базы — деньги на ветер. У документных баз есть свои плюсы. Они позволяют нам быстро разрабатывать прототипы, не париться насчет схемы, колбасить данные туда-сюда. Плюсов много, минус один: каша из данных. Когда коллекций у нас становится десять, двадцать или сорок вместо трёх, когда мы без отсутствия схем пытаемся склеить из них что-то хорошее и удобоваримое, становится это делать все сложнее. Опять долго делаем фичи.
Ок, давайте возьмем реляционную базу. MySQL, PostgreSQL, или Oracle, если денег хватит. С реляционными базами можно однажды прийти на работу и обнаружить себя в аду из транзакций и хранимок. Это не обязательно произойдёт с нашим проектом. Но если произойдет, то эти хитросплетения логики будет невозможно тестировать. А ещё если вдруг мы достигнем вертикального предела нашего большого золотого сервера, на котором мы хостим базу, потом будет довольно сложно их разделять. Долго делаем фичи.
Ладно. Базу взяли какую-нибудь, бахнули перед ней ORM, чтобы проще было с одного SQL на другой переезжать. Когда-нибудь (spoiler: никогда).
Архитектура
Какую взять архитектуру? Ребята на Хабре пишут, что микросервисы – это клёво. Олег Бунин говорит: «берите микросервисы».
Если начать с микросервисов, то с восьмидесятипроцентной вероятностью границы у них будут неправильные, потому что не до конца продумали доменную модель и плохо поняли, где надо резать, а где не надо. Плюс все берут микросервисы, деплоят их пачками по всему своему кластеру, и через месяц возникает вопрос: «а как это всё теперь тестировать?». Сервисы уже работают в продакшене, а мы их не тестируем. Используя привычные методологии (пирамида тестирования, ручные интеграционные тесты, end-to-end тесты), тестировать микросервисы сложно. Поэтому мы долго делаем фичи.
Ок, тогда давайте бахнем монолит. Это самая правильная идея для стартапа. Очень долго можно жить с отличным монолитом и не иметь проблем. Но если мы решим сильно расширить команду, то надо быть осторожнее. Монолит нормально масштабируется, пока разработчиков 20, 30, 50. Дальше скорость доставки фич падает экспоненциально, а мы теряем пользователей.
Где запускать проект?
Это всё надо где-то запускать. 2018 год, самый логичный вариант сделать это в облаке. Запустишь не в облаке — пацаны засмеют. Но, во-первых, есть федеральный закон 152, значительно ограничивающий выбор облачных провайдеров, у которых можно хоститься. Во-вторых, очень легко приватный ключ от своего аккаунта на Amazon случайно закоммитить в Github, и кто-то обязательно придёт и потратит все ваши деньги. А если этого не произойдёт, то в какой-то момент вас разорят облачные тарифы.
Можно арендовать дата-центр. Может, это не так ресурсоэффективно изначально, но в долгосрочной перспективе, вероятно, обойдётся дешевле, чем хоститься в облаке. Но тут нужны люди, которые это будут поддерживать. По моему опыту, те, кто это любят и умеют делать, не очень любят общаться со всеми остальными, поэтому они организуются в отдел. А отдел – это сепаратизм. Я имею в виду то, что внутри команды админов будет легче обмениваться опытом, но в будущем это может работать не очень хорошо. Будут вопросы с приоритезацией задач от других коллег, с синхронизацией. Другие специалисты не будут знать, что происходит внутри отдела, который поддерживает наш дата-центр.
В общем, сепаратизм нам не подходит. Логично переходим к вопросу набора команды.
Команда
Разработка
Допустим, мы разобрались с языками, базами и тем, где хостить проект. Настало время набирать команду. Можно взять несколько очень крутых ребят, которые все проблемы решат: стократные разработчики, бэкенд-ниндзи, вы понимаете. Возможно, это прокатит. Но на деле вероятно, что приглашённые звёзды будут:
В итоге… да-да, долго делаем фичи. Еще вариант — взять обычных девчонок и ребят, которые просто будут писать код, делать фичи нормально. Но если взять много не очень опытных разработчиков с разным бэкграундом, они могут писать код в разном стиле, делать штуки по-разному, и при достаточном размере команды всем будет тесно, все будут у друг друга фигурные скобочки переставлять в пуллреквестах. Это не очень эффективно. Как это можно решить? Начальник может читать весь код. Я могу читать все пуллреквесты, а мой друг и ко-фаундер Валерка потом второй раз будет перечитывать (на всякий случай, мало ли). Понятно, это не масштабируется и все медленно делают фичи.
Более правильный вариант — определить кодстайл для компании. Для многих языков он уже есть, и можно его просто соблюдать. Либо если кому-то очень хочется, можно взять готовый и подтюнить немного, и потом смотреть на пуллреквестах и говорить, что здесь фигурная скобочка не там стоит, по кодстайлу должна стоять там. С таким аргументом уже не поспоришь, но на деле это не сильно лучше предыдущего варианта, все равно мы медленно делаем фичи. Правильный вариант для всех современных языков — проверять это автоматически.
Ок. Набрали разработчиков, фигачим код. Но мы начали релизить фичи в продакшн, и нам надо как-то убеждаться, что мы без багов их катим, что у нас ничего не падает.
Quality Assurance
Можно сказать, что QA-специалисты нам не нужны. Многие так делают, это иногда работает. Но не все разработчики любят писать тесты. Их можно понять. И стоит их лучше мотивировать, чтобы тесты все-таки писали, но реальность жестока: unit-тесты ловят далеко не все баги. А если какой-то разработчик не любит писать тесты и все-таки начал их писать, то скорее всего это будут unit-тесты.
Плюс еще есть подходы, когда ты минимизируешь mean time between failures вместо mean time to recover. Mean time between failures — это когда QA специалист говорит: «не будем релизить, у меня чутье плохое, баги будут, давайте через две недели выкатим». А mean time to recover — это когда вы катите что-нибудь, сразу видите на метриках, что что-то сломалось, и через две минуты все откатили, пофиксили и все ок. Но чтобы можно было проект через две минуты откатить, надо всё покрыть нормальными метриками, а это не всегда тривиально. А если метрики в плачевном состоянии, и мы выкатим плохой релиз, мы можем узнать об этом после того, как все пользователи уйдут от нас к конкурентам.
Другой вариант: всё-таки сделать отдел QA. Вы помните: отдел — это не очень хорошо, это сепаратизм, это нам не подходит. Сепаратизм можно разрулить с помощью кроссфункциональных команд. Да, они решают проблему того, что у нас админ сидит отдельно, тестировщики отдельно.
Но создают другие проблемы. Так как разработчики, тестировщики и все прочие члены кроссфункциональных команд начинают больше общаться внутри своих команд и решать предыдущие проблемы, они меньше общаются с их коллегами по функции: другими бэкендерами и тестировщиками, они начинают переизобретать велосипеды, делать параллельно одни и те же вещи, наступает изоляция между командами. Шило на мыло: был один сепаратизм, стал другой.
Как это разрулить? Общаться с коллегами в кружках по интересам. Где-то это называют гильдиями, где-то — коммьюнити. Если мы масштабируем команду кроссфункциональными командами, чтобы они не замыкались в себе, мы просто организуем кружок любителей бэкенда, функциональных языков, секьюрити…
Итоги
На самом деле, не всё так плохо. Из любой ситуации можно найти выход, найти решение. Может быть, не идеальное, но наиболее подходящее в данной ситуации с минимумом проблем. Всегда возможен компромисс.
А ещё — всё это интересно. Интересно решать проблемы, которые уже кто-то решал, новые проблемы еще интереснее решать. Интересно делиться знаниями.