Недавно к команде Skyeng присоединился Александр Макаров, давний участник core team фреймворка Yii. Я не мог пропустить такой инфоповод и отправился в Воронеж, чтобы порасспросить Сашу про жизнь в мире open source, перспективы участия в разработке свободного ПО и совмещение такой разработки с полной ставкой.

Как ты стал членом core team Yii?

Работал Java-разработчиком в Murano Software, делал свои проекты: блог, какие-то небольшие подработки по верстке. Хостинг для Java в то время был дорог, поэтому стал двигаться в сторону PHP, тем более, что в универе имел с ним дело. Сперва писал на голом PHP, но все превращалось в кашу, поэтому начал изучать фреймворки. Посмотрел Zend, там деплой попроще, но все равно ява явой, слишком наворочено было для моих целей. Перебрал еще несколько, остановился на CodeIgniter – этот фреймворк мне, в принципе, понравился, простенький.

Запустил на нем первый бложек, все было хорошо, начали прилетать проекты, сложность росла, и в какой-то момент что-то сломалось. Залез внутрь, ужаснулся, попытался исправить… В то время EllisLab начала фокусироваться на CMS, а на CodeIgniter забивать, поэтому приходилось рассчитывать на свои силы, ну и искать коллег по фреймворку. Скооперировались с Антоном [Исайкиным] и сделали сообщество code-igniter.ru, где перевели доки, отвечали на вопросы и в итоге вырастили хорошее комьюнити. Мы предприняли немало попыток протащить в ядро что-то свое, но они не увенчались успехом, ничего с фреймворком не менялось, картина была печальна. Начал снова изучать другие варианты, случайно набрел на сайт Yii; он в тот момент был дико страшный, с заблуренным логотипом. Несмотря на это, почитал доки – понял, что там все логично, разложено по полочкам, абстракции не чрезмерные, развернул тестовое приложение – все классно.

Для своего следующего проекта взял Yii, зашло хорошо, потом еще, ну и полезли какие-то мелочи. Начал писать тикеты, потом предлагать решения, выкладывать патчи, потом Тян [Qiang Xue] сказал «твои патчи долго ревьювить, а качество довольно высокое, поэтому давай сразу в мастер». Так я и попал в core team. Тогда же мы запустили yiiframework.ru, я его анонсировал на форумах нашего имевшегося сообщества, оттуда переползло много народу, поэтому база быстро выросла.

Мы поддерживали версию 1.1, потом запланировали 1.2, которая так и не вышла, зато вышла 2.0, к которой я уже основательно приложил руку. В 2015-м году Тян вышел на новую работу, у него на фреймворк практически не осталось времени, и он передал проект пятерым самым активным участникам. Теперь нет отдельного человека, который все решает, теперь у нас есть внутренний слак, а все важные решения – коллективные.



Что из себя представляет core team? Как ведется общение? Как распределяются задачи, есть ли какие-то дедлайны?

В core team сейчас пять человек: Дима Науменко из Киева, Паша Климов из Донецка, Карстен Брендт из Германии (он, как и я, давно уже в команде, причем он знает русский язык), Буджвин [Boudewijn Vahrmeijer aka dynosource] из Нидерландов. Это основные участники, сейчас еще сформировали дополнительные команды из самых активных ревьюверов и контрибуторов, дали им больше прав, чтобы они могли работать с пулл-реквестами и даже некоторыми репозиториями напрямую. Их 13 человек, и еще есть около двадцати активных контрибуторов, а вообще людей, которые участвуют в разработке, за две сотни.

Общаемся в слаке по-английски. Списываемся 2-3 раза в неделю, иногда созваниваемся, встречаемся на конференциях. Активное общение случается, когда начинаем спорить, обсуждать суперновость или готовимся к конференции, а так каждый в меру своих сил берет тикеты и пытается их разрулить, или проектирует следующие версии. Поскольку у всех фултайм работы, у нас нет чётких дедлайнов, они появляются, только если случается что-то критичное.

А как вообще совмещается open source разработка и фултайм?

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

Стоит ли вообще заниматься опенсорсом?

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

Для меня главный результат – удалось за 5 лет поработать с ребятами намного опытнее меня, это было в тот период, когда я перестал расти и начал думать, что учиться мне больше нечему. Это неправда, учиться всегда есть чему, главное найти, у кого.

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



К каким проблемам надо быть готовым?

Если запилил библиотеку и она стала сверхпопулярной, с одной стороны хорошо – приглашают на конференции, предлагают достойные позиции, а с другой она начинает пожирать твое время и самого тебя морально. С определенного момента опенсорс можно перевести в режим фултайм работы, но до того это хобби для себя, надо получать удовольствие и не считать его основной целью жизни. Иначе случится выгорание и вместо талантливого разработчика будет безжизненный человек, который не хочет делать ничего. У нас в команде несколько человек так сгорело – классно контрибутили, но слишком часто и интенсивно, и в итоге истощились.

Надо быть готовым к тому, что неизбежно появится туча очень, очень громких хейтеров. Надо учиться фильтровать это дело, отсеивать, это непросто. Один недовольный громче сотни довольных, это всегда так. Например, недавно запустили несколько опросов на фейсбуке по следующей версии, пошли комментарии. В них полно конструктива, но, конечно, там сразу же появилась тема «лучшее, что вы можете сделать, это прибить все нафиг, чтобы все писали на Symfony и Laravel». Это довольно странная позиция, учитывая, что у той же Symfonу на Гитхабе 13 тысяч звезд, ненамного больше, чем у нас. Я понимаю, что с точки зрения теории Yii не самая правильная штука, мы срезали углы, сейчас я бы многое переписал, и мы будем этим заниматься, но хейтерство напрягает, и к нему надо быть готовым. Если не можешь выносить критику — лучше, наверное, в опенсорс не соваться.

Помогает ли опенсорс найти крутую работу? Расскажи, где работал, уже будучи в core team.

Я работал на нью-йоркский Clevertech, живя в Воронеже. Оказался там именно из-за Yii – сказали, твой опыт развития нам интересен, у нас есть свои наработки, которые надо задокументировать и выложить в опенсорс. Так как это я умею лучше всего, то с этого и начал, потом написал небольшой открытый вики-движок. То, что они начали выкладывать свои наработки в опенсорс, очень помогло потом затянуть в компанию много классных разработчиков. Это полезно для HR, для удержания разработчиков, и круто для кода – его в опенсорсе причесывают, на него набегает множество народу и начинает тестировать на безумные кейсы, которые ты даже представить себе не можешь, и библиотека вылизывается до идеала за короткое время.

Через какое-то время Тян позвал в норвежский стартап stay.com. Там была команда, с которой я очень хотел работать, поэтому передал дела одному из основных разработчиков и перебрался в Stay.

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

Кстати, со «Стеем» я понял, что главное в продукте, как правило, не алгоритм, а грамотные бизнес-процессы и знания внутри компании, которые сложно понять постороннему из-за отсутствия опыта их построения с нуля. У нас на соседних улицах открылась пара офисов, копировавших наш сервис и делавших то же самое, но они слабо понимали, что происходит, потому что взяли за основу готовое решение, не видя его изнанки.



Можно ли прокормиться опенсорсом? Каковы твои успехи на Patreon?

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

Patreon был экспериментом, когда «Стей» закрылся. Идея заниматься фреймворком как фултаймом была давно. Впрочем, особо радужных надежд я на краудфандинг не возлагал, но почему бы не попробовать. Получилось очень хорошо, сообщество оказалось отзывчивым, накидали сумму, которая позволила целый год заниматься фреймворком на постоянной основе. Однако в определенный момент я начал понимать, что ржавею без реальных проектов. Когда заканчиваются новые идеи для фреймворка, я теряю видение, не понимаю, куда двигаться, и одна из причин, почему принял предложение Skyeng – здесь можно набраться нового опыта, чему-то научиться.

В общем, когда я на Patreon объявил, что выхожу на работу, самые крутые спонсоры (такие, как HumHub, CraftCMS, Luya) либо снизили свои платежи, либо ушли, что логично – они хотят поддерживать фреймворк, а не лично Сашу Макарова. Но все равно остается неплохая сумма на текущую работу из маленьких пожертвований, за что я очень благодарен.

Мы хотим зарегистрировать фонд, чтобы спонсоры давали деньги именно на Yii, и они распределялись между всеми участниками разработки и тратились на сервера, развитие, дизайн – на все то, что сейчас каждый из нас оплачивает из своего кармана. Права на Yii у Тяна (он их зарегистрировал для защиты доменного имени, потому что иначе оно бы в определенный момент ушло к Нинтендо), он не против.

Вообще, опенсорсный фреймворк – дорогое удовольствие?

Да, достаточно. Затраты зависят от этапа – например, если только что-то сделал, и о нем еще никто не знает, лучший способ продвижения – активно ездить по всем конференциям и рассказывать. А это накладно, ведь расходы никто не возмещает, в Штатах и в Европе это не принято.



Ты часто указываешь конференции среди «плюшек» для опенсорс-разработчика. А в чем их польза?

Ну, во-первых, мне нравится. Круто пообщаться с людьми. В свое время я на них узнавал очень много нового, в то время, когда еще не принято было все массово выкладывать в Гитхаб. Конференции были основным источником информации, особенно кулуары. Ну и заведенные там знакомства очень помогают в работе – например, когда надо сказать Яндексу, что что-то сломалось, самый эффективный способ – дернуть кого-нибудь изнутри. И это еще нормально по сравнению с Гуглом.

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

Почему решил работать в Skyeng?

Когда появилось чувство, что «ржавею», начал искать, чем бы заняться. Сперва запустил в Воронеже кофейню (скоро вторую откроем), потом нагрузка опять упала, я начал лениться, надо было что-то с этим делать. Походил на собеседования, понял, что могу в голове оценивать алгоритмы и писать код на бумажке (раньше думал, что нет). Было 5-6 очень хороших предложений, но они не устроили по некоторым условиям. Например, в контракте было прописано, что права на весь написанный мной на работе код переходят работодателю. Это значит, что, если я что-то случайно пушну в Yii, права уйдут им, и менять этот пункт они не хотели.

В общем, прилетает предложение от Skyeng, а поскольку я ни от чего сходу не отказываюсь, то почему бы и нет. Полез изучать, что это, почитал статьи, начал понимать, что все не так просто, что за фасадом скрывается что-то глубокое. На собеседовании рассказали подробнее, убедился, что это именно то, что мне нужно в плане сложности задач, да и компания активно растет, значит, я смогу привнести то, что привнес в другие проекты. И тут говорят, что редактировать контракт – вообще не вопрос, ну все и стало ясно.

Занимаюсь пока поддержкой старого бэкенда, написанного на Yii. Буду его понемногу обновлять и переводить на Symfony. Я не против, в компании должен быть единый стандарт.

Что посоветуешь людям, которые таки решатся отправиться в опенсорс?

Реальность такова, что опенсорс проекты – то же самое, что стартапы, выстреливает очень маленький процент. Но в опенсорсе сразу видно, почему. Ты выкладываешь код, и чтобы это было не зря, он должен кому-то пригодиться. А для этого этот кто-то должен для начала вообще узнать, что ты ему что-то подготовил.

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

Еще одна распространенная ошибка – когда люди пилят код, но никому об этом не говорят. Вот на Гитхабе отличная библиотека, лежит в профиле годами, но никто о ней не знает. Да, если это что-то супер-уникальное, то может его и найдут, но если это просто хороший продукт, то вряд ли. Если пару дней потратить на пиар, написать на Реддит, Хабру, еще куда-то, то придут люди и проект заживет своей жизнью.

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

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

Хотите задать свой вопрос Александру? Воспользуйтесь комментариями, мы постараемся оперативно ответить. Ну а если хотите работать с ним в одной крутой команде Skyeng — мы всегда ищем таланты!

Комментарии (15)


  1. dmirogin
    29.11.2017 16:13

    Спасибо. Если интересно еще побольше узнать об OpenSource, то можно послушать доклад Александра на YiiConf 2017 yiiconf.ru/ru/offers/offer/240


  1. vtvz_ru
    29.11.2017 16:47

    Вопрос: по каким причинам backend решили переписать с Yii на Symfony? Насколько Yii плох для крупных проектов?


    1. Ontaelio Автор
      29.11.2017 16:59

      Саша чуть позже ответит, я пока по первому вопросу. На Yii написаны очень старые куски бэкенда, еще на 1.1, их давно никто не трогал из принципа «if it works don't fix it». Потом пришли новые разработчики и стали писать новые участки бэкенда на Symfony (потому что работали с ним), ну и теперь надо старые довести до текущего стандарта. Когда я причесывал интервью, оно подсократилось, вот из удаленного в тему:

      Будешь рефакторить старый код?

      Я работал в компаниях, где слово «рефакторинг» — ругательное. Там было принято четко определяться, на что надо тратить время, и какие задачи это решает. Поэтому я привык что-то переделывать по мере поступления задач. Просто закладываю на них чуть больше времени и исправляю все, до чего дотягиваются руки, по ходу работы. Так ты вникаешь в проект, понимаешь задачи, и со временем код становится лучше. Мы будем понемногу переделывать некоторые части бэкенда, все-таки Yii 1.1 – заслуженный старичок; скорее всего на Symfony, ничего не имею против.


    1. SamDark
      29.11.2017 17:06

      Во-первых, стоит уточнить что переписать с Yii 1.1. Он несколько устарел и поменять его, если и так есть необходимость переписать, нормально.


      Причины переписать именно с фреймворком не связаны. Бэкенд состоит из множества сервисов, самые старые на Yii 1.1 и, как бывает, архитектура самих сервисов, которая изначально была нормальной, в изменившихся реалиях бизнес-процессов, становится не очень подходящей.


      Yii 2.0 вполне подошёл бы, самое сложное там всё-равно совсем не про фреймворк, но так как некоторые сервисы уже на Symfony и у многих экспертиза именно в Symfony, было решено (ещё до моего прихода) не плодить зоопарк.


      1. bores
        30.11.2017 15:34

        В далёком 2014-м участвовал в yii-бэкенде как разработчик одного из подрядчиков. Подумать только как разрослась команда за 3 года!
        PS: Мой код будет выпиливать сам Александр Макаров. Я в экстазе! )))


  1. mrhx
    30.11.2017 00:23

    Интервью понравилось, но почему сразу два макбука?? :)


    1. Ontaelio Автор
      30.11.2017 00:38
      +1


      1. ilyaplot
        30.11.2017 11:59

        Идея отличная, реализация не очень. Надо было брать не менее трех ноутбуков :)


  1. SbWereWolf
    30.11.2017 09:10
    +1

    Здравое интервью. Спасибо.


  1. Samouvazhektra
    30.11.2017 20:54

    А на какой версии Symfony? Будете 4-ку внедрять?


    1. SamDark
      30.11.2017 23:28

      Скорее нет, чем да. 4-ка только-только вышла. Опасно.


    1. AntonTrekov
      02.12.2017 11:59

      Медиа сервисы уже летом переехали на четверку, хотя она еще и не вышла тогда. Был доклад на Symfony Moscow Meetup от Надежды Рябцовой.


      1. SamDark
        02.12.2017 17:49

        И ещё на митапе SuperJob был этот же доклад. Вот видео: https://youtu.be/EfL8lsUTlFo?t=1h27m44s


  1. Ekstazi
    01.12.2017 14:53

    Symfony неплохой фреймворк, я вообще сейчас в проекте где все на codeigniter 3 написано… Но любовь к yii все так же осталась.


    1. SamDark
      02.12.2017 17:57

      У Symfony идеология отличается прилично. На Yii можно делать очень просто и быстро, но и легко из за этого сделать плохо (лапшекод). На Symfony делать быстро и просто тоже можно (мы это сделали как-то на хакатоне, взяли второе место), но очень легко сделать слишком сложно (лазанья) и скатиться в J2EE (в плохом смысле). Одни compiler-pass и многоуровневое кеширование чего стоят...


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