«Программисты, которые умеют писать алгоритмы, — нишевая профессия»

Недавно у нас вышел проект лапшеснимателя — когда мы вручную писали алгоритм, который будет находить на странице нужные слова.

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

👉 Будет полезно всем, кто готовится стать продуктовым разработчиком и профессионально создавать софт.

Вот мысль:

«Есть философская тема, просто подискутировать.

Я наконец-то наладил работу в «Кортексе» и нанимаю разрабов. Вот у меня такие штуки в текущей разработке вызывают сомнения. Потому что сейчас умение писать код становится всё менее востребованным.

То есть, поставив задачу перед разработчиком, я бы ожидал, что человек скорее принесёт мне код:

pip install highlight-text

highlight_text(text, ['словоформы', 'для', 'подсветки'])

(То есть нашёл бы готовое решение среди существующих библиотек и применил бы его в проекте за пять минут, а не городил бы целый алгоритм с нуля. — Прим. ред.)

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

Смысл в том, что когда ты в проекте написал свой код, его надо обслуживать и тестировать. А если ты взял нормальную библиотеку, то её обслуживает сообщество.

В итоге писать свой код становится очень дорого.»

Развернём эту мысль по мотивам дальнейшей беседы с Колей.

Что не так с «олимпиадным программированием»

Есть такой взгляд на программирование, что для решения задачи нужно создать новый файл и с нуля придумать решение (как это сделали мы в своём проекте). Чтобы это решение работало, нужно придумать какие-то алгоритмы: циклы, логику, проверки и т. д. Обычно такие задачи дают на олимпиадах по программированию, отсюда и название.

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

Но есть и проблемы:

❌ Алгоритм — это ещё не продукт. Чтобы от алгоритма перейти к продукту, нужно написать интерфейс, подготовить серверную инфраструктуру, подготовить все вспомогательные модули. Представьте, сколько всего должно работать в интернет-магазине: авторизация, восстановление пароля, добавление товара в базу, возврат товара, рекомендации товаров и т. д. Если вы написали пусть даже гениальный алгоритм рекомендаций товара, это только 5% разработки вашего интернет-магазина.

❌ Разработать мало. Нужно поддерживать. Продукт, который мы напишем сегодня, нужно будет поддерживать несколько лет. За это время могут смениться разработчики и технологии. В какой-то момент наш оптимизированный авторский алгоритм может оказаться несовместимым с новыми технологиями.

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

Коля Митин:

«Иметь свой код сейчас очень дорого.

Поэтому мы даже свой код пишем «по учебнику». То есть берём известный фреймворк и всё по бест-практисес.

У нас вообще в проектах никаких тайных знаний, всё либо в конфигах Докерфайлов или Анзиблов или написано по хендбуку фреймворка.

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

А как тогда делать?

Альтернатива — использовать готовые библиотеки и фреймворки с открытым кодом. Вместо того чтобы писать решение с нуля — находить готовые решения и собирать из них продукт.

Начинающим программистам: что такое фреймворки и библиотеки

Что это даёт:

✅ Большие продукты создаются быстро. Теперь разработка сводится не к тому, чтобы сочинить алгоритм. Вместо этого ты находишь нужные библиотеки, склеиваешь их и тестируешь. Это гораздо быстрее.

✅ Документация на всё. Публично доступные фреймворки и библиотеки тщательно задокументированы, к ним есть учебники, справочники, правила и best practices. Если у вас ушёл один разработчик и пришёл другой, который не разбирается в вашей технологии, — он легко обучится по общедоступным справочникам.

✅ Поддержка — у сообщества. У открытых библиотек и фреймворков есть люди, которые их поддерживают. Другие люди предлагают улучшения и исправляют баги. Третьи исследуют безопасность этих решений. Если на библиотеку критически посмотрело сто разработчиков, это явно более надёжная библиотека, чем если её написал один программист в вашем офисе.

А что делать с тем, что каждый квартал появляется новый фреймворк?

Коля Митин, Кортекс:

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

К тому же чтобы взять новый модный фреймворк в продакшн, его версия как минимум должна начинаться с 2, а лучше с 3. Тогда понятно, что он прошёл проверку временем.

И это хорошо работает, потому что версии 1 обычно используют всякие early adopters в частных проектах. Там они ловят все проблемы первой версии (и исправляют).

Алгоритмы ещё нужны, но не всем

Это не значит, что писать алгоритмы с нуля больше не нужно. Просто теперь это не всё программирование, а лишь его часть, причём не самая большая.

Вот примеры, где алгоритмы всё ещё нужны и полезны:

Внутри сложных продуктов или в больших компаниях типа Google и Facebook.
В разработке, где критически важна оптимизация — например, в высоконагруженных системах, в создании драйверов, программировании микроконтроллеров.
Для создания собственных библиотек, фреймворков и языков программирования.
В обучении основам информатики.

Что нужно, чтобы быть востребованным продуктовым разработчиком

Процитируем пост Коли из его канала «Коля Митин говорит»:

Очевидно, что разработчики сейчас пишут кучу одинакового кода каждую секунду по всему миру.

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

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

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

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