Всем привет, меня зовут Серёжа, я технический лидер iOS-разработки в Альфа-Банке. Сегодня я хочу поговорить о многогранности мира программирования, а именно о количестве языков и причинах, по которым они нам нужны, и о том, зачем одному программисту несколько языков.
Поскольку тема довольно неоднозначна, хочу зафиксировать два момента:
Всё нижеизложенное – моё личное и субъективное мнение, основанное на моём опыте.
Если с каких-то рассуждений прямо сильно подгорит, приходи в комментарии, будет классно пообщаться!
Из основных причин, зачем учить языки (как языки программирования, так и языки в принципе), выделю: непредсказуемое будущее (никогда заранее не знаешь, какой язык тебе пригодится), огромное количество зарубежных материалов и базирование многих вещей на английском (например, название сущностей в том же Swift). В целом с языками программирования так же, как и со знаниями: лишними точно не будут.
Как я знакомился с языками
Сколько себя помню, с тех пор, как начал интересоваться ИТ, меня всегда поражало разнообразие языков программирования. В школе мы изучали Pascal, Delphi и позднее C. Я вообще не понимал принципиальную разницу между ними, зачем их так много и для чего мне учить новый язык, если я уже знаю какой-то (справедливости ради, для школьных задач все языки примерно одинаковые).
Уже позже, в университете, я узнал, чем же всё-таки отличаются языки, зачем придумывают новые, и как с этим жить. Тогда же у меня и сформировалась чёткая метафора о параллели языков программирования с инструментами.
Языки программирования, как инструменты в ящике рабочего. Да, можно взять только молоток, особенно если рабочий — специалист по забиванию гвоздей. Молотком можно забить саморез в стену при большом желании, но, согласитесь, если бы у вас была отвёртка или шуруповёрт, с саморезами вам было бы гораздо проще (да и саморез сел бы надёжнее).
Так и с языками, нет единого, который применим вообще ко всему и на отличном уровне (привет, JavaScript). Каждый язык хорош для какой-то одной или даже нескольких задач, но использовать его везде не имеет большого смысла, так как постоянно придётся мириться с ограничениями.
Главный вопрос: какие языки учить?
Так какие же языки нужно учить программисту? Вопрос довольно сложный и многогранный. Да и слово «нужно» неуместно, так как особо горящей потребности в этом, как правило, нет.
Я, как мобильной разработчик, могу говорить с высоты своего опыта только о фронт-разработке (простите за тавтологию), но, думаю, что и у ребят с бэкенда или системной разработки (или любых других мест, разработка живёт не одними программами) идеи будут те же самые.
Конечно, тем, кто пишет на более-менее современных языках (JavaScript, Kotlin, Swift) сложно понять, что существуют другие языки зачем нужны другие языки программирования. Все они мультипарадигмальные, и на них можно писать почти что угодно, причём с удобством для себя. В чём же тогда проблема — разберёмся далее.
Плагины, скрипты и на чём их пишут
Возьмём утилиты, которые помогают нам в работе (я сейчас не про IDE): плагины, скрипты, автоматизаторы. На чём их пишут? Ну, наверное, можно написать на тяжёлом Swift или Kotlin, можно использовать npm и тащить с собой всю телегу с модулями различные библиотеки для JS, и это даже будет работать, но насколько это всё удобно? И что делать, если на рынке уже есть утилита, которая требует другого языка?
В таком случае вам пригодятся lightweight-языки для написания простеньких скриптов, особенно те, которые позволяют развернуть нужное окружение на любой рабочей машине и жить в одном окружении всей команде. Так, например, очень удобно писать скрипты на Ruby или Python, потому что они встроены в большинство Unix-систем, а также дают возможность настроить весь workaround очень просто (например, с помощью Bundler). Можно ещё писать скрипты прям для bash (zsh и т.д.), это почти максимальный lightweight, но ты платишь за это удобством, да и не все хорошо владеют Shell сегодня.
Многие из нас пишут удобные скрипты для работы, но вот в чём проблема: чтобы запустить скрипты, их нужно скачивать и разворачивать у себя, поддерживать в актуальном состоянии и т.д. Если скрипт маленький — ничего, а вот если большой, для него нужны сторонние ресурсы, которые неизвестно где находятся, а если вам ещё и нужен доступ к базам данных…
Мы делаем для такого микросервисы — лайтовые внутренние «ручки», которые можно дёрнуть из внутренней сети и воспроизвести функции, например, добавить ревьюеров в репозиторий разом во все в проекты.
Так исторически сложилось, что эти микросервисы мы пишем на Go. По нынешним меркам довольно молодой язык, который уже успел заслужить одобрение со стороны многих крутых компаний, и они начали применять его в продакшене. Подробно про Go можно почитать тут. Добавлю, что это системный язык программирования, который работает очень быстро.
Прикольно, занимая должность iOS-разработчика, параллельно приобретать новый востребованный навык. Понятно, что Go — неспецифический язык для iOS, в отличие от Swift, но для меня это и стало мотивацией поизучать его. На Swift тоже можно писать микросервисы, и ребята в Альфе даже пробовали. Но чаще пишем на Go, как раз чтобы попробовать что-то интересное. Были даже случаи, когда ребята из iOS уходили в бэкенд, просто потому что понравилось.
Примеры с CocoaPods и Fastlane и хаосом в линтере
В iOS-разработке есть самый популярный и удобный менеджер пакетов под названием CocoaPods, который написан на Ruby (и да, я знаю про Carthage и SPM, но пока они не отняли весь рынок у CocoaPods). Знание Ruby у нас явно будет не лишним.
Также есть безумно популярный и удобный автоматизатор сборки под названием Fastlane, и он тоже на Ruby. Здесь резонный вопрос: ну и что, что они на Ruby, я же их только использую? Да, всё так, но часто компании дорабатывают эти утилиты или пишут свои функции, чтобы расширить возможности. Согласитесь, в таком случае неплохо бы знать Ruby?
Необязательно знать все фреймворки, вышедшие для Ruby, или все ультрасложные конструкции языка, но неплохо понимать базовые штуки. Расскажу пример из жизни: у нас в Альфе как-то раз на сборках PR начал происходить просто хаос, код менялся сам собой, причём непонятно на что (это было ещё даже до появления ChatGPT).
Мы не могли понять, что происходит со сборками и начали раскапывать историю коммитов, чтобы найти виновника. Виновником оказалась функция на Ruby, которая изменяла приходящие в неё данные через параметры. В Swift для этого нужно указывать специальное слово inout, чтобы приходящие параметры можно было менять, а в Ruby это по умолчанию(сейчас профессионалы Ruby могут меня съесть, потому что это не совсем так, но в данном контексте этого достаточно). iOS-разработчик о таком, естественно, не знал.
В общем и целом, забавная вышла история, мы смогли быстро найти проблему и откатить изменения. Ничего страшного не случилось, но могло что-то сломаться при сборке релиза.
Теперь о CI/CD
Кроме скриптов и автоматизаторов, на большинстве мало-мальских серьёзных проектов используется CI/CD. Одна из самых популярных и известных таких систем (а также open source) — это Jenkins. Так вот, если вы хотите писать джобы на Jenkins, то придётся немного подучить Groovy.
Если кто не знает, Groovy — это язык, построенный на базе JVM и имеющий обратную совместимость с Java, что хорошо для людей, знакомых с Java, и не очень для тех, кто регулярно пишет на других языках. Да, можно переехать на другую систему CI/CD с другим языком, но менять инструменты только из-за языка как минимум странно и непрактично.
В любом случае большинство, если не все системы CI/CD так или иначе привязаны к какому-то языку разработки. Даже если вы напишите свою систему для данной цели, всё равно все джобы и скрипты нужно будет писать на каком-то одном языке. Команда чаще всего мультиплатформенная, и кому-то всё равно придётся осваивать новый язык для поддержки и доработки CI/CD.
Иногда, конечно, за CI/CD отвечает отдельный человек или команда, но такое бывает только на крупных проектах. И да, умение развернуть и поддерживать CI/CD никогда лишним не будет.
Pet-проекты и микросервисы для себя
Pet-проекты ребята пишут в свободное время, чтобы сделать что-то по кайфу. Если тебе нравится программировать, логично, что в свободное время ты не против этим заняться, особенно если хочешь сделать что-то конкретное. Я как-то написал за пару вечеров пульт для телевизора, потому что меня выбесили все приложения из стора: во-первых, они дорогие и рекламы очень много, во-вторых, я могу не хуже.
У нас в команде кто-то писал fullstack-проекты с фронтом, кто-то — чисто на бэкенде. Кто-то писал софт для тренировок, кто-то — приложение для изучения английского и даже получал деньги за рекламу.
Это покрывало затраты на аккаунт, плюс прилетало ещё 100$ в год сверху. Кто-то пишет проект, чтобы изучать новую технологию — это самая частая история. Компания Apple в своё время представила виджеты или Swift UI, и все побежали их пробовать. Мало прочитать гайдлайны и статьи про новые фишки, нужно пописать самому, чтобы всё понять. Для этого можно сделать калькулятор или To do лист. Главное не приложение, а как и с помощью чего ты его написал.
Pet-проекты требуют нестандартных подходов и мотивируют изучать новые технологии, чтобы добавить какую-то функциональность. Когда у тебя в багаже умение пользоваться разными языками, ты можешь запросто без изучения чего-то с нуля выполнить новую работу. У тебя расширяется инструментарий.
Обычно полноценные проекты разрабатываются большой командой, и до начала самой разработки подготавливаются различные артефакты, изучается рынок, планируется продукт, а также выбираются технологии для реализации. У pet-проекта нет стадии предпродакшена, разработка запускается, и необходимость в новой (и потенциально неизученной) технологии возникает сразу.
Если ты когда-то писал сервер на условном Python или Ruby, то можешь пойти и развернуть бэкенд для своего приложения. Если ты этого никогда не делал, потребуется больше времени, и нужно будет изучить новый фреймворк или новый язык и новый фреймворк для него. Те, кто пишут у нас микросервисы, намного охотнее разворачивают какие-то системы, чем те, кто занимается чистым фронтом.
Извечный холивар про единый язык и мультиязыки
Все мы знаем про замечательный JavaScript. Есть огромное количество людей, которые пишут на нём бэкенд, фронтенд, мелкие скрипты, микросервисы и даже мобильные приложения. При всём уважении, это прекрасный язык для своих вещей, я не хейтер JS, но и не сторонник такого мнения. Это быстро, удобно, ты не изучаешь новые технологии. Если вам нравится — спорить не буду, вам это приносит доход и (возможно) удовольствие.
Я считаю, что языки разрабатываются под конкретные нужды. У нас есть системные языки, языки для фронта, языки для мобильной разработки. Kotlin и Swift подходят много для чего, кроме того, под что они создавались, за счёт универсальности и продуманности, но имхо, скоуп этих задач ограничен. Если мы выходим за этот скоуп, могут возникнуть проблемы.
Одна из проблем — отсутствие большого комьюнити. Если ты пишешь бэкенд на языке, предназначенном для фронта, тебе будет трудно встретить таких же энтузиастов. Это приводит к тому, что некому развивать и двигать технологию, находить ответы на вопросы. Даже на Stack Overflow про Vapor в разы меньше ответов. Возможно, в будущем что-то изменится, но я не Нострадамус, я не знаю. Пока, выбирая фреймворк и язык для написания бэкенда в продакшен, вряд ли большинство компаний выберет Vapor, хотя фреймворк достойный, и его можно использовать.
Вернусь к сравнению языков программирования с набором инструментов. Давайте откладывать шуруповёрт, если нужно распилить дерево, и возьмём пилу, не будем заниматься ерундой. Я считаю, что проще писать на том языке, который больше подходит для нашей системы, а не пытаться натянуть его на всё. Если у вас другое мнение, а такое точно будет, буду рад услышать его в комментариях. Даже внутри нашей команды у нас расходятся точки зрения примерно 50/50.
Плюсы и минусы изучения нескольких языков
Что хорошего мы получаем:
Уменьшение выгорания на основном проекте за счёт изучения чего-то нового.
Дополнительные навыки, которые могут пригодиться в будущем.
Как следствие — изучение новых инфраструктур, архитектур и прочего.
Возможность быстрее и проще решать повседневные задачи и настраивать автоматизации.
Общение с новым комьюнити, рост вширь.
Потенциальный рост в Full-Stack разработчика, или в DevOps, или в техлида, ну и так далее.
А какие минусы могут быть:
Повышение порога входа на проект с большим количеством используемых языков (для скриптов, CI и т.д.).
Потенциальная каша из языков, если каждый будет использовать свой (привет, скрипты на Python с подключением JS и запуском через Ruby).
Синдром самозванца в новой для себя области.
Что ещё можно поизучать разработчику
Итак, вернёмся к обсуждению, какой язык учить. Это сильно зависит от вашего рода деятельности и того, чем вы хотите заниматься. Кому-то достаточно JS + React, его не в чем винить, но и осваивать новые языки и фреймворки всё же полезно.
Если говорить про мою специальность, я бы посоветовал iOS-разработчику изучать, кроме Swift, опционально Objective-C (iOS легаси все-таки) и Ruby (CocoaPods, Fastlane). Это несколько каверзный язык, у нас неоднократно были с ним проблемы (выше есть даже история об одной из таких проблем). Там много неочевидных вещей, особенно для неподготовленного зрителя. Если ты не изучишь их по книжечке, они могут всплыть рано или поздно.
Ещё iOS-разработчику можно изучить Kotlin, если очень хочется, он напрямую связан с Java — популярнейшим языком в мире. На Kotlin сегодня часто пишут бэкенд, поэтому его знание для столь важной части современной разработки точно не будут лишними. Kotlin — основной язык Android, огромной мобильной платформы. Круто понимать, как разрабатывают твои коллеги, особенно в большой компании. Если у тебя есть хотя бы минимальная экспертиза, ты сможешь что-то подсказать.
Разрабатывая какую-то технологию, некоторые совсем не учитывают ограничения альтернативной платформы. Тебе будет нужен оппонент, и да, ты не станешь экспертом в обеих платформах, но у тебя точно будут пререквизиты.
У JetBrains есть фреймворк Kotlin Native, чтобы разрабатывать сразу для двух платформ. Пока он сыроват, его мало кто использует в проде, но в перспективе он сможет в будущем сэкономить время разработки вдвое. Несколько человек будут делать системный код, а остальные вёрстку. Уже сейчас можно смотреть в будущее и изучать новые языки.
Ещё рекомендую изучить Groovy — язык над Java. Многие ребята, которые пишут на Java и Kotlin, с ним знакомы, как и ребята с Android (что логично). Для чего он айосеру? Напомню, о чём говорил выше: одна из самых популярных систем для CI/CD — это Jenkins.
Ну, и чисто моя личная рекомендация — Go. Мне он понравился благодаря ультралёгкому пониманию написанного кода, а также простому вливанию в комьюнити. Язык достаточно простой, чтобы его можно было быстро изучить действующему программисту, зато он предоставляет большие возможности и быструю скорость сборки (что подкупает после Enterprise iOS-проектов). На нём легко писать небольшие скрипты и собирать данные. Я его много для чего использую, не скажу, что он незаменим, но мне Go зашёл.
Как дальше жить после прочтения статьи
Если вы прочитали статью, и вам она показалась полной чушью, значит у вас есть своё альтернативное мнение, это круто!
Если статья вам не только показалась чушью, но и вы полностью не согласны с ней, отлично, жду ваших комментариев, буду рад услышать ваше мнение, это всегда интересно.
Если статья вам понравилась, но вы считаете её неполной, было бы здорово, чтобы вы написали свои мысли, запилим upd.
Если у вас остались вопросы, тоже пишите, отвечу, исходя из своего опыта.
Программист мыслит языками программирования, фреймворками, алгоритмами и т.д., поэтому чем шире его база знаний, тем круче будет полёт его мысли. Учите языки, наш мир развивается очень быстро, особенно ИТ-сфера, классно, когда вы на острие. Языки — непосредственный инструмент для создания продукта.
Возможно, именно вы придумаете универсальный язык, и нам больше не понадобится куча инструментов. А пока подрезюмируем: в программиста сможет влезть сколько угодно языков, вопрос в том, надо ли оно именно ему.
