Недавно у нас вышел проект лапшеснимателя — когда мы вручную писали алгоритм, который будет находить на странице нужные слова.
После этой статьи у нас прошёл разговор с человеком, который профессионально занимается разработкой и нанимает людей — Колей Митиным из компании «Кортекс». И у него есть мнение, которым мы хотим поделиться с вами.
👉 Будет полезно всем, кто готовится стать продуктовым разработчиком и профессионально создавать софт.
Вот мысль:
«Есть философская тема, просто подискутировать.
Я наконец-то наладил работу в «Кортексе» и нанимаю разрабов. Вот у меня такие штуки в текущей разработке вызывают сомнения. Потому что сейчас умение писать код становится всё менее востребованным.
То есть, поставив задачу перед разработчиком, я бы ожидал, что человек скорее принесёт мне код:
pip install highlight-text
highlight_text(text, ['словоформы', 'для', 'подсветки'])
(То есть нашёл бы готовое решение среди существующих библиотек и применил бы его в проекте за пять минут, а не городил бы целый алгоритм с нуля. — Прим. ред.)
В общем, олимпиадные программисты, которые умеют писать алгоритмы, — сейчас нишевая профессия, а продуктовые, которые умеют собирать всё из готовых библиотек — ой как нужны.
Смысл в том, что когда ты в проекте написал свой код, его надо обслуживать и тестировать. А если ты взял нормальную библиотеку, то её обслуживает сообщество.
В итоге писать свой код становится очень дорого.»
Развернём эту мысль по мотивам дальнейшей беседы с Колей.
Что не так с «олимпиадным программированием»
Есть такой взгляд на программирование, что для решения задачи нужно создать новый файл и с нуля придумать решение (как это сделали мы в своём проекте). Чтобы это решение работало, нужно придумать какие-то алгоритмы: циклы, логику, проверки и т. д. Обычно такие задачи дают на олимпиадах по программированию, отсюда и название.
У таких алгоритмов есть сильная сторона: если мы пишем алгоритм под конкретную задачу, скорее всего, он получится быстрым, оптимизированным, учитывающим все текущие нюансы.
Но есть и проблемы:
❌ Алгоритм — это ещё не продукт. Чтобы от алгоритма перейти к продукту, нужно написать интерфейс, подготовить серверную инфраструктуру, подготовить все вспомогательные модули. Представьте, сколько всего должно работать в интернет-магазине: авторизация, восстановление пароля, добавление товара в базу, возврат товара, рекомендации товаров и т. д. Если вы написали пусть даже гениальный алгоритм рекомендаций товара, это только 5% разработки вашего интернет-магазина.
❌ Разработать мало. Нужно поддерживать. Продукт, который мы напишем сегодня, нужно будет поддерживать несколько лет. За это время могут смениться разработчики и технологии. В какой-то момент наш оптимизированный авторский алгоритм может оказаться несовместимым с новыми технологиями.
Ещё хуже — если разработчик, который написал исходный алгоритм, уходит из компании, не оставив после себя документацию по алгоритму. Тогда оставшимся разработчикам будет трудно разобраться, что как работает и как поддерживать этот продукт.
Коля Митин:
«Иметь свой код сейчас очень дорого.
Поэтому мы даже свой код пишем «по учебнику». То есть берём известный фреймворк и всё по бест-практисес.
У нас вообще в проектах никаких тайных знаний, всё либо в конфигах Докерфайлов или Анзиблов или написано по хендбуку фреймворка.
Даже если нужно просто перекатать данные из одной базы в другую, то мы делаем модели, дописываем сервисы и всё вот это вот. Потому что это не так долго и страшно, если умеешь, а прочитать и понять код сможет любой, кто знаком с несущим фреймворком.»
А как тогда делать?
Альтернатива — использовать готовые библиотеки и фреймворки с открытым кодом. Вместо того чтобы писать решение с нуля — находить готовые решения и собирать из них продукт.
Что это даёт:
✅ Большие продукты создаются быстро. Теперь разработка сводится не к тому, чтобы сочинить алгоритм. Вместо этого ты находишь нужные библиотеки, склеиваешь их и тестируешь. Это гораздо быстрее.
✅ Документация на всё. Публично доступные фреймворки и библиотеки тщательно задокументированы, к ним есть учебники, справочники, правила и best practices. Если у вас ушёл один разработчик и пришёл другой, который не разбирается в вашей технологии, — он легко обучится по общедоступным справочникам.
✅ Поддержка — у сообщества. У открытых библиотек и фреймворков есть люди, которые их поддерживают. Другие люди предлагают улучшения и исправляют баги. Третьи исследуют безопасность этих решений. Если на библиотеку критически посмотрело сто разработчиков, это явно более надёжная библиотека, чем если её написал один программист в вашем офисе.
А что делать с тем, что каждый квартал появляется новый фреймворк?
Коля Митин, Кортекс:
Это такой программерский миф. В целом у поддерживаемой технологии жизненный цикл около 10 лет. За это время обычно проект бросают, консервируя, или два раза переписывают, потому что концепция поменялась.
К тому же чтобы взять новый модный фреймворк в продакшн, его версия как минимум должна начинаться с 2, а лучше с 3. Тогда понятно, что он прошёл проверку временем.
И это хорошо работает, потому что версии 1 обычно используют всякие early adopters в частных проектах. Там они ловят все проблемы первой версии (и исправляют).
Алгоритмы ещё нужны, но не всем
Это не значит, что писать алгоритмы с нуля больше не нужно. Просто теперь это не всё программирование, а лишь его часть, причём не самая большая.
Вот примеры, где алгоритмы всё ещё нужны и полезны:
- Внутри сложных продуктов или в больших компаниях типа Google и Facebook.
- В разработке, где критически важна оптимизация — например, в высоконагруженных системах, в создании драйверов, программировании микроконтроллеров.
- Для создания собственных библиотек, фреймворков и языков программирования.
- В обучении основам информатики.
Что нужно, чтобы быть востребованным продуктовым разработчиком
Процитируем пост Коли из его канала «Коля Митин говорит»:
Очевидно, что разработчики сейчас пишут кучу одинакового кода каждую секунду по всему миру.
Ценность современного продуктового разработчика в том, чтобы внимательно следить за технологиями, изучать подходы, понимать, какие из них перспективные, какие неудачные.
Продуктовый разработчик как повар. Знает, как собрать продукт из хороших полуфабрикатов, как и какие продукты между собой сочетаются, а какие испортят вкус друг друга и вызовут несварение у пользователя. Знает особенности приготовления и уместность в конечном блюде.
Высшим пилотажем для продуктового разработчика является умение видеть технологии, которые действительно революционизируют продуктовую разработку, и участвовать в их развитии.
Продуктовый разработчик старается писать как можно меньше логики, предпочитая программировать конфигурации частей системы. В идеальном продукте вся логика хранится в частях системы, которые разрабатывают отдельные команды, а связаны они между собой только конфигурацией конечного продукта.
Вы работодатель? Вам слово
Если вы нанимаете разработчиков, менеджеров или аналитиков в ИТ-командах и у вас есть взгляд на состояние рынка — велком: maxim.ilyahov@yandex.ru
Будем рады опубликовать ваш взгляд или рассказ. Покажите начинающим разработчикам, что реально нужно на рынке.
