Хабрахабр

«Ваша библиотека, как ваш ребёнок, может пойти в неожиданную для вас сторону»: интервью с создателем MobX

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

А скоро Мишель приедет в Россию выступить на HolyJS, поэтому ребята из программного комитета конференции (Дмитрий DmitryMakhnev Махнёв и Евгений bunopus Кот) подробно расспросили его: и об опенсорсе в целом, и конкретно о MobX, и о конференциях.
Евгений: Можете для начала рассказать немного о себе для тех, кто вас не знает? Мишель Уэстстрате хорошо знает обо всём этом: у его библиотеки MobX больше 17 000 звёзд на гитхабе, число её контрибьюторов давно перевалило за сотню.

Меня зовут Мишель Уэстстрате (что для большинства людей слишком сложно выговорить), я из Голландии. — Да, конечно. Я работаю в компании Mendix. Чаще всего меня знают по моей работе над MobX или над immer. Автоматизируем большое количество банковских страховых компаний и похожих систем. Мы делаем софт, который делает софт: платформу разработки приложений, которую использует множество консалтинговых компаний. А около двух лет назад я вовлёкся в мир опенсорса, с того момента активен и конкретно в 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-state-tree я намеренно выбрал таких людей, которые создают много пользовательских библиотек, и дал им права мейнтейнера. Для «основного» MobX такое не требуется, потому что там всё и так уже устаканилось, алгоритмы за последние пару лет не изменились, так что работа по поддержке небольшая. А ещё, думаю, это даёт разработчикам мотивацию и ощущение надёжности — ведь они могут помочь библиотеке работать с тем, с чем они сталкиваются. Ведь если вы активно используете библиотеку в своей повседневной работе, вы наткнётесь на паттерны или распространённые проблемы, которые я упустил.

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

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

И в итоге некоторые части кодовой базы очень неприглядные, потому что они пытаются определить, используете вы TypeScript или Babel. В MobX есть отличный пример такого: изначально я писал для TypeScript, где декораторы очень простые, а затем люди начали использовать его с Babel, где совсем другая реализация. Но это часть работы. Это звучит ужасно и это выглядит ужасно. И в этом смысле ваше дитя может пойти в направлении, которого вы не задумывали, но это нормально, потому что в конечном счёте важно, чтобы люди могли успешно использовать проект. Не обязательно любить это, но обязательно убедиться, что всё везде работает нормально.

Что вы в связи с этими переменами думаете о текущей ситуации в опенсорсе, и чего ждёте от будущего? Евгений: Разработка меняется, многое становится проще, чем было 10-20 лет назад. Станут ли всем заправлять большие компании, или наоборот, энтузиасты?

Не уверен, что будут большие перемены. — Сложный вопрос. Меня особенно впечатляют Facebook и Microsoft — то, сколько они сейчас опенсорсят и до какой степени позволяют сторонним разработчикам контрибьютить. И происходят изменения в обе стороны сразу. С другой стороны, для одиночки, вероятно, никогда не было так просто участвовать в опенсорсном проекте или создать свой, как сейчас. React Native — особенно яркий пример, где громадная часть работы приходит не со стороны Facebook. Я в последние недели работаю с Gitpod, и это отлично: я могу проверять пулл-реквесты, даже не выполняя ничего локально. Инструменты становятся всё более стандартизованными, у нас появляются отличные онлайновые IDE вроде CodeSandbox и Gitpod. Так что не знаю, каковы будут перемены. Можно просто запускать в Docker в браузере и разрабатывать там.

А сейчас в мире веба и JavaScript я вижу, что опенсорс развивается быстрее и быстрее. Евгений: Восемь лет назад, когда я был С++ разработчиком, такого опенсорсного сообщества, как сейчас, не было. Продолжится ли этот рост?

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

Евгений: То есть вы считаете, что разработка опенсорсной библиотеки может помочь на собеседовании?

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

Как и почему вы изначально начали его делать? Дмитрий: Мы поговорили об опенсорсе в целом, давайте перейдём конкретно к MobX.

У нас в Mendix давно было Windows-приложение, написанное на C#. — Хороший вопрос. React только начинался, Angular уже существовал какое-то время, Ember был довольно популярен. Несколько лет назад мы решили портировать его в веб и начали разбираться, какой стек нам использовать. И довольно быстро мы влюбились в React из-за его компонентной модели и предлагаемого им слоя абстракции.

В C# мы постоянно обновляли модель и перерисовывали весь canvas, и никто ничего не оптимизировал, потому что всё и так работало очень быстро, так что не требовалось «подходить к рендерингу по-умному». Но затем мы обнаружили, что у нас проблема с производительностью, оказалось, что полностью обновлять DOM достаточно дорого, даже в случае React. Так что мы задумались, как делать это эффективно. Но тут мы обнаружили, что в случае с DOM нельзя просто перерисовывать всё 60 раз в секунду. Одна из них — то, с какими данными мы работали и как их рендерили. Думали про immutable approach, но в нашем случае это не подходило по нескольким причинам. Наши данные очень сложно нормализовать. Одинаковая информация рендерилась в различных местах. Например пришлось бы писать селекторы для тех данных, которые рендеришь. И во-вторых, казалось, что по-прежнему придётся иметь дело со слишком большим количеством деталей.

Если не хочется говорить компонентам «Так, вот эту часть данные возьми отсюда, а вот эту вон оттуда, и тогда можешь что-то порендерить»? А что, если хочется писать такой же простой код, каким до этого был наш код на C#, «отрендерь что-то», и не хочется заморачиваться с тем, как это изменится в будущем? Где не обозначаешь ни отношения между зависимостями данных и компонентами, ни то, что когда должно рендериться. Мы начали изучать, какие технологии доступны на данный момент, и быстро пришли к парадигме, использованной в Knockout, Meteor и (по крайней мере концептуально) даже в Angular.

И оказалось, что чаще всего людей волнует нехватка предсказуемости и «отлаживаемости», то, что что-то может выполняться слишком часто, или слишком редко, или не в том порядке. Я начал разбираться, почему люди зачастую ненавидят подобные подходы, особенно когда приложение разрастается. Мы можем стремиться к той же цели, но умнее подойти к реализации. И я решил, что мы можем справиться лучше. Он не просто захватывает отношения между observes и observables, а строит целый граф зависимостей, так что можно быть уверенным, что все observers выполняются в самому эффективном порядке. И так MobX и появился. В общем, тут было взято уже существующее, но с попыткой сделать его более предсказуемым. В реактивном программировании есть понятие «glitch» — так вот, тут такое возникнуть не может.

Дмитрий: То есть если мне нравится какой-то подход, но существующие библиотеки недостаточно хороши, можно просто взять и сделать лучше, и такое может стать популярным?

Так что я писал её изначально для наших внутренних целей, а затем отправился на ReactEurope. — Да, именно! Тогда бушевали Flux-войны. Вроде бы это был 2015-й, и там было много разговоров о Flux-паттернах. И тогда я подумал «надо опенсорснуть». И я ощущал, что люди вкладывают очень много сил в проблему, которую мы уже решили. Вероятно, потому что это была не «ещё одна реализация Flux», а что-то совсем другое. И это сработало. Это было полезно многим людям.

Не возникает ли ощущение, что всё слишком усложнилось? Евгений: Изначальная идея MobX была простой, а теперь там много кода и фич.

У меня вечно есть это чувство «Хочу сделать MobX Lite». — Возникает! У меня даже есть доклад, где я подобное и делаю. По сути, можно сделать аналог MobX, уложившись в 200 строчек кода. Потом можно накинуть ещё несколько сотен строк, чтобы всё как следует оптимизировать и сделать проект быстрее в самых разных условиях. Там реализованы главные реактивные алгоритмы. Но думаю, что три четверти кода — это уже вещи на уровне API, вроде реализации декораторов. Так получается всё ядро MobX. Например, в MobX 5 по сравнению с MobX 4 изменилось то, что связано с Proxy. Есть главная идея, а есть всё то вокруг неё, что призвано сделать API как можно лучше.

Пока что большинство разработчиков использует их только в каких-то средствах разработки, а у вас в продакшне. Дмитрий: К вопросу о Proxy. Не без нюансов?

И только год назад их имплементировали во всех браузерах. — Порой непросто быть одним из первых проектов, где они используются, но Proxy появились-то давно, стабильная имплементация появилась примерно четыре года назад. Базовая имплементация появилась ещё в Chrome 8, но раньше их использование означало существенные накладные расходы, а теперь это изменилось.

Мы помним дни, когда jQuery был королём веб-разработки, и тогда речь о состоянии на клиенте не шла, мы хранили его в глобальном объекте или чём-то вроде. Евгений: Давайте поговорим о состоянии. Что изменилось? А теперь не создать приложение без управляющей состоянием библиотеки вроде Redux или MobX.

Один в том, что во времена jQuery-приложений у нас вообще было не так уж много состояния на клиенте. — Думаю, тут два ответа. Сейчас же это не очень хорошая практика из-за распространения микросервисов. Я имею в виду, что JQuery часто использовался для добавления интерактивности, когда всё состояние хранилось на сервере. Это позволило упростить создание более сложных приложений. Но более важная причина перехода от jQuery к основанной на компонентах модели вроде React в том, что она позволяет думать самодостаточными, независимыми компонентами, что лучше подходит при увеличении кодовой базы. Управление состоянием позволяет вам разделить свои состояния на более связные паттерны. Например, в нашем случае мы используем те же самые state definitions на фронтенде и бэкенде.
И я думаю, управление состоянием сделало для состояния то же, что React сделал для UI. Можно использовать самодостаточные наборы данных и логики, юнит-тестируя их без UI и лучше контролируя их.

Мы уже дошли до той точки, когда больше добавить к нему нечего? Евгений: А что вы думаете о будущем управления состоянием?

Особенно когда речь идёт об управлении состоянием, ориентированном на immutable values. — Думаю, мы до неё ещё не добрались. Но я думаю, ещё много чего можно сделать в state management. Думаю, одна из причин, по которым immer стал так популярен в этом году — в том, что он сделал обновление immutable states более нативным для JS. Я думаю, что появляется всё больше и больше подходов, например, очень интересно упомянуть GraphQL, хотя он и не очень удобен, когда нужно работать с локальными состояниями. Например, для разделения информации большинство людей использует селекторы или линзы, но мне кажется, что это не очень удобно. Так что нам ещё есть куда расти…

Евгений: Можете ли назвать фичу-две, которые вы хотели бы добавить в MobX?

Я бы хотел сделать преобразования данных более реактивными. — Есть одна вещь, которую я бы хотел сделать, но боюсь, что она будет нужна далеко не всем. Ваш фильтр должен показывать, например, все незаконченные todo. Я имею в виду вот что: представим, что у вас есть простой to-do list и вы применяете к нему фильтрацию. И сейчас нет удобного способа это выразить. Проблема состоит в том, что если что-то поменялось, то фильтр должен перебрать все todo-элементы в списке, в то время как можно обработать только изменившиеся. Но в принципе преобразования данных можно сделать реактивнее, чем они есть сейчас.

Хочется спросить о тренингах. Дмитрий: Авторов популярных библиотек зовут выступать на конференции и проводить тренинги. Какое у вас отношение, и с чем сталкиваетесь в Европе? В России их не любят, считая чем-то для начинающих.

Я лично люблю учиться одним из двух способов: или я сажусь и читаю книгу от корки до корки, или прихожу на тренинг. — Мне очень нравятся тренинги, и я считаю их отличным способом учиться. Хотя я сам создал несколько видеокурсов, так это и не полюбил. Видео — это не для меня, они вечно или слишком медленные, или слишком быстрые. И поскольку это очень практическое занятие, сразу ощущаешь, как всё работает, каково оно вообще и как можешь применить это. Когда я начал осваиваться с Docker, отправился на тренинг. По-моему, главное в них — то, что это быстрейший способ освоить новую технологию, с которой ты ещё особо не был знаком. Для меня тренинги — это не «для джуниоров». Книга — это скорее про общую картину, по которой можешь понять, насколько для тебя вообще что-то релевантно. Думаю, это главная ценность, и от книги такого не получишь. Там в перерывах люди подходят с конкретными вопросами о конкретных сложностях, с которыми столкнулись, или спрашивают о применении усвоенного в их конкретной ситуации. Но если по-настоящему хочешь начать работать с чем-то, или серьёзно обдумываешь такой вариант, тренинг будет быстрее всего. Я очень верю в такую форму освоения новых технологий. Это преимущество тренингов: можно поговорить с кем-то, задать вопросы, относящиеся непосредственно к вашей ситуации.

Что вы думаете? Евгений: Также многие (по крайней мере, в России) считают, что не стоит ходить на конференции, потому что можно почитать тексты на Medium или посмотреть видео на YouTube.

Во всяком случае, моё личное мнение такое. — Думаю, в отличие от тренингов, главная цель конференции — не в обучении. Тем, что происходит в индустрии, тем, что люди делают… Захотеть учиться. Главная причина пойти на конференцию — вдохновиться. Когда приходите на конференцию с коллегами, постарайтесь не слишком много говорить с ними. Вместе с этим приходит и нетворкинг. Вы знаете, какие проблемы они решают. Их вы и так уже знаете. Можно увидеть, что они делают, какие проблемы решают, и какой у них опыт с библиотекой, о которой кто-то делал доклад утром. Куда интереснее говорить со случайными людьми, например, стоя в очереди за едой. Многие люди боятся подходить к спикерам, но для меня как спикера (и, думаю, для большинства других спикеров) общаться со зрителями — это как раз интересная часть конференции. И ищите спикеров, если у вас есть вопросы к ним. Так что не смущайтесь и обращайтесь. Ну, лучше не обращайтесь ко мне за пять минут до моего выхода на сцену, но всё остальное время я стараюсь быть очень доступным.

Вы впервые окажетесь в России — чего ожидаете от Москвы и от конференции? Евгений: Отличный совет.

А ещё я заметил, что в России есть множество пользователей MobX. — Я определённо хочу посмотреть на Москву и определённо буду ей потрясён. Так что надеюсь встретиться на конференции со многими пользователями MobX. Вижу это по трекеру, по коммитам.

Там он подробнее поговорит про state management. Увидеть Мишеля и задать ему вопросы можно будет на HolyJS 2018 Moscow, которая пройдёт 24-25 ноября. Посмотреть описание докладов конференции можно на её сайте.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть