Каково живётся создателям популярных опенсорсных библиотек? Конечно, приятно, когда результат твоей работы помогает многим людям по всей планете. Но не оказываешься ли завален задачами, которые даже не являются твоей основной работой? Как с этим справляться? Насколько смело можно делегировать полномочия?
Мишель Уэстстрате хорошо знает обо всём этом: у его библиотеки MobX больше 17 000 звёзд на гитхабе, число её контрибьюторов давно перевалило за сотню. А скоро Мишель приедет в Россию выступить на HolyJS, поэтому ребята из программного комитета конференции (Дмитрий DmitryMakhnev Махнёв и Евгений bunopus Кот) подробно расспросили его: и об опенсорсе в целом, и конкретно о MobX, и о конференциях.
Евгений: Можете для начала рассказать немного о себе для тех, кто вас не знает?
— Да, конечно. Меня зовут Мишель Уэстстрате (что для большинства людей слишком сложно выговорить), я из Голландии. Чаще всего меня знают по моей работе над MobX или над immer. Я работаю в компании Mendix. Мы делаем софт, который делает софт: платформу разработки приложений, которую использует множество консалтинговых компаний. Автоматизируем большое количество банковских страховых компаний и похожих систем. Я занимаюсь технической стороной — то есть тем, что мне нравится. А около двух лет назад я вовлёкся в мир опенсорса, с того момента активен и конкретно в React-сообществе, и вообще в JS-сообществе.
Евгений: Чем именно занимаетесь в Mendix, вы там техлид?
— Да. У меня там несколько разных ролей, и главная из них — техлидская. По сути, это означает, что я отвечаю за выбор технических решений одного из наших «трайбов». Таким образом я работаю над продуктом, который является окружением для мобильных приложений. Мы работаем над ним с четырьмя командами, и в основном я занимаюсь принятием правильных архитектурных и технологических решений. Кроме того, я по-прежнему программирую. Это одна часть моей работы.
А другая — участие в опенсорсном сообществе. Это «двусторонняя» деятельность. С одной стороны, мы занимаемся клёвыми техническими штуками, которыми хочется делиться на конференциях, и я выступаю сам или поощряю коллег выступить. А с другой стороны, в частом посещении конференций хорошо и противоположное: обнаруживаешь что-то, что может быть полезно для нас, тогда мы изучаем это и включаем в наш стек.
Евгений: В описании вашего Твиттера упомянут «OSS-евангелизм». Что это, и почему оно важно для вас?
— Первая причина, по которой это важно: я обнаружил, что если переводишь свою разработку в опенсорс, это совершенно не экономит тебе время, зато очень помогает в тестировании и повышает качество. Потому что библиотеку вроде MobX используют в совсем разных условиях. И я думаю, что в этом смысле опенсорс даёт такое преимущество, которое очень сложно получить другим способом.
А вторая: я верю, что наши «низкоуровневые» разработки не определяют компанию, так что почему бы ими не поделиться. Я имею в виду, что компанию делает более или менее конкурентоспособной продукт, который сделан на основе её технологий — а не эти технологии сами по себе. И от коллаборации все выигрывают, это позволяет разработке в целом ускориться.
Евгений: Порой говорят, что «безденежный» опенсорс — это вообще-то очень дорогое удовольствие. Проекты вроде Linux требуют кучи денег от гигантов масштаба Oracle и Microsoft. Это так? Может ли опенсорсное сообщество существовать без больших вендоров и денег?
— Думаю, зависит от конкретной ситуации. Есть маленькие библиотеки, которые могли бы так существовать. Но проекты вроде упомянутого ядра Linux или React Native настолько сложные, и от них зависит столько людей, что там необходима надёжная финансовая модель. В таком случае без больших спонсоров было бы очень сложно. Но я не думаю, что это проблема. Думаю, важнее, чтобы компании учились брать ответственность, чем чтобы мы учились обходиться без них.
Eвгений: Например, если Facebook придёт к вам и скажет «Давайте мы купим MobX или будем спонсировать, чтобы разработка шла под нашим брендом»?
— Ну, вообще-то, они уже спонсируют! Даже забавно, но Facebook — один из спонсоров MobX на Open Collective. Так что в каком-то смысле это уже произошло. По-моему, Open Collective — отличный пример того, как мы можем улучшить финансовое положение опенсорса. Он позволяет компаниям спонсировать разработку подходящим им образом, потому что там в финансовом смысле серьёзный подход, с инвойсами и тому подобным.
В Mendix мне, по сути, и так в значительной степени платят за работу над MobX, так что я не заинтересован полностью перейти в Facebook. Понимаю, что кого-то другого это может заинтересовать, но не вижу в этом проблемы. По-моему, если лицензия остаётся опенсорсной, нет ничего страшного в том, что продукт выходит под брендом главного спонсора. Это всё равно что смотреть футбол по телевизору: если все могут увидеть игру, то нет особой разницы, какой логотип на футболках.
Евгений: Если большая компания спонсирует библиотеку, то не может ли она сказать «Раз мы столько платим, то давайте, пожалуйста, сделаете нам в ней вот это»?
— Не сталкивался с таким, по крайней мере, так, чтобы это становилось проблемой. Если не ошибаюсь, в webpack используют такую модель, там возможно платить за фичи. Так что некоторый риск есть, но думаю, тут ответственность мейнтейнеров следить, чтобы проект оставался верен своей философии. Но в пределах этой философии, скорее всего, есть много пространства для манёвра. И кроме того, в опенсорсе, если вдруг что-то идёт совершенно не так, хотя бы остаётся возможность форка.
Евгений: Разработка открытого обеспечения похожа на кривую: сначала ты делаешь библиотеку, никому больше не нужную, потом ей начинают пользоваться люди, потом она набирает тысячи звёзд на гитхабе и так далее. Когда опенсорсный проект становится популярным, он может начать требовать много времени. Сколько вы тратите на MobX?
— В последнее время не очень много. MobX сейчас довольно стабилен. В прошлом много потратил, конечно. Там было очень по-разному. Думаю, в течение первой пары лет это было несколько вечеров в неделю, а ещё много мелких моментов, когда просто отвечаешь на мелкие issue или вопросы в Твиттере. Эти мелочи не ощущаются как существенное вложение времени, но думаю, что суммарно они заметно добавляют. Однако это очень сложно измерить. Это как проверять рабочую почту — проверяешь issue и быстро отправляешь ответ.
Евгений: Как быть продуктивным в ситуации, когда ты разработчик, создал библиотеку, она стала популярной и требует всё больше времени? Вам повезло, у вас есть возможность заниматься ей в рабочее время. Но если уже есть работа и хобби, а проект становится популярнее?
— Ну, когда я начинал работать над MobX, это тоже было только в свободное время, рабочее добавилось уже когда проект добился популярности. Но у меня есть несколько советов. Я заметил, что есть несколько правил, которые мне помогли.
Первое: следить за актуальностью документации. Если вы получили один и тот же вопрос три-четыре раза, обязательно убедитесь, что зафиксировали ответ в документации. Потому что это в итоге сэкономит вам время.
Второе: будьте очень разборчивы в том, какие issue принимаете. В самом начале, как только вам сообщают об ошибке, вы пытаетесь воспроизвести проблему, основываясь на имеющемся описании. И в части случаев обнаруживаете, что это невозможно, а время уже затрачено. Поэтому сейчас я требую от issue что-то, что могу напрямую запустить, будь то код в «песочнице» или пулл-реквест с юнит-тестами. Что-то, позволяющее мне определить, где проблема — в библиотеке или на стороне пользователя. Это очень важно, потому что позволяет мне и сэкономить время, и убедиться, что автор issue готов инвестировать своё время. Некоторые говорят «У меня нет времени помогать в воспроизведении бага», и возникает ощущение «Ну, тогда у меня нет времени помогать решать вашу проблему». Ведь человеку, вероятно, платят за ту работу, в которой он использует мою библиотеку — почему тогда я должен инвестировать своё свободное время в его проблему? В общем, такая избирательность помогает, хотя и заставляет почувствовать себя несколько менее ответственным, ведь хочется помогать вообще всем. Но я обнаружил, что «помогать всем» попросту нереалистично.
А ещё, поскольку я занимаюсь несколькими библиотеками, я не отвечаю на все issue моментально, а «прыгаю» от одной библиотеки к другой: работаю поочерёдно по несколько дней над каждой, а затем перехожу к следующей. И я могу ответить вам за считанные минуты, если вы написали по поводу той, которой занимаюсь сейчас, а могу не отвечать днями, если до вашей ещё не дошла очередь. Это помогает мне реже переключать контекст.
Все эти советы помогают, когда твоя библиотека начинает набирать популярность.
Евгений: Когда создатель популярной библиотеки отвечает «не могу воспроизвести, напишите юнит-тест», это не вызывает у людей ощущение «он зазнался и не хочет помогать»?
— Я сталкивался с таким эффектом, но очень редко. Думаю, обычно пользователь понимает и то, что мейнтейнеры довольно заняты, и то, что проблема с высокой вероятностью на его стороне. Думаю, если вы используете фильтр Lodash и у вас возникает проблема, то тут непроизвольно будет ощущение «наверное, это у меня что-то не так, ведь Lodash используют все». Так что большинство людей понимает, что они должны быть аккуратны в вопросах.
Евгений: Когда библиотека становится популярной и требует больше времени, насколько стоит делиться своей ролью контрибьютора, предоставляя права другим участникам сообщества?
— Это прекрасная идея, я обычно даю права контрибьютора, как только вижу от одного человека несколько хороших пулл-реквестов (или даже один пулл-реквест, если он большой). По-моему, это отлично работает. Например, в MobX-state-tree основная часть работы сейчас делается другими людьми, не мной. И есть другие части кодовой базы, в которых люди разбираются лучше меня, и замечательно, что всё пришло к такому состоянию. Для «основного» MobX такое не требуется, потому что там всё и так уже устаканилось, алгоритмы за последние пару лет не изменились, так что работа по поддержке небольшая. Но в случае с MobX-state-tree я намеренно выбрал таких людей, которые создают много пользовательских библиотек, и дал им права мейнтейнера. Ведь если вы активно используете библиотеку в своей повседневной работе, вы наткнётесь на паттерны или распространённые проблемы, которые я упустил. А ещё, думаю, это даёт разработчикам мотивацию и ощущение надёжности — ведь они могут помочь библиотеке работать с тем, с чем они сталкиваются.
Евгений: Нет при этом ощущения, что библиотека, как ребёнок, отбивается от рук? Возможно, вы не во всём согласны с тем, как именно её развивают другие люди?
— Порой немного бывает. Но думаю, что это нормально. Вы провели отличную аналогию с детьми: со временем они вырастают, им становится 18, и тогда вам надо их отпустить, потому что им пришло время самим находить свой путь. Думаю, в некоторой степени с опенсорсными библиотеками так же. Если они успешны, то начинаешь сталкиваться с более сложными ситуациями. Начинаешь иметь дело со случаями, с которыми вообще-то не хотел бы иметь дела. Код уже не будет тем прекрасным, чистым и минималистичным кодом, которого хотелось изначально. Это неизбежно.
В MobX есть отличный пример такого: изначально я писал для TypeScript, где декораторы очень простые, а затем люди начали использовать его с Babel, где совсем другая реализация. И в итоге некоторые части кодовой базы очень неприглядные, потому что они пытаются определить, используете вы TypeScript или Babel. Это звучит ужасно и это выглядит ужасно. Но это часть работы. Не обязательно любить это, но обязательно убедиться, что всё везде работает нормально. И в этом смысле ваше дитя может пойти в направлении, которого вы не задумывали, но это нормально, потому что в конечном счёте важно, чтобы люди могли успешно использовать проект.
Евгений: Разработка меняется, многое становится проще, чем было 10-20 лет назад. Что вы в связи с этими переменами думаете о текущей ситуации в опенсорсе, и чего ждёте от будущего? Станут ли всем заправлять большие компании, или наоборот, энтузиасты?
— Сложный вопрос. Не уверен, что будут большие перемены. И происходят изменения в обе стороны сразу. Меня особенно впечатляют Facebook и Microsoft — то, сколько они сейчас опенсорсят и до какой степени позволяют сторонним разработчикам контрибьютить. React Native — особенно яркий пример, где громадная часть работы приходит не со стороны Facebook. С другой стороны, для одиночки, вероятно, никогда не было так просто участвовать в опенсорсном проекте или создать свой, как сейчас. Инструменты становятся всё более стандартизованными, у нас появляются отличные онлайновые IDE вроде CodeSandbox и Gitpod. Я в последние недели работаю с Gitpod, и это отлично: я могу проверять пулл-реквесты, даже не выполняя ничего локально. Можно просто запускать в Docker в браузере и разрабатывать там. Так что не знаю, каковы будут перемены.
Евгений: Восемь лет назад, когда я был С++ разработчиком, такого опенсорсного сообщества, как сейчас, не было. А сейчас в мире веба и JavaScript я вижу, что опенсорс развивается быстрее и быстрее. Продолжится ли этот рост?
— Думаю, движение продолжится. Одна из причин, по-моему, в следующем: и компании, и разработчики всё лучше понимают, что опенсорс не только полезен тем, кто его разрабатывает или использует, но ещё и помогает находить сотрудников. Посмотрев на участие человека в опенсорсе, можно понять о нём больше, чем если собеседовать его целый день. То, как он отвечает на issue или заводит их, показывает многое. Думаю, разработчики и компании всё больше осознают значимость этого.
Евгений: То есть вы считаете, что разработка опенсорсной библиотеки может помочь на собеседовании?
— Именно. Если вы компания и у вас есть такие библиотеки, не привязанные жёстко к вашему API, это отлично, потому что люди придут участвовать — и они могут оказаться именно теми, кто вам нужен. И если вы наймёте кого-то из ваших контрибьюторов, им будет проще влиться, а вы будете лучше понимать, чего ждать. Думаю, по одной только этой причине было опенсорснуто много интересного.
Дмитрий: Мы поговорили об опенсорсе в целом, давайте перейдём конкретно к MobX. Как и почему вы изначально начали его делать?
— Хороший вопрос. У нас в Mendix давно было Windows-приложение, написанное на C#. Несколько лет назад мы решили портировать его в веб и начали разбираться, какой стек нам использовать. React только начинался, Angular уже существовал какое-то время, Ember был довольно популярен. И довольно быстро мы влюбились в React из-за его компонентной модели и предлагаемого им слоя абстракции.
Но затем мы обнаружили, что у нас проблема с производительностью, оказалось, что полностью обновлять DOM достаточно дорого, даже в случае React. В C# мы постоянно обновляли модель и перерисовывали весь canvas, и никто ничего не оптимизировал, потому что всё и так работало очень быстро, так что не требовалось «подходить к рендерингу по-умному». Но тут мы обнаружили, что в случае с DOM нельзя просто перерисовывать всё 60 раз в секунду. Так что мы задумались, как делать это эффективно. Думали про immutable approach, но в нашем случае это не подходило по нескольким причинам. Одна из них — то, с какими данными мы работали и как их рендерили. Одинаковая информация рендерилась в различных местах. Наши данные очень сложно нормализовать. И во-вторых, казалось, что по-прежнему придётся иметь дело со слишком большим количеством деталей. Например пришлось бы писать селекторы для тех данных, которые рендеришь.
А что, если хочется писать такой же простой код, каким до этого был наш код на C#, «отрендерь что-то», и не хочется заморачиваться с тем, как это изменится в будущем? Если не хочется говорить компонентам «Так, вот эту часть данные возьми отсюда, а вот эту вон оттуда, и тогда можешь что-то порендерить»? Мы начали изучать, какие технологии доступны на данный момент, и быстро пришли к парадигме, использованной в Knockout, Meteor и (по крайней мере концептуально) даже в Angular. Где не обозначаешь ни отношения между зависимостями данных и компонентами, ни то, что когда должно рендериться.
Я начал разбираться, почему люди зачастую ненавидят подобные подходы, особенно когда приложение разрастается. И оказалось, что чаще всего людей волнует нехватка предсказуемости и «отлаживаемости», то, что что-то может выполняться слишком часто, или слишком редко, или не в том порядке. И я решил, что мы можем справиться лучше. Мы можем стремиться к той же цели, но умнее подойти к реализации. И так MobX и появился. Он не просто захватывает отношения между observes и observables, а строит целый граф зависимостей, так что можно быть уверенным, что все observers выполняются в самому эффективном порядке. В реактивном программировании есть понятие «glitch» — так вот, тут такое возникнуть не может. В общем, тут было взято уже существующее, но с попыткой сделать его более предсказуемым.
Дмитрий: То есть если мне нравится какой-то подход, но существующие библиотеки недостаточно хороши, можно просто взять и сделать лучше, и такое может стать популярным?
— Да, именно! Так что я писал её изначально для наших внутренних целей, а затем отправился на ReactEurope. Вроде бы это был 2015-й, и там было много разговоров о Flux-паттернах. Тогда бушевали Flux-войны. И я ощущал, что люди вкладывают очень много сил в проблему, которую мы уже решили. И тогда я подумал «надо опенсорснуть». И это сработало. Вероятно, потому что это была не «ещё одна реализация Flux», а что-то совсем другое. Это было полезно многим людям.
Евгений: Изначальная идея MobX была простой, а теперь там много кода и фич. Не возникает ли ощущение, что всё слишком усложнилось?
— Возникает! У меня вечно есть это чувство «Хочу сделать MobX Lite». По сути, можно сделать аналог MobX, уложившись в 200 строчек кода. У меня даже есть доклад, где я подобное и делаю. Там реализованы главные реактивные алгоритмы. Потом можно накинуть ещё несколько сотен строк, чтобы всё как следует оптимизировать и сделать проект быстрее в самых разных условиях. Так получается всё ядро MobX. Но думаю, что три четверти кода — это уже вещи на уровне API, вроде реализации декораторов. Есть главная идея, а есть всё то вокруг неё, что призвано сделать API как можно лучше. Например, в MobX 5 по сравнению с MobX 4 изменилось то, что связано с Proxy.
Дмитрий: К вопросу о Proxy. Пока что большинство разработчиков использует их только в каких-то средствах разработки, а у вас в продакшне. Не без нюансов?
— Порой непросто быть одним из первых проектов, где они используются, но Proxy появились-то давно, стабильная имплементация появилась примерно четыре года назад. И только год назад их имплементировали во всех браузерах. Базовая имплементация появилась ещё в Chrome 8, но раньше их использование означало существенные накладные расходы, а теперь это изменилось.
Евгений: Давайте поговорим о состоянии. Мы помним дни, когда jQuery был королём веб-разработки, и тогда речь о состоянии на клиенте не шла, мы хранили его в глобальном объекте или чём-то вроде. А теперь не создать приложение без управляющей состоянием библиотеки вроде Redux или MobX. Что изменилось?
— Думаю, тут два ответа. Один в том, что во времена jQuery-приложений у нас вообще было не так уж много состояния на клиенте. Я имею в виду, что JQuery часто использовался для добавления интерактивности, когда всё состояние хранилось на сервере. Сейчас же это не очень хорошая практика из-за распространения микросервисов. Но более важная причина перехода от jQuery к основанной на компонентах модели вроде React в том, что она позволяет думать самодостаточными, независимыми компонентами, что лучше подходит при увеличении кодовой базы. Это позволило упростить создание более сложных приложений. Например, в нашем случае мы используем те же самые state definitions на фронтенде и бэкенде.
И я думаю, управление состоянием сделало для состояния то же, что React сделал для UI. Управление состоянием позволяет вам разделить свои состояния на более связные паттерны. Можно использовать самодостаточные наборы данных и логики, юнит-тестируя их без UI и лучше контролируя их.
Евгений: А что вы думаете о будущем управления состоянием? Мы уже дошли до той точки, когда больше добавить к нему нечего?
— Думаю, мы до неё ещё не добрались. Особенно когда речь идёт об управлении состоянием, ориентированном на immutable values. Думаю, одна из причин, по которым immer стал так популярен в этом году — в том, что он сделал обновление immutable states более нативным для JS. Но я думаю, ещё много чего можно сделать в state management. Например, для разделения информации большинство людей использует селекторы или линзы, но мне кажется, что это не очень удобно. Я думаю, что появляется всё больше и больше подходов, например, очень интересно упомянуть GraphQL, хотя он и не очень удобен, когда нужно работать с локальными состояниями. Так что нам ещё есть куда расти…
Евгений: Можете ли назвать фичу-две, которые вы хотели бы добавить в MobX?
— Есть одна вещь, которую я бы хотел сделать, но боюсь, что она будет нужна далеко не всем. Я бы хотел сделать преобразования данных более реактивными. Я имею в виду вот что: представим, что у вас есть простой to-do list и вы применяете к нему фильтрацию. Ваш фильтр должен показывать, например, все незаконченные todo. Проблема состоит в том, что если что-то поменялось, то фильтр должен перебрать все todo-элементы в списке, в то время как можно обработать только изменившиеся. И сейчас нет удобного способа это выразить. Но в принципе преобразования данных можно сделать реактивнее, чем они есть сейчас.
Дмитрий: Авторов популярных библиотек зовут выступать на конференции и проводить тренинги. Хочется спросить о тренингах. В России их не любят, считая чем-то для начинающих. Какое у вас отношение, и с чем сталкиваетесь в Европе?
— Мне очень нравятся тренинги, и я считаю их отличным способом учиться. Я лично люблю учиться одним из двух способов: или я сажусь и читаю книгу от корки до корки, или прихожу на тренинг. Видео — это не для меня, они вечно или слишком медленные, или слишком быстрые. Хотя я сам создал несколько видеокурсов, так это и не полюбил. Когда я начал осваиваться с Docker, отправился на тренинг. И поскольку это очень практическое занятие, сразу ощущаешь, как всё работает, каково оно вообще и как можешь применить это. Для меня тренинги — это не «для джуниоров». По-моему, главное в них — то, что это быстрейший способ освоить новую технологию, с которой ты ещё особо не был знаком. Думаю, это главная ценность, и от книги такого не получишь. Книга — это скорее про общую картину, по которой можешь понять, насколько для тебя вообще что-то релевантно. Но если по-настоящему хочешь начать работать с чем-то, или серьёзно обдумываешь такой вариант, тренинг будет быстрее всего. Там в перерывах люди подходят с конкретными вопросами о конкретных сложностях, с которыми столкнулись, или спрашивают о применении усвоенного в их конкретной ситуации. Это преимущество тренингов: можно поговорить с кем-то, задать вопросы, относящиеся непосредственно к вашей ситуации. Я очень верю в такую форму освоения новых технологий.
Евгений: Также многие (по крайней мере, в России) считают, что не стоит ходить на конференции, потому что можно почитать тексты на Medium или посмотреть видео на YouTube. Что вы думаете?
— Думаю, в отличие от тренингов, главная цель конференции — не в обучении. Во всяком случае, моё личное мнение такое. Главная причина пойти на конференцию — вдохновиться. Тем, что происходит в индустрии, тем, что люди делают… Захотеть учиться. Вместе с этим приходит и нетворкинг. Когда приходите на конференцию с коллегами, постарайтесь не слишком много говорить с ними. Их вы и так уже знаете. Вы знаете, какие проблемы они решают. Куда интереснее говорить со случайными людьми, например, стоя в очереди за едой. Можно увидеть, что они делают, какие проблемы решают, и какой у них опыт с библиотекой, о которой кто-то делал доклад утром. И ищите спикеров, если у вас есть вопросы к ним. Многие люди боятся подходить к спикерам, но для меня как спикера (и, думаю, для большинства других спикеров) общаться со зрителями — это как раз интересная часть конференции. Ну, лучше не обращайтесь ко мне за пять минут до моего выхода на сцену, но всё остальное время я стараюсь быть очень доступным. Так что не смущайтесь и обращайтесь.
Евгений: Отличный совет. Вы впервые окажетесь в России — чего ожидаете от Москвы и от конференции?
— Я определённо хочу посмотреть на Москву и определённо буду ей потрясён. А ещё я заметил, что в России есть множество пользователей MobX. Вижу это по трекеру, по коммитам. Так что надеюсь встретиться на конференции со многими пользователями MobX.
Увидеть Мишеля и задать ему вопросы можно будет на HolyJS 2018 Moscow, которая пройдёт 24-25 ноября. Там он подробнее поговорит про state management. Посмотреть описание докладов конференции можно на её сайте.
