Язык разработки: что решает заказчик, а что команда

Короткий ответ

Нет, выбирать язык заказчику не нужно. Но это не значит, что решать нечего: просто решения лежат на уровень выше, и они куда важнее.

Заказчик лучше всех знает ограничения: какие сценарии критичны, с чем система обязана интегрироваться, какая ожидается нагрузка, к какому сроку нужен результат и кто будет всё это поддерживать через год. Из этих ответов стек выводится почти механически.

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

Что на самом деле определяет выбор

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

Мобильные приложения

Здесь выбор сводится к трём вариантам, и решает не мода, а то, что критично для продукта.

Нативно — Swift для iOS и Kotlin для Android. Это две разработки, то есть дороже и дольше, но максимум от платформы. Берём, когда важны плавность и сложные анимации, тяжёлая графика и AR, работа с камерой в реальном времени или с железом. В платёжной платформе городского транспорта иначе было нельзя: оплата и запись на транспортную карту через NFC и анимация движения транспорта по данным ГЛОНАСС — это ровно та часть, где кроссплатформа упирается в потолок.

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

Kotlin Multiplatform — общая только бизнес-логика, интерфейс остаётся нативным. Это компромисс для случая, когда «родной» вид экранов важен, а платить за две полные разработки нечем. В приложении цветочного маркетплейса бюджет не покрывал два нативных проекта: на KMM iOS-версию собрали за два с половиной месяца против пяти на Android.

Разбор этой развилки подробнее — в отдельной статье про нативную и кроссплатформенную разработку.

Веб: фронтенд и бэкенд — разные разговоры

Фронтенд. Спор о языке тут почти закрыт: это TypeScript, а обсуждать имеет смысл фреймворк. Мы работаем на React и Next.js — они дают серверный рендеринг (важно для поиска), статическую сборку и предсказуемую производительность. Сайт этого блога собран ровно так, и сайт крупного банка, где мы довели вёрстку страниц до конструктора, тоже.

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

На практике это выглядит так. Node.js и TypeScript удобны, когда фронтенд и бэкенд пишет одна команда: один язык, общие типы, меньше стыков. Python берут, когда рядом данные, аналитика или модели — в инфраструктуре федеральной продуктовой сети каталог с ценами и остатками по каждому из примерно двадцати тысяч магазинов мы делали на Python 3 и Elasticsearch. Go уместен там, где нужна экономная обработка большого потока запросов. Java и Kotlin — когда система живёт в enterprise-контуре с его требованиями к интеграциям и поддержке. PHP остаётся разумным для сайтов на CMS и для развития того, что на нём уже написано.

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

ИИ: почему все говорят «Python» — и когда он не нужен

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

А вот продукт вокруг модели — бот, ассистент, интеграция с CRM, веб-интерфейс — не обязан быть на Python. Обращение к модели это обычный сетевой запрос, и писать его логично на том, на чём написан остальной ваш сервис. Наш собственный бот приёма заявок работает на Node.js вообще без внешних зависимостей — так его проще разворачивать и нечему ломаться при обновлениях.

Практическое правило: Python обязателен там, где вы работаете с данными и моделями сами. Если вы пользуетесь готовыми моделями по API, язык продукта выбирается по обычным критериям из начала статьи.

Когда заказчику всё же стоит вмешаться

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

Во всех четырёх случаях вы приносите не название языка, а ограничение. Название мы предложим сами — и объясним, почему именно оно.

Красный флаг: «мы всё делаем на одном»

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

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

Коротко

Опишите задачу и ограничения — вернёмся с оценкой объёма и сроков за два рабочих дня и с рекомендацией по стеку, в которой будет написано, почему именно так.