Антон Архипов: «Пользователи выбирают языки программирования с крутым сообществом»

Антон Архипов

---

Developer Advocate в JetBrains, Kotlin team. Любит спорт и играть на басу.

---

Ссылки

Смысл developer experience в том, чтобы разработчик не встречал технологических препятствий во время решения задач.

Нельзя сказать, что мы целенаправленно работаем над developer experience, но мы делаем много связанной с ним работы. Как минимум стараемся, чтобы программисту было комфортно писать и читать код. Он не должен биться головой об стол и кричать, что ничего не работает или ничего не понятно.

Что нужно хорошему языку программирования с точки зрения developer experience

Экспрессивность. Язык должен быть достаточно выразительным, чтобы описать задачу. Например, у нас есть список, и язык позволяет пройтись по нему с помощью какого-нибудь оператора — например, цикла for.

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

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

Инструменты. Первый инструмент, с которым мы встречаемся, когда работаем с языком программирования, — компилятор. Если компиляция программы занимает слишком много времени, это ухудшает developer experience. Поэтому чем быстрее работает компилятор, тем лучше.

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

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

Тестирование и отладка программ. Есть ли в языке инструменты для отладки кода? Насколько удобно разработчикам писать тесты? Если в программе возникнет ошибка, сможет ли разработчик остановить её в определённой точке и исследовать контекст? Все эти вопросы напрямую касаются developer experience.

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

Например, в вебе изменить состояние программы можно без повторной компиляции. Допустим, чтобы отобразить переписанный кусочек HTML-кода, достаточно нажать в браузере F5. В других, более сложных технологических стеках, например основанных на JVM, такие инструменты не предусмотрены. Максимум можно изменить значение какой-нибудь переменной и увидеть, как оно обновилось в программе.

До прихода в JetBrains я работал над продуктом, который умеет полностью обновлять состояние JVM‑приложения без повторной компиляции. Это экономит время и улучшает developer experience — позволяет быстрее исправлять ошибки.

Инфраструктура. Насколько легко развёртываются приложения, написанные на нашем языке? Какие для него есть инструменты командной разработки? Это важно, потому что мы часто работаем в командах и проводим код-ревью, а код надо где-то хранить.

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

Развитое сообщество. Пользователи выбирают языки программирования и технологии с крутым сообществом — так проще найти ответы на вопросы в интернете или на площадках вроде Stack Overflow.

Когда я предвосхищаю вопросы пользователей и создаю обучающий контент, то сокращаю цикл поиска ответов. Если человек изучает Kotlin и хочет узнать, как работать с фреймворком Spring Framework, он может выйти на наш канал и посмотреть мои видео на эту тему:

О чём мы пишем в наших медиа

Я выкладываю свои видео во все наши каналы — в первую очередь на YouTube, в Twitter и Slack. Затем их подхватывают участники сообщества и распространяют дальше.

Чтобы расширить дистрибуцию, мы делаем короткие нарезки из видео для YouTube и публикуем их в TikTok для рекламы основного канала — но не так, чтобы люди сгорали от испанского стыда при просмотре (как это бывает у некоторых контентмейкеров).

Формат вертикальных сторис сейчас, наверное, среди самых популярных — мы видим его в TikTok, на YouTube и других платформах. Хорошее обучающее видео можно нарезать на несколько 15-секундных рекламных роликов и распространять в таком формате. Наши подписчики часто репостят и комментируют видео в своих каналах — например, в Telegram-чатах про Kotlin.

Тексты чаще всего пишут технические писатели. В основном это новости: анонсы вебинаров, релизов Kotlin или библиотек. А в прошлом году мы стали выпускать ещё и более технический контент.

В сообществе программистов есть популярное международное событие — Advent of Code. Его организаторы ежедневно с 1 по 25 декабря выкладывают по одной простой задаче, которую можно решить на любом языке программирования. Раньше мы спонсировали Advent of Code, а в прошлом году сделали такой же набор задач на Kotlin и оформили их в формате видео и постов.

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

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

Кто создаёт и развивает Kotlin

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

Команда инженеров Kotlin. Они создают и поддерживают язык, компилятор и связанные с ними инструменты. А я рассказываю пользователям об этих проектах, оформляя всё в красивые истории и добавляя собственные эмоции. Если рассказать историю языком, близким пользователю, то он захочет попробовать Kotlin и его новые возможности.

Компания JetBrains. У JetBrains много продуктов, и иногда я помогаю другим командам с материалами и презентациями. Так, два года назад, ещё до пандемии, я ездил по городам с презентациями по Kotlin, TeamCity и IntelliJ IDEA.

Пользователи. Я участвую в записи подкаста «Разбор полётов». У него есть свой чат, вокруг которого сформировалось целое сообщество. Слушатели знают, что я работаю в JetBrains, а до этого работал в других проектах. Ещё я веду твиттер, посещаю российские и западные конференции, участвую в жизни их сообществ и выступаю с докладами. Люди часто задают вопросы по Kotlin мне в личку, присылают свои наработки и спрашивают моего мнения.

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

Как Developer Advocate, я должен приносить команде фидбэк от пользователей. Каким бы продуктом я ни занимался, команда, которая его производит, нуждается в обратной связи. Другой вопрос, получается ли у неё реагировать на отзывы, которые я приношу. Это не всегда возможно.

Когда я только пришёл в JetBrains, то попал в команду TeamCity. Я ещё не успел официально устроиться, а ребята уже попросили меня протестировать продукт с точки зрения пользователя. Им нужен был человек, который способен оценить удобство незамыленным взглядом, потому что они уже много лет занимались продуктом и могли не замечать очевидных проблем.

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

Как фидбэк от пользователей влияет на Kotlin

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

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

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

Долгое время любители функционального программирования, перешедшие, например, из Scala, просили добавить в Kotlin type classes. В GitHub (туда пользователи присылают запросы) было много дискуссий по этому поводу, но в итоге решение приняли — тайпклассам в Kotlin быть. Сейчас идёт активная работа над множественными ресиверами. Возможно, мы увидим их превью уже в весеннем релизе.

Почему важно следовать принципу be nice

Представители разных JVM-языков и технологий не относятся друг к другу как к конкурентам. Да, к нам, в Kotlin, часто приходят люди из Java — это наша основная аудитория. И у Java, как и у Kotlin, есть адвокаты — со многими из них я знаком, и иногда мы спорим, но до конфликтов не доходит.

Например, официальный евангелист Java в Oracle Николай Парлог (@nipafx) раньше вёл блог с выжимками из дискуссий о дизайне языка, а сейчас пишет статьи о новых возможностях. Он пытается убедить пользователей, что решения Java более правильные с точки зрения дизайна. Хоть материалы Николая иногда бывают «на грани», они всегда написаны в вежливом тоне.

Пользователи часто просят нас писать материалы, в которых Java и Kotlin сравниваются side by side. Мы сознательно отказываемся от такого формата, потому что он не соответствует нашим принципам. Вместо этого мы предоставляем migration guide, в котором говорим: «Если на Java вы писали такой-то код и читали файлы таким-то образом, то вот как вы можете сделать это на Kotlin».

Мы не противопоставляем языки, а даём рецепты тем, кто начал программировать на Kotlin после Java. Конечно, можно было бы нарисовать большой плакат, обклеить его рекламой и кричать, что мы лучше всех. Но такой подход не приветствуется в сообществе.

Возможно, некоторые читатели припомнят мне бенчмарк-войны, когда производители хешей состязались в скорости, мол, «у меня хеш на 0,002 секунды быстрее в такой-то операции». Да, такие гонки были, есть и будут, потому что за ними стоят продажи. Но производителей технологий я в таком поведении ещё ни разу не уличал.