Про айс ти

Автор Бакута Андрей

Я подумал, что описать все роли в IT именно на сегодняшний день, может быть тяжело, так как областей много, специализаций в каждой области еще больше, при этом они могут смешиваться и иметь свои особенности в различных компаниях. Поэтому зайду немного издалека, со времени когда все было намного проще и оттуда попытаюсь рассказать как и почему происходило деление и возникновение более узких специализаций. Рассказывать буду на примере веба по очевидным причинам. Я не знаю насколько подробно нужно расписывать термины, так что могу определять какие-то уже тебе известные, при этом просто упоминать, не углубляясь, другие, которые как раз требуют определений. Иногда понятия будут даваться для примера, то есть не нужно прям углубляться чтобы понять мысль или идею. В любом случае ChatGPT — в помощь.

В основе всего веба лежит HTML и протоколы его передачи. Протоколы нам пока не особо интересны, а вот хтмл — да. Ну и может еще клиент-серверная архитектура. Звучит громко и страшно, но по факту все просто: клиентом обычно выступает браузер, а сервером — компьютер в датацентре провайдера или даже машина разработчика на этапе создания и изменения сайта. Возвращаюсь к хтмл. Изначально для его создания, то есть для создания сайта, который отдает хтмл страницы, хватало одного разработчика. Сам сайт обычно состоял из базы данных и PHP скрипта, который как раз напоминал хтмл, но с вкраплениями кода, который обращался к базе, доставал какие-то данные и встраивал их в страницу. По факту на выходе сервер отдавал текст, который состоял из разметки и встроенных в эту разметку данных. Данные могли быть любыми (профиль пользователя, история заказов, описание товаров и т. д.). Да, еще хочу сказать пару слов про delpoy. Deploy — это по сути процесс, при котором сайт, который изначально работал только на машине разработчика, появляется на компьютере дата центра. Так вот он был максимально простым. Обычно весь сайт как есть заливался по SFTP протоколу на машину твоего хостинг провайдера вручную при каждом изменении. По факту поменять что-то на сайте можно было двумя способами: или изменить/добавить данные в базе, или же поменять разметку или код в PHP скрипте и перезалить сайт на хостинг. Повторюсь, что на данном историческом этапе хватало одного человека. Название должности может варьироваться, но наверное наиболее часто встречающаяся это Web Developer.

Со временем дизайны сайтов стали усложнятся. Занимался этим собственно Web Designer. Дизайны начали делать заранее, до этапа разработки. Так же это было обосновано тем, что их гораздо проще менять чем код. Соответственно цикл выглядил примерно так: делается дизайн, показывается заказчику, тот предлагает правки, дизайнер их применяет, снова согласовывает, и уже финальный дизайн идет в работу. Ну и вопрос что за работа добавилась к описанной выше. В вебе дизайн страницы обычно реализуется с помощью языка стилей CSS. Если быстро объяснять — в HTML буква М отвечает за Markup, то есть за разметку. Для разметки ты можешь использовать специальные констукции, которые будут говорить что это просто абзац текста, это кнопка, это ссылка, это текстовое поле и т. д. Также разные куски разметки ты можешь помечать разными именами (задавать class и/или id). И дальше, имея имена элементов, заданные тобой, классы и их комбинации, ты можешь задавать различные стили (цвета и размеры текста, шрифты, бекграунды, позднее даже эффекты анимации) с помощью css. С усложнением дизайнов усложнялся и css. Усложнялся и в плане добавления новых свойств, и в плане общей организации. В добавок к этому на том этапе была проблема совместимости с разными браузерами. Для того, чтобы твой сайт одинаково отображался и в Internet Explorer, и в Firefox, нужно было обладать достаточно специфичными знаниями. Отсюда появляется новая специализация Верстальщик. Не на английском, потому что на западе обычно этой работой занимался дизайнер, там считай такой специализации не было. У нас же дизайнеры почему-то отказывались делать эту работу. От них на выходе был PSD файл, сделанный в фотошопе. Далее верстальщик делал html + css файлы на его основе и отдавал из дальше Backend Developer'у. Ага, по факту из ниоткуда возникает еще одна специализация. По сути это тот же Web Developer, но он уже больше занимается именно скриптовой частью сайта и взаимодействием с базами данных, чем написанием html. При этом он всё еще работает с хтмл, полученным от верстальщика, но его задача теперь заключается в том, чтобы внедрить скриптовую часть в нужные участки готового хтмл. Так сказать оживить его динамикой, которую привносят данные из базы.

Здесь хочу немного отвлечься на развитие инструментов и технологий. Изначально сайты писались с использованием cgi скриптов, на смену им пришел php, но это всё еще были просто скрипты, и как именно их организовыать решали исключительно разработчики сайтов. Далее, когда люди увидели паттерны в организации этих самых скриптов, начали появляться веб фреймворки (web framework). Причем эти фреймворки писались уже на разных языках программирования, не только на php. Примеры из тех что я помню, многие кстати используются и сейчас: Symfony (язык PHP), Django (язык Python), Ruby on Rails (язык Ruby), Spring (язык Java). Их появление привело к тому, что сайты, особенно типовые, стало гораздо проще и быстрее писать, так как фреймворк решал за тебя очень много задач (роутинг, взаимодействие с базой, надстройки над html, общая организация кода). Плюс, зная какой-то фреймоврк, ты мог прийти в существующий проект и уже заранее знать как и что там организовано. То есть с одной стороны стало проще, с другой это еще более усложнило и углубило специализацию Backend Developer'a и по сути создало новые специализации вроде Ruby Backend Developer, Java Backend Developer и т. д.

Здесь еще раз отвлекусь, но в этот раз на языки программирования. Большинство языков программирования создавались как универсальные. То есть на одном и том же языке можно писать и сайты, и игры, и десктопные приложения. Но можно не означает нужно. В том смысле, что на одних языках что-то делается гораздо легче, чем на других. Например, ты можешь написать сайт на C++, или написать игру на PHP. Но игрой на пхп скорей всего будет 2д платформер, который будет при этом лагать и идти в 10 кадрах даже на твоей машине, а у сайта на с++ будет невероятно сложный код, который просто нереально будет поддерживать. Поэтому у языков тоже появилась своя специализация, хотя и они могут пересекаться. PHP, Ruby, Java, Elixir, Kotlin — веб приложения, Python — AI/ML приложения, Kotlin/Java — мобильная Аndroid разработка, Swift — мобильная iOS разработка. Вообще языков программирования тысячи, вот прям тысячи. И подход типа «я хочу быть программистом, поэтому я выучу все языки программирования по алфавиту» естественно не работает. Так что лучше всегда отталкиваться от задачи. Плюс во всех языках встречаются одни и те же принципы. Их всегда можно разделить по парадигме (OOP, функциональные), по типизации (строгая, динамическая), по синтаксису (C-подобные, ML-подобные, семейство Lisp языков), по платформе (JVM, Beam). Это к тому, что если ты потратил некоторое время чтобы выучить Ruby, то Python ты выучишь гораздо быстрее, так как они оба объектно ориентированные, или после Java легко перейти на Kotlin, так как оба языка писались под одну JVM платформу. Так что условно можно прочесть только одну толстенную книгу (или пройти длинный туториал), а дальше уже смотреть на кусочки другой толстенной книги (таймстепмы или разделы туториала), чтобы узнать как реализуются конкретные части в новом языке.

Может быть я немного забегаю вперед (напомню что в основном повествовании мы остановились на специализациях бекенд разработчиков), но в разговоре о языках отдельно хочется сказать про JavaScript. Изначально язык создавался для скриптования поведения на хтмл страницах, например, я нажимаю на кнопочку, и появляется блок с менюшкой. То есть вначале у него была очень узкая область применения, но из-за достаточно низкого порога вхождения он развивался просто невероятными темпами. В итоге кажется, что, зная JavaScript, можно делать практически что угодно. И бекенд для сайтов (NextJS, nestjs, Remix), и фронтенд (React, Vue, Angular, Svelte), и десктоп (Electron), мобильные приложения (React Native), и даже игры (Phaser). Это все делает его чуть ли не идеальным первым языком для изучения.

Все-таки вернусь к специализациям. Как я уже говорил бекенд усложнился с появлением фреймворков, но что там с нашими верстальщиками? В их случае немного поменялись процессы. Теперь для оптимизации они не просто отдают хтмл бекендерам, которые внедряют его во фремворк, теперь сами верстальщики делают верстку внутри фреймоврка, используя инструменты и соглашения этого фрейморка. Например, в том же Ruby on Rails разметка описывается не в хтмл, а в ERB файлах, а стили описываются не css, а scss, и уже сам фреймворк занимается преобразованием в html+css. Кроме этого усложняется поведение страниц, а также получает распространение Ajax технология (возможность делать запросы на сервер без полной перезагрузки страницы). Из-за этого приходится изучать и достаточно много писать на JavaScript. Тут в помощь приходят JS библиотеки вроде jQuery, и наш верстальщик потихоньку превращается в Frontend Developer, что как бы должно уточнить специализацию и показать, что разработчик уже умеет не просто верстать страницы, но и реализовывать их достаточно сложное поведение в браузере, которое так же может включать дополнительные запросы на сервер (например редактирование и сохранение профиля) без перезагрузки сервера.

Вот эта возможность делать запросы без перезагрузки на самом деле была достаточно революционной. Вообще классический пример, который показывает масштаб и потенциал, — это Gmail. Ты можешь управлять письмами на клиенте (в браузере) и только иногда делать запросы в бекграунде, чтобы синхронизировать изменения на клиенте с сервером. Идея в том, что эту логику, которой раньше занимался сервер, то есть формирование нового html при изменении состояния (например новый список писем в папочке), теперь можно описывать исключительно на клиенте используя JavaScript. Сложность клиентского кода довольно резко усилилась. Теперь тебе не достаточно библиотек типа jQuery, которые умеют только манипулировать блоками хтмл на странице, теперь тебе нужны инструменты для описания абстракций типа "Почтовый ящик", "Письмо" или "Корзина" для того, чтобы хоть как-то контролировать сложность кода, выполняемого на странице. Это все вылилось просто в поток фреймворков и тулинга уже для клиентского (или Frontend) кода.

В этот период JS фреймворки появлялись и исчезали с довольно большой скоростью. Ситуацию хорошо описывала перефразированная древняя китайская пословица: «Если достаточно долго сидеть на берегу реки, то можно увидеть как по ней проплывет тело умершего JS фреймворка, который ты хотел изучить». В итоге из этой борьбы вышли React, Angular, Vue, Svelte, ну и может парочка других библиотек. Результатом также стало дальнейшее сужение специализации. Теперь, как и у бекенд разработчиков, у фронтендеров появилось разделение на React Frontend Developer, Angular Frontend Developer и т. д. Также постепенно началось разделение кодовой базы. Если изначально бекенд отдавал хтмл, то теперь все чаще он начинает отдавать только данные (часто в виде JSON по Rest API протоколу). Фронтенд уже отдается более "легковесными" (в том смысле, что от них уже не требуется взаимодействие с базой данных или сложный роутинг) серверами, а далее браузер уже выполняет код, который реализует логику приложения, используя данные, полученные от бекенда по Rest API.

У этого нового подхода плюсом можно также считать то, что Backend API (данные, отдаваемые по Rest протоколу) можно было переиспользовать в разных приложениях, в мобильных и браузерных. DIM — хороший пример. Из-за того, что у банжи есть нормально реализованный backend API, создатели дима смогли сделать и сайт, и мобильное приложение. При этом источник данных у них один. Или тот же d2armorpicker. Банжи даже не предполагали какие приложения могут быть построены поверх их публичных данных.

Забавный факт, что у этого разделения появилась и обратная сторона. Не все заказчики готовы оплачивать команду разработчиков, то есть им нужен чисто один универсальный солдат. Казалось бы ты, как бекенд разработчик, пройдя по эволюционной лестнице, описанной выше, можешь просто использовать подход и инструментарий, который не предполагал разделения на бекенд и фронтенд. И некоторые идут по этому пути, несмотря на то, что подобный подход считается устаревшим. Но другие пытаются следовать более-менее современным практикам, что требует от них (как впрочем и первый вариант) знаний и фронта, и бека. Такие люди будут у нас уже называться Fullstack Web Developer. Не всегда фулстек — одиночка. Иногда вас может быть целая команда, но идея в том, что любой человек в такой команде может выполнить любую задачу, будь то подверстать какую-то форму или реализовать интеграцию с платежной системой. На практике я не видел прям трушных фулстаков, которые умеют делать все одинаково качественно. Обычно это или фронт, который может что-то несложное сделать на беке (ну или сложное, но долго), или наоборот.

Отдельно хочется упомянуть такую специализацию как DevOps Engineer. В самом начале я рассказывал про деплой и насколько он просто делался. Этот процесс тоже все время усложнялся. В какой-то момент эту функцию взяли на себя фреймворки, то есть код, связанный с деплоем, обычно реализовывался в самом фреймворке; от тебя же нужно было как-то сконфигурировать возможность доступа к машине на хостинге, ну и может быть провести небольшой предварительный сетап (поставить нужные приложения) на этой машине. То есть деплой все еще делался с машины разработчика. Такой подход очень плохо масштабировался. Представь себе сайт, над которым работает 200 или даже 2000 человек, и все они как-то меняют и заливают свои изменения. В итоге пришли к тому, что вся сборка и деплой отделены в отдельный процесс, который выполняется на отдельной машине и который запускается каждый раз, когда изменения попадают в кодовую базу (репозиторий), которая кстати тоже уже хранится на отдельной машине (и разработчики периодически достают изменения чтобы синхронизироваться). В добавок ко всему хостинг провайдеры начали усложнять инфраструктуру и предлагать различные сервисы (Amazon Aws). Тут еще можно долго рассказывать о процессе деплоя, но можно себе представить что вся эта сложность потребовала своих специалистов со знанием своей специфичной предметной области. Так и появились девопс инженеры. Обычно это были или бывшие Администраторы, которые разбирались в unix системах, или бывшие бекенд программисты, на которых свалились (ну или же они сами с радостью взялись) задачи, связанные со сборкой и деплоем. В общем, если на релизе или при обновлении какой-то онлайн игры возникают очереди, вылеты или любые проблемы с сетью, то, возможно, дев опсы — это те самые люди, которые больше всех налажали, не смогли правильно настроить сервера или правильно закодить масштабирование серверов или распределение трафика.

Пару слов про тестирование, а так же Manual QA Engineer и QA Automation Engineer (SDET). Понятное дело, что когда разработчики сделали какой-то продукт, то его нужно протестировать. По хорошему сами разработчики должны, во-первых, вручную протестировать свой код, во-вторых, покрыть продукт автоматическими тестами. Но тут есть куча нюансов. Специализация мануального тестировщика существует по нескольким причинам. Иногда процессы не достаточно хорошо налажены (ой, у нас нет времени писать тесты, ой, заказчик не оплачивает тесты) или разработчики не достаточно дисциплинированы, чтобы покрывать код автотестами. Иногда специфика продукта усложняет или делает автотесты невозможными. Например, игры. Какие-то штуки ты можешь покрыть тестами, типа вычисление демеджа в зависимости от действующих скиллов, баффов и сопротивлений, но то, что персонаж где-то падает под текстуру, уже можно вычислить только при ручном тестировании. Обычно мануальщики неплохо знают бизнес логику приложения и в дальнейшем могут либо углубиться дальше и заниматься уже написаним автотестов, что сделает их уже QA Automation, либо уйти в оценку бизнеса и более плотную работу с заказчиком в качестве Business Analyst (BA) или даже Project Manager (PM). Но так же нередко из мануальщиков переходят во фронтенд и бекенд разработчики.

По поводу коммуникации с заказчиком. Изначально нужно быть готовым к любого рода коммуникациям. Заказчик может ставить задачи или консультироваться напрямую, возможно, у заказчика будет свой дизайнер, с которым придется общаться, или своя команда и свой PM, Engineering Manager (EM) или еще кто-то. Общаться придется на разных этапах: пресейл (когда заказчик только выбирает команду для разработки), на стадии активной разработки (когда нужно уточнять требования), на стадии демо (когда нужно будет показывать какой-то выполненный кусок работы). И общаться придется разными способами: голосом, имейлами или же в чатах. Иногда аутсорс компании пытаются построить стену между заказчиком и разработчиком в виде PM от нашей стороны. Хоть такой вариант и возможен, но я бы на него не особо надеялся (у меня, по крайней мере, не так), и у него есть определенные минусы, так как всегда возможен эффект сломанного телефона, который обычно ни к чему хорошему не приводит. Часто собеседования даже в наши аутсорс компании начинают на английском. Но может это чисто наша фишка, тут нужно уточнять.

Закончить хочу упоминанием специализаций, которые появились буквально в последний год. Это все, что связано с AI, в нашей компании это — Agent Systems Engineer и Deep Learning Engineer. В чем состоит работа и вообще специфика я не расскажу, но нам говорят, что за этим прям будущее, это нужно знать хотя бы в некоторой степени, чтобы не устареть и не оказаться на улице, и что весь веб и все, что мы делали до этого, станет как бы дополнением к АИ приложениям. Не знаю так ли это, но тут мы практически с тобой на одном уровне. Мне тоже нужно пройти хотя бы пару курсов, чтобы увидеть потенциал, возможные области применения и то, чего в будущем захотят заказчики.

Как-то очень длинно получилось, при этом кажется, что ни о чем так толком и не рассказал. В любом случае если появятся какие-то вопросы, даже если они покажутся глупыми, то задавай — не стесняйся.