Почему фуллстек

Деление разработчиков на фронтенд и бэкенд стало классическим и многим подходит. Мы методом проб и ошибок пришли к обратному. Почему — рассказывают бизнес-технолог, менеджер и тимлид, он же один из фуллстек-разработчиков.

Понимаешь, что и где выгоднее

// Слово нашему бизнес-технологу Павлу Хозяшеву. В свободное время Паша пилит свой pet-проект на React + NodeJS, отвечая за все стороны разработки.

«Почему 1 землекоп лучше 2,5 землекопов? (Да, базу тоже сам проектируешь, 0,5 землекопа на это.)

  1. Каждой функциональности — свой инструмент
    Если понимаешь ограничения и возможности каждой из сторон, не пытаешься запихать в любимый фронт или бэк всю возможную функциональность или откреститься от неё. Понимаешь, что и где выгоднее реализовать.
  2. Проще пилить промежуточные вещи типа API
    Если сам реализуешь фронт и бэк, не нужно согласовывать четкую спецификацию на API — берешь и делаешь лучший возможный вариант с точки зрения обеих сторон.
  3. Единая ответственность
    Тебя нужно погрузить в проект один раз и нет вариантов многократной передачи тасок между разработчиками ради „понимания, где это будет сделать лучше“. Кроме того, можешь поправить любой баг, если он может быть поправлен за конечное время».

Погружаешься не только в строчки кода

// Константин Рожков — тимлид и гендир. Стал первым фуллстек-разработчиком компании, когда это еще не было мейнстримом. Кто кроме него лучше опишет разработку у нас?

«Многие программисты любят пофутболить задачи, когда „проблема не на их стороне“. Мы с коллегами придерживаемся мнения, что задачи выполняются не для отметки в Редмайне, а для решения какой-то проблемы в бизнес-логике. Поэтому футболить мы не любим.

Знание и backend, и frontend позволяют думать не только о „своей“ части работы. Больше понимания реализации — больше шансов оптимальнее выполнить задачу. Кроме того, фуллстек видит шире и в решениях исходит из того, как этим будут пользоваться остальные.

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

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

Не просто делаешь, что сказали

// Менеджер Маша Третьякова работает на многих уровнях: с продуктами, проектами, клиентами, пользователями и командой.

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

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

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

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

Разделяешь подход?

Вакансия fullstack-разработчика (ASP .NET Core + Angular/Vue) у нас открыта всегда.

    Расскажи о себе, можешь сразу указать пожелания по формату работы и окладу.

    Оформлять резюме необязательно.

    Если приложишь код или ссылку на Github, наш ответ будет более конкретным.

    Мы всегда ищем талантливых сотрудников и обязательно ответим.