Google Developer Expert (GDE) — это признанный эксперт, обладающий определенным уровнем квалификации в конкретной области технологий Google. Сегодня почти тысяча экспертов представляют технологии Google по всему миру, их них специалистов по Android только 138, из которых в России пока один - Евгений Мацюк. Он создатель OpenSource (открытый исходный код) фреймворка (программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта) для написания автотестов под Android - Kaspresso.
«Эксперт-онлайн» поговорил с Евгением Мацюком, о том как создавался Kaspresso и где разработчику найти время на проекты OpenSource.
— Прошло уже чуть более двух лет с первого релиза Kaspresso. Как комьюнити приняло библиотеку, и чего вы достигли за это время?
— За это время мы выпустили еще шесть полноценных релизов, получили более 1200 звездочек на GitHub'е (крупнеший в мире интернет хостинг проектов с открытым исходным кодом и инструментов разработки – прим «Эксперт»), нашими пользователями стали такие крупные российские и не только компании, как Яндекс, Сбербанк, Касперский, HeadHunter, Revolut, AliExpress, Tinkoff, Raiffeisen, VTB, X5 Retail Group, Blinklist и многие другие. У нас активное комьюнити, только в русскоговорящем чате более 600 разработчиков и тестировщиков. Ну а самое главное, что все больше специалистов начинают считать Kaspresso неким стандартом в написании автотестов под Android. То есть Kaspresso оказывает непосредственное влияние на индустрию, экономя сотни часов и бесконечное количество нервных клеток своим клиентам.
— Это ваш первый OpenSource проект или было еще что-то до этого?
— Конечно же, у меня были определенные наработки и до Kaspresso. Сначала это были тестовые проекты, на которых я показывал имплементацию каких-то своих идей из статей про RxJava и про архитектуру. Затем в 2017 году мы с ребятами попробовали сделать некий Архитектурный CookBook, куда хотели заносить в структурированном виде архитектурные рецепты имплементаций типовых сценариев, встречающихся в приложении. Несмотря на то, что рецепты мы писали на русском, да и в целом нас хватило на очень непродолжительный временной период, CookBook на данный момент набрал более 600 звездочек. То есть если бы мы вели все это дело на английском и активно поддерживали, то может было бы большое будущее тут. Но уж слишком все быстро меняется в этих архитектурах, да и времени оно требует очень много.
— А почему вы делаете OpenSource проекты?
— Первое, что напрашивается сразу, это то, что компании и продукты будут сменяться в вашем резюме, а OpenSource проекты с вами навсегда. В резюме можно написать все, что угодно, но как это проверить? Как проверить ваш импакт, ваше качество написания кода, ваши архитектурные скиллы? А вот OpenSource-проект дает ответ сразу на очень многие вопросы о вас. Можно посмотреть на код, архитектуру, на вашу поддержку проекта и пользователей, на ваше планирование и умение делать продукт, на ваше комьюнити, на пиар продукта, на качество документации и тд. Помню, что когда я просматривал резюме кандидатов, а их через меня прошло очень много, то сразу же выделял разработчиков с достойными OS-проектами, хотя бы 100 звездочек на GitHub. Я просматривал код проектов, и уже на интервью спрашивал в основном по софт-скиллам и по тому, чем бы интересно было заниматься, ведь техническая часть и так понятна. Признаюсь, таких кандидатов было ну очень мало.
Второе, вы создаете продукт своими руками. Не делаете какую-то фичу, не являетесь винтиком в системе, а создаете именно полноценный продукт с полным влиянием на его развитие. И этот продукт двигает индустрию вперед. Поверьте, это абсолютно другие ощущения.
Третье, я верю в трансформацию OpenSource решений в крутые компании. То тут, то там появляются новости о поднятии инвестиций компаниями, которые еще вчера были просто OS-библиотеками. Черт побери, да почему бы и нет? Ведь вы делаете продукт для аудитории, частью которой являетесь и боль которой прекрасно чувствуете. Подумайте об этом на досуге.
— Как создавался Kaspresso?
— В 2018 году в Лаборатории Касперского уже как несколько лет был отдел автотестирования, но результаты, к сожалению, были не такими, как ожидалось. Наблюдались большие проблемы со скоростью, со стабильностью. В качестве основного инструмента для написания автотестов был выбран Appium, который, казалось, был разумным выбором. Но вот что-то шло не так. Была попытка привлечения разработчиков к написанию автотестов, но они были не в восторге от процесса взаимодействия с Appium. Были активные дискуссии по тому, как это исправить и что делать. Автотесты виделись одним из главных способов сокращения релизного цикла, и мы были обязаны что-то тут придумать.
И вот весной 2018 года мы с товарищем отправляемся на конференцию Mobius, где ребята из Avito рассказывали про свой путь в автотестах. Примерно же в это время выходят несколько подкастов, посвященных автотестам под Android. Одна из главных идей, которая шла от докладов и подкастов - это использование нативных инструментов, таких как Espresso, и полный отказ от кроссплатформенных решений типа Appium.
Вообще то время я бы отнес ко времени слома традиционного релизного цикла. Раньше релиз в квартал или полгода было приемлемым, сейчас же компании все больше и больше начинали осознавать важность скорости доставки изменений пользователю. Теперь приемлемым считался релиз раз в одну-две недели. Такой резкий скачок вынуждал полностью перестраивать весь процесс CI/CD (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка – прим «Эксперт»). Раньше мы могли спокойно тестировать и «руками», теперь же без автотестов гарантировать качество продукта уже не представлялось возможным. Но штука в том, что и инструменты для автотестирования тоже не были готовы к столь резкому повышению требований по стабильности и скорости исполнения тестов. Потом оказалось, что и нативные тесты были не решением. Да, они превосходили по скорости Appium, но практически никак не решали вопросы со стабильностью, читаемостью, легкостью поддержки и тд.
Возник вакуум, появился тот самый - голубой океан. Я решил попробовать взяться за это дело.
Мне удалось убедить менеджмент, что нам стоит менять подход в автотестировании, что готового решения нет, и его придется создавать самим. В результате мне было поручено создать оперативную команду разработчиков из представителей разных продуктовых команд, для создания решения, позволяющего писать прежде всего стабильные и быстрые тесты. Также к обсуждениям и ресерчам я привлек ребят из Avito и HeadHunter. Совместными усилиями к середине весны 2019 года была создана самая первая альфа-версия Kaspresso. Этой версии уже было достаточно для внутреннего потребления, но также было стойкое ощущение, что это нужно опенсорсить, потому что во фреймворке был ряд очень интересных и нетривиальных решений, которые мы нигде до этого не видели.
Успешный весенний доклад на Mobius 2019 только подтвердил наши догадки - комьюнити было заинтересовано в подобном решении и очень ждало его. Я снова пошел к менеджменту и убедил их, что нам нужно опенсорситься, и для этого нужно выделить время. Все лето над Kaspresso кипела работа, а уже в сентябре 2019 года состоялся публичный релиз.
— А где взять время на эти все активности?
— Секрет очень прост. Если вы решаете проблему компании, то компания же вам выделяет на это время, а еще и денюжку платит. Львиная доля первой версии Kaspresso была написана в рабочие часы. Хотя я любил писать еще и по вечерам, и по выходным. Но делал я это только потому, что просто горел идеей, а не потому что времени не давали.
Но, конечно же, это была шутка про простоту со временем. Когда мы выпустили первую версию, а наш фреймворк позволил командам решить задачу сокращения релизного цикла, фокус с фреймворка, конечно же, начал смещаться, ведь ключевая задача то решена. И все последующие релизы были выпущены практически исключительно в свободное от работы время. Вы должны быть готовы к этому. Но скажу важную вещь - осознание, что это ваш продукт, творит чудеса, и всегда каким-то странным образом вы найдете и время, и энергию.
