Интервью с разработчиком. Евгений Мацюк (Лаборатория Касперского)

Расскажи в двух словах:

Кто ты? Чем занимаешься в команде? Сколько лет работаешь в компании?

Я — Development Team Leader флагманского продукта «Лаборатории Касперского» — Kaspersky Internet Security for Android (KIS for Android). К команде я присоединился ровно год назад.

Какой у тебя опыт? Почему разработка Android?

В этом году исполнится шесть лет, как я начал знакомство с Android. Эх, как время то летит. Еще недавно был таким молодым и полным надежд =)

До этого я программировал на С++ в VisualStudio, Qt. Были весьма неплохие наработки в компьютерном зрении.

Также я с другом участвовал в некоторых стартапах, самым интересным из которых был «Воздушный монитор». Мы спроектировали там систему распознавания жестов. Представьте себе, изображением в воздухе можно было полноценно управлять, прям как в «Железном человеке». На выставках у нас всегда был ажиотаж =)

Как это примерно выглядело, можно посмотреть здесь.

Android выбрал, потому что это было, да и в принципе до сих пор, «стильно, модно, молодежно». Ну и просто хотелось что-то новое попробовать для себя.

В написании каких приложений ты поучаствовал?

К сожалению, мне не довелось поработать в «кровавых аутсорсах» =) Тогда бы счет приложений мог бы и за сотню перевалить. В начале карьеры участвовал в разработке звонилок, название которых вам ничего не скажет.

Намного интереснее уже было в LinguaLeo. Но из-за финансовых проблем компании проработать там удалось недолго.

Потом «вставание с колен» СбербанкБизнесОнлайна. Мы приняли приложение с рейтингом 3.1 и соответствующей кодовой базой, а через полтора года имели рейтинг 4.5 с Чистой архитектурой, юнит-тестами и RxJava. Что может быть прекрасней? Будет что внукам рассказать.

А сейчас KIS for Android, который считается одним из самых лучших в мире антивирусом.

Что является лучшей и худшей частью твоей работы?

Вообще я где-то прочитал, что программирование — это высшая форма творческой деятельности. Ты каждый день сталкиваешься с каким-то вызовом, с какой-то задачей. Ты должен держать в голове много информации, уметь абстрагировать в нужной степени самые разные вещи. Твой мозг должен быть всегда голодным до знаний и до поиска истины. Ты должен каждый день становится лучше, иначе поезд технологий быстро уйдет, и посредственность будет твоим уделом.И разве все это не круто?

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

Теперь поговорим о разработке

Какая у вас архитектура? Каких паттернов придерживаетесь при разработке?

Думаю, что абсолютно никого не удивлю своим ответом. Чистая архитектура. Этим все сказано =)

Какие библиотеки и фреймворки используете? Какие считаете надежными?

• RxJava 2;

• Dagger 2;

• Moxy;

• Cicerone;

• LeakCanary;

• BlockCanary.

Со всеми работаю относительно давно, все знаю довольно хорошо, как я считаю.

Как осуществляется внедрение новой, потенциально полезной библиотеки? Есть человек-инноватор или группа людей, которые включают библиотеку в проект и изучают ее?

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

Каких-то специальных выделенных бойцов «новых технологий» у нас нет.

Если в проекте нам понравилась новая библиотека, мы рассказываем про нее всему штабу, и каждая команда уже отдельно принимает решение. Да, у нас довольно большая свобода в рамках команд.

Расскажи о тестировании. Как оно происходит? При помощи каких библиотек и подходов?

С Чистой архитектурой обязательной составляющей стали и юнит-тесты. У нас довольно-таки большой объем бизнес-логики, и без тестов - никак. По покрытию никаких рамок себе не ставим. Покрываем тестами прежде всего сложные участки. Тривиальные вещи опускаем. То есть по факту максимально покрываются тестами Интеракторы.

UI-тесты у нас пишет отдельная команда. Разработка этим не занимается, и я считаю, она и не должна этим заниматься.

Инструментарий у нас такой — JUnit, Mockito, AssertJ. По опыту, этого вполне достаточно, ничего лишнего.

Как ведете документацию? Что используете для этого, пишете ли документацию к методам.

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

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

Вообще до сих пор не совсем могу понять, как 50 или 100 разработчиков могу писать одно мобильное приложение. Мне кажется, одной из обязательных фич тогда должен быть полет в космос =)

Как выкладываете релиз? Постепенно или сразу, есть ли фокус-группы?

Перед выкладкой обязательно проводим закрытые бета-тестирования. У нас есть свой форум и свои фанаты продукта, которые дают отличную обратную связь.

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

Так как у продукта почти 10 миллионов активных пользователей, то раскатку релизной версии проводим по чуть-чуть, активно следя за Android Vitals.

Расскажи о прочих сервисах, если они есть, которые помогают разрабатывать приложения.

Начинаем активно использовать Firebase. В частности уже заюзали Firebase Analytics, Firebase Remote Config, Crashlytics. Еще Notifications хотим подключить.

Для анализа данных начали юзать BigQuery, пробуем сейчас разные инструменты удобной визуализации данных. К сожалению, консоли Google Analytics и Firebase Analytics все-таки крайне ограниченны. GA в принципе пофункциональней будет, но там мы попадаем на сэмплнг. А с 10 млн пользователей, от которых каждый день сыплются события, вы можете себе представить, какую погрешность в итоге с этим сэмплингом можете получить.

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

Как ты считаешь, нативная разработка будет жить в будущем? Или же постепенно ее вытеснят кроссплатформенные движки, типа React Native, Flutter? Как вообще ты относишься к кроссплатформенной разработке.

Нативная разработка будет жить еще очень долго, как мне кажется.

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

А какое твое мнение по поводу Open Source разработки? Для новичков и опытных разработчиков. Участвовал ли ты сам?

Считаю, что вещь весьма хорошая и полезная.

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

К сожалению, сам я не особо участвовал в подобных проектах. Все-таки они требуют времени, и иногда немалого времени. В основном я репортил баги =)

Как относишься к Architecture Components от Google? Стоит ли переделывать свои проекты на нее? И как ты вообще видишь дальнейшее развитие архитектурной поддержки от Google?

Отношусь хорошо. Прежде всего потому, что Google серьезно начал заниматься таким вопросом, как архитектура приложения. То есть любой начинающий разработчик уже будет иметь определенное представление об этом очень важном вопросе. Эх, если бы такая штука появилась года три назад хотя бы. А то все самим, все самим приходилось познавать.

Так то ребята по сути просто собрали с мира по нитке и представили то, что более-менее уже устоялось в комьюнити.

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

А если именно такой проект, где непонятно какая архитектура и собираешься сделать все хорошо, то что бы ты выбрал? Взял бы ты сейчас в проект достаточно новые компоненты от Google или же придерживался хорошо зарекомендовавших себя подходов из Clean?

Я бы все-таки придерживался Clean. Мне кажется, уже столько всего там разобрано на молекулы, столько ситуаций рассмотрено. Доклады, статьи, CookBook даже. И все это на русском языке! На самом деле в плане подборки материалов в англоязычной среде я такого и близко не встречал.

Плюс активное русскоязычное комьюнити, где вам всегда помогут.

Да и я всегда открыт для вопросов и всегда с радостью подсказываю.

Кроме того компоненты, которые предлагает Гугл, они ведь не несут что-то принципиально новое и лучшее. Есть отличные аналоги типа Moxy и RxJava.

Теперь поговорим о команде.

Сколько человек у вас в команде?

В команде KIS for Android сейчас четыре разработчика вместе со мной плюс стажер.

А сколько у вас команд? И часто ли бывают пересечения между командами?

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

Как осуществляется взаимодействие внутри команды? Ну и немного про методологию работы.

Практически в каждой компании, в которой я работал, говорилось, что мы работаем по Scrum, Agile и вот этому всему. По факту везде же своя вариация данных методик. И на самом деле это правильно, как я считаю. Не процессы должны нами управлять, а мы - процессами, и они прежде всего должны делать нашу жизнь легче, а легкость - это далеко не обязательно предельная формализованность.

Как осуществляется взаимодействие между отделами? Например, отделом разработки и дизайна, или между разработчиками и тестировщиками.

У нас опен-спейс и все под боком =)

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

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

Как осуществляется работа с системой контроля? Делаете ли код ревью?

По работе с системой контроля — стандартный GitFlow.

В качестве технологического стэка используем Microsoft TFS с некоторыми добавками типа Jenkins и UpSource. Почему именно TFS? Так уж исторически сложилось, ведь изначально разработка велась только под Windows, и мы с Microsoft партнеры. В целом TFS предоставляет вполне стандартный набор возможностей, все устраивает.

По проверке кода. Статический анализ + Юнит-тесты + Ревью кода. Данное сочетание — закон. Кто его нарушит — продолжите сами =)

Как попасть в вам в команду? Какой уровень знаний нужен, чтобы у вас работать?

Кстати говоря, мы сейчас активно ищем новых сотрудников уровня middle/senior. Поэтому всем желающим — welcome!

Что ждем от кандидата? Прежде всего крепких знаний по Java и Android, хороший общий кругозор, а самое главное - «горящие глаза»! Подробнее можно прочитать здесь.

На самом деле у нас вы точно сможете найти себе занятие по душе. Любите UI и анимашки, пожалуйста. Любите ковыряться в кишках Android и натива, реверсить приложения, тоже милости просим. Предпочитаете больше заниматься бизнес-логикой, архитектурой там всякой, RxJava — это ко мне =)

Пишите мне сразу напрямую. Очень жду.

Как ты охарактеризуешь «крутого» разработчика? Как можно себя самоидентифицировать?

Я уже в самом начале говорил про важность постоянного самосовершенствования и любовь к делу. Сделаю еще одну добавку.

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

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

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

Да бред все это =)

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

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

Главное — результат. Но при этом должен быть человек (он же лид), который спрашивает результат и следит за процессом. Иначе иногда разработчики могут немного улетать в космос или же просто заниматься ни тем. Ну и вообще лид должен быть и наставником, и товарищем, и просто хорошим человеком =)

Обсудить архитектуру Android приложений с Евгением и другими ребятами можно в чате Android Architecture. Если у вас есть какие-то сомнения в архитектуре, то смело задавайте их туда.

Для связи с Евгением Мацюком используйте Telegram. Также его профиль на Хабре.

Подписывайтесь на канал Android Live, где я публикую свои мысли о разработке, статьи и подборки.

С удовольствием отвечу на ваши вопросы по каналу, а также буду рад услышать ваши отзывы.