Хабр, привет! Меня зовут Илья Благородов, я занимаюсь разработкой уже более 30 лет, а ещё я — один из экспертов онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Сегодня хочу поговорить о том, как правильно выбирать инструменты для разработки, почему разбираться в разных инструментах — не равно уметь их правильно применять и что с этим делать.
Несколько лет назад я поймал себя на мысли, что начать программировать стало проще, чем когда-либо. Почти любую технологию можно освоить бесплатно: YouTube забит разборами, документация популярных продуктов стала гораздо лучше, а что непонятно — объяснит ИИ. Казалось бы, проблема подготовки разработчиков должна была исчезнуть сама собой.
Но на собеседованиях я всё чаще вижу обратное: кандидат уверенно перечисляет языки, фреймворки и инструменты, а потом «плывёт», как только разговор уходит от конкретной технологии к причинам её выбора. Знания стало возможным получить за минуты. Дефицитом стало другое — умение превращать знания в обоснованные решения.
Мне нравится думать об этом через одну аналогию. Тьюториал — это навигатор: он показывает проверенный маршрут из точки А в точку Б, предупреждает о поворотах и почти гарантирует, что вы доедете. Проблема в том, что инженеру рано или поздно приходится ехать по дороге, которой ещё нет на карте. И вот тут выясняется, что годы езды по навигатору не учат ориентироваться на местности.
Диалог, который годами повторяется на собеседованиях
Начну с истории, которая случалась со мной на собеседованиях столько раз, что я перестал считать её совпадением. Кандидат, в резюме — Redis, Kafka, Kubernetes.
Спрашиваю:
— Почему в этом проекте вы использовали Redis?
— Потому что он быстрый.
— А почему не хватило PostgreSQL?
— Ну… Redis быстрее.
— А какие именно задачи вы им решали?
— …
Дело не в Redis. Точно так же ломаются разговоры про Kafka, Elasticsearch, GraphQL — про что угодно. Человек умеет пользоваться инструментом, но никогда не задумывался, зачем тот появился в проекте.
И наоборот: однажды я собеседовал разработчика, у которого в резюме было совсем мало модных слов. На вопрос про кеширование он вместо ответа сам начал задавать вопросы: какие данные, как часто меняются, что случится, если отдать устаревшее значение. Через десять минут стало ясно, что он понимает предмет глубже, чем предыдущие пять кандидатов с «Redis» в резюме, вместе взятые. Мы его наняли и ни разу не пожалели.
Со временем эта закономерность стала для меня почти диагностической. Чем меньше у кандидата опыта, тем быстрее он бросается писать решение. Сильные инженеры, наоборот, начинают с вопросов: уточняют требования, спрашивают про объёмы данных и нагрузку, выясняют ограничения существующей системы. Нередко первые пятнадцать минут собеседования проходят вообще без единой строчки кода — человек пытается понять задачу, а не решить её. Признаюсь, раньше меня это даже раздражало: время идёт, а кода нет.
Теперь я понимаю, что смотрел не туда. Человек, который сначала разбирается в задаче, уже действует как инженер — он изучает местность, прежде чем строить дорогу. Такому инженерному мышлению мы в том числе учим студентов в онлайн-магистратуре «Фронтенд-, бэкенд-разработка и ИИ-решения»: наша задача — выпустить специалистов, которые будут смотреть на разработку системно, не только через призму тьюториалов и инструкций.
Яндекс Практикум: В онлайн-магистратуре ИТМО «Фронтенд-, бэкенд-разработка и ИИ-решения» вы можете выбрать направление — фронтенд или бэкенд, язык программирования — JavaScript, Python, Java или С++ и подходящий по уровню трек — для опытных или с нуля. Программа ежегодно обновляется, оставить заявку можно на сайте программы.
Почему тьюториалы так убедительны
Справедливости ради: тьюториалы работают, и работают отлично. Я сам регулярно ими пользуюсь — это лучший способ за вечер познакомиться с новой технологией. За несколько часов можно написать первое API, собрать Docker-образ, развернуть приложение в облаке. Быстрый результат мотивирует, и возникает ощущение, что освоение профессии — вопрос количества просмотренных роликов.
Ловушка в другом. Автор ролика заранее знает, куда едет: маршрут проложен, архитектура выбрана, код проверен. Зрителю остаётся повторить путь. А в реальной разработке заранее известного правильного пути почти никогда нет. Есть требования бизнеса, сроки, легаси, опыт команды, бюджет — и любое решение оказывается компромиссом между скоростью, стоимостью сопровождения и сложностью. Навигатор прекрасен, пока дорога есть на карте. Работа инженера начинается там, где карта заканчивается.
Тут можно возразить — и я сам долго так думал, — что это дело наживное: посмотришь сто тьюториалов и картина сложится сама. Не сложится. Сто проложенных маршрутов не учат прокладывать сто первый. Они учат доверять навигатору.
Есть и более сильное возражение, которое мне однажды высказали в комментариях: «А вы уверены, что дело в тьюториалах? Может, слабые кандидаты были бы слабыми при любом способе обучения?» Честный ответ: не уверен. Возможно, формат тут вообще ни при чём, и я путаю причину со следствием — люди, которые не любят задавать вопрос «почему», просто естественным образом выбирают формат, где этот вопрос не нужен. Но для практического вывода это неважно: в обоих случаях выход один и тот же — целенаправленно ставить себя в ситуации, где готового маршрута нет.
Как я сам съехал с карты в кювет
Признаюсь честно: самый убедительный аргумент против «обучения по роликам» я получил на собственном проекте. Лет семь назад, после прохождения одного курса по архитектуре, я притащил Kafka в сервис, который обрабатывал несколько сотен событий в день. Не в секунду — в день. Мне казалось, что мы «закладываемся на рост». В итоге команда полгода возилась с настройкой, мониторингом, группами, лагами, странными таймаутами, а задачу спокойно решил бы cron и одна таблица в PostgreSQL. Рост, под который мы закладывались, так и не наступил.
Самое неприятное — в тот момент я был уверен, что принимаю взвешенное решение. Я ведь «знал Kafka». Только позже я понял: я знал, как её использовать, но не задал себе главный вопрос — нужна ли она здесь вообще. Курс дал мне маршрут, и я поехал по нему, не глядя, туда ли вообще еду.
Кстати, выпилить её потом оказалось куда сложнее, чем внедрить: за полгода на неё успели завязаться два соседних сервиса. Это ещё одно свойство инженерных решений, о котором молчат тьюториалы, — у них есть стоимость отмены, и она почти всегда выше стоимости внедрения.
От «я знаю» к «я выбираю»
После той истории я стал формулировать для себя (а потом и для джунов в команде) четыре уровня владения любой технологией:
«Я знаю» — слышал на конференции, видел в вакансиях, посмотрел пару роликов.
«Я умею» — могу поднять контейнер, подключить Redis, написать сервис на новом фреймворке. Именно до этого уровня тьюториалы доводят отлично, и это нормально: для того они и создаются.
«Я понимаю» — могу ответить, почему технология устроена именно так, какие проблемы решает, где будет работать плохо. Сюда одними роликами уже не доехать: нужны документация, эксперименты, собственные ошибки.
«Я выбираю» — вопрос звучит уже не «как использовать Redis?», а «нужен ли Redis вообще?». Не «как развернуть Kubernetes?», а «настолько ли сложен проект, чтобы платить за Kubernetes?».
Вот на четвёртом уровне и заканчивается изучение технологий и начинается инженерия. И туда принципиально невозможно попасть, повторяя чужие действия — не потому, что авторы роликов что-то делают не так, а потому, что сам формат не предполагает принятия решений. Выбор уже сделан за вас.
В онлайн-магистратуре «Фронтенд-, бэкенд-разработка и ИИ-решения» мы уделяем много времени осознанному использованию инструментов и учим выбирать не между «правильным» и «неправильным», а между несколькими несовершенными вариантами: один быстрее реализовать, но тяжелее сопровождать; другой надёжнее, но дороже; третий проще для команды, но создаст ограничения через год. Умение видеть эти компромиссы и есть инженерное мышление. Отсюда, кстати, следует вывод, который поначалу кажется контринтуитивным: один и тот же инженер в разных проектах может предложить противоположные решения — и оба будут правильными.
Яндекс Практикум: В онлайн-магистратуре ИТМО «Фронтенд-, бэкенд-разработка и ИИ-решения» поступление и обучение проходят полностью онлайн, вы получите отсрочку от армии и студенческие льготы, а после выпуска — два диплома: магистерский от ИТМО и Яндекса о профпереподготовке. Оставить заявку можно на сайте программы.
Начинающие разработчики часто воспринимают архитектуру как набор рецептов: мало пользователей — монолит, много — микросервисы, нужны события — Kafka, нужна скорость — Redis. Ни одно из этих правил не универсально. Архитектура начинается не с выбора технологий, а с понимания задачи и ограничений; технологии появляются позже, как следствие. Выучить заранее ответ на вопрос «какую архитектуру выбрать» невозможно по той же причине, по которой невозможно заранее выучить маршрут по дороге, которую вы сами ещё не проложили.
История с код-ревью
Ещё один случай, который многое мне объяснил. Джун из моей команды принёс на ревью пулреквест: аккуратный, с тестами, с чистой структурой — и с полноценной реализацией паттерна CQRS для внутренней админки на двадцать пользователей. Код был хороший. Решение — нет.
Я спросил, почему CQRS. Он честно ответил: «Смотрел курс по чистой архитектуре, там сказали, что так правильно». Мы сели и час разбирали не код, а вопросы: сколько у нас пользователей, какая нагрузка, кто будет это сопровождать, что мы выигрываем и чем платим. В конце он сам предложил выбросить три четверти абстракций.
Через год этот же человек на ревью чужого кода первым делом спрашивал: «А какую проблему мы решаем?» Это и был момент, когда он перестал ехать по навигатору. Замечу: не тьюториалы его испортили — они дали ему «я умею». Просто следующий уровень пришёл не из роликов, а из разговора, в котором его решение пришлось защищать.
Где этому тогда учатся
Универсального ответа нет: кто-то проходит этот путь в университете, кто-то на сильных курсах, кто-то в первой хорошей команде, кто-то строит образовательную траекторию сам. В онлайн-магистратуре «Фронтенд-, бэкенд-разработка и ИИ-решения» мы тоже этому учим — всего за 2 года, так что приходите учиться. Если присмотреться, у всех путей есть общие черты:
Фундамент. Двадцать лет я слышу, что теория переоценена, потому что «на практике всё иначе». Отчасти это правда: мало кто ежедневно реализует структуры данных. Но за мою карьеру сменилось несколько поколений фреймворков, ORM и облачных платформ, а принципы распределённых систем, сети, теория баз данных и алгоритмы никуда не делись. Разработчик с фундаментом не запоминает очередной набор команд — он понимает, чем новый инструмент отличается от известных. Фундамент — это не навигатор, а умение читать местность: солнце, рельеф, стороны света. С ним не страшно, что карта устарела.
Обратная связь. Самому объективно оценить свои решения почти невозможно: если приложение работает, легко решить, что архитектура удачная. Разница между «работает» и «спроектировано правильно» проявляется через месяцы. Мне повезло: на первой серьёзной работе у меня был тимлид, который на любую мою схему отвечал одним и тем же вопросом — «а что сломается первым?». Тогда это казалось занудством. Сейчас я задаю этот вопрос сам — и себе, и другим — и он экономит недели. Хороший наставник ценен не тем, что знает ответы, а тем, что учит смотреть на систему под другим углом.
Последовательность. Небольшое отступление: когда учишься по роликам, ты изучаешь только то, что нужно прямо сейчас. Сегодня Docker, завтра Redis, послезавтра очередной фреймворк. Каждая поездка по навигатору успешна, но карта в голове так и остаётся набором несвязанных маршрутов. Системное обучение раздражающе устроено наоборот: оно заставляет разбираться в сетях, операционных системах и теории баз данных задолго до того, как они понадобятся. Во время учёбы это кажется избыточным. Ценность становится видна через годы — когда именно эти «лишние» знания позволяют ориентироваться в новой технологии за дни, а не за месяцы.
Контролируемый дискомфорт. Хорошее обучение устроено неприятно: задания сложнее предыдущих, код получает замечания, решения приходится защищать. Именно эта среда выталкивает за пределы шаблонов.
Я встречал сильных инженеров с любым бэкграундом: выпускников топовых вузов, людей из других профессий, самоучек. Общее у них одно: в какой-то момент каждый выехал за край карты — в вузе, где заставляли защищать решения, в команде с жёсткими ревью или на собственных болезненных ошибках вроде моей Kafka на триста событий в день.
Хороший тьюториал отвечает на вопрос «как это сделать?». Хороший инженер большую часть времени задаёт другие вопросы. Почему именно так? Какие есть альтернативы? Что произойдёт через год? Где слабое место? Стоит ли вообще решать проблему этим способом? Кто и как это будет поддерживать и развивать и сколько это будет стоить компании? Навигатор довезёт вас до места, куда уже ездили тысячи людей. Но однажды понадобится дорога, которой нет ни в одном тьюториале, — и в этот момент выяснится, кем вы были все эти годы: пассажиром или инженером.
