«Если человек — гик, то это не только в рабочее время, это круглосуточно и на всю жизнь»

По-простому: кто такие бэкенд-, фронтенд- и фулстек-разработчики

• Фронтенд-программист разрабатывает все, что пользователь видит на экране.
• Бэкенд-программист делает серверную часть — программу, к которой обращается конкретный сайт или мобильное приложение с разными просьбами. Например, «вытащи из базы данных список пользователей и пришли его мне».
• Фулстек-программист умеет делать и серверную часть, и многообразные виды фронтенда: сайты, приложения, ботов, программы для компьютеров, прошивки для электронных устройств. Иначе говоря, человек-оркестр.

Существуют ли фулстек-специалисты?

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

Такой специалист начинает программировать еще в детстве, к 15 годам имеет неплохой опыт на разных языках, получает высшее профильное образование, работает по 2-3 года в разных компаниях — в общем, «дозревает» около 20 лет.

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

Крутая кузница фулстек-кадров — фриланс. Фрилансеры редко сидят годами над одним и тем же проектом — им сама жизнь подсовывает разноплановые задачи. Более того, когда работаешь в команде, можно передать задачу коллегам. Фрилансеры же чаще тянут проекты в одиночку. Некому помочь с бэкендом? Будь добр, сам научись.

Какие специалисты в команде не нужны

Программист, который говорит, что делает только фронтенд и только на этой конкретной платформе, — либо обладает крайне маленьким опытом, либо клинически нелюбознательный. И то, и другое плохо.

Проведу аналогию с музыкальной группой. Представьте, что вокалист просит ударника одновременно ударить по трем тарелкам. Тот, конечно, не справится, потому что у него всего две руки и две палочки. Или другая ситуация: соло-гитарист предлагает вокалисту повторить за ним трель, в которой три октавы меняются за одну секунду — тоже невозможно.

По-моим наблюдениям, не бывает хороших программистов, которые бы не любили программировать. У многих разработчиков профессия совпадает с хобби. Я знаю, что после рабочего дня мои ребята решают программерские головоломки, делают из своей квартиры «умный дом» или прогают другой личный проект.

Сериал «Теория большого взрыва» не то чтобы сильно преувеличивает. Если человек — гик, то это не только в рабочее время, это круглосуточно и на всю жизнь.

Как организовать рабочий процесс в IT-команде

У нас в компании несколько фулстек-разработчиков, но, как бы мне ни хотелось, собрать команду только из них почти невозможно: таких специалистов на рынке труда мало. Я склоняюсь к тому, чтобы брать в команду программистов с максимально широким кругозором и делить их по задачам на фронтенд- и бэкенд-разработчиков.

Здесь можно привести пример из истории: когда в мастерской люди договорились разделить между собой труд, началась промышленная революция, а человечество пересело с лошадей на автомобили Генри Форда.

• Если человек отвечает за закручивание одной конкретной гайки — он в этой гайке разбирается лучше всех и умеет закручивать ее с неимоверной скоростью.
• Если специалист не тратит время на смену инструментов — ему проще сфокусироваться на своей конкретной задаче.
• Если сотрудник с четкой специализацией заболевает — его проще заменить, чем человека, чьи обязанности обширны и никому полностью неизвестны.
• Если нам потребуется закручивать больше гаек определенного типа — нам не нужно искать гениальных мастеров: достаточно взять любого человека и обучить его закручиванию такой гайки.

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

Разочарование сменилось сдержанной радостью, когда начался этап тестирования и доводки проекта. Багов оказалось меньше, и те, которые были, решались значительно быстрее. Сдержанная радость, в свою очередь, сменилась бурным восторгом, когда три проекта спустя мы обнаружили, что скорость разработки выросла примерно на 30% — программисты научились работать в команде, а менеджеры выстроили управленческий процесс.

Кроме того, разделение труда позволило делать разные части системы параллельно: пока верстальщик верстает, бэкенд-программист пишет API. Практически двукратное снижение срока на этап разработки.

***

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

Однако чтобы делать свою работу быстро и качественно, специализироваться он должен только на своих задачах. Краткий вывод из этой статьи прозвучит так: «Нужно ли фронтенд-программисту понимать базы данных? Да! Стоит ли ему в них залезать? Нет!».