Привет! Впервые проводим сессию вопросов и ответов в формате поста на Хабре. Команда мобильной разработки «Лаборатории Касперского» ответит на все комментарии первого уровня, которые появятся сегодня с 13 до 20 часов по московскому времени. Мы готовы ответить на вопросы, связанными с разработкой, тестированием, аспектами безопасности мобильных и носимых устройств (операционные системы Android, iOS, Sailfish, OpenWrt, Windows Phone, Symbian, Blackberry и др.)
Немного о нас
В «Лаборатории Касперского» мы занимаемся исследованиями, разработкой и сопровождением B2С, B2B и технологических продуктов под мобильные устройства (хотя непосредственно анализом вредоносного ПО мы не занимаемся).
На вопросы ответят:
Виктор Яблоков (@viktoryablokov) — руководитель мобильной разработки
Выпускник мехмата МГУ, к. ф.-м. н., автор множества патентов и научных статей. В мобильной разработке с 2000 года, из которых последние 16 лет — в «Лаборатории Касперского», где прошел путь от разработчика до руководителя управления мобильных продуктов.
Алексей Комиссаров (@lozzz)
Глава iOS-разработки. Прошел карьерный путь от начинающего разработчика до руководителя направления.
Константин Филатов (@konstantin_filatov)
Ведущий эксперт «Лаборатории Касперского», который знает все тонкости Android, отвечает за технологические исследования и разрабатывает новые продукты.
Ольга Николенко (@lynx09)
Руководительница мобильного тестирования. В данной сфере с 2003 года, за это время успела поработать в Devexperts, Motorola, Paralles, Deutsche Bank. К мобильной команде в «ЛК» присоединилась в 2014-м, где решает самые амбициозные задачи.
Андрей Берюхов (@andreysber)
Android-разработчик, автор статей и докладов про Jetpack Compose, Kotlin Multiplatform и Flutter. Выпускник магистратуры ФКН НИУ ВШЭ.
Дмитрий Кузнецов (@ihppie)
Ведущий iOS-разработчик.
Занимается коммерческой iOS-разработкой на протяжении семи лет. В «Лаборатории Касперского» с 2016 года. В настоящий момент тимлид двух проектов. Выпускник ВМК МГУ.
Немного о нас
В «Лаборатории Касперского» мы занимаемся исследованиями, разработкой и сопровождением B2С, B2B и технологических продуктов под мобильные устройства (хотя непосредственно анализом вредоносного ПО мы не занимаемся).
На вопросы ответят:
Виктор Яблоков (@viktoryablokov) — руководитель мобильной разработкиВыпускник мехмата МГУ, к. ф.-м. н., автор множества патентов и научных статей. В мобильной разработке с 2000 года, из которых последние 16 лет — в «Лаборатории Касперского», где прошел путь от разработчика до руководителя управления мобильных продуктов.
Алексей Комиссаров (@lozzz)
Глава iOS-разработки. Прошел карьерный путь от начинающего разработчика до руководителя направления.
Константин Филатов (@konstantin_filatov)
Ведущий эксперт «Лаборатории Касперского», который знает все тонкости Android, отвечает за технологические исследования и разрабатывает новые продукты.
Ольга Николенко (@lynx09)
Руководительница мобильного тестирования. В данной сфере с 2003 года, за это время успела поработать в Devexperts, Motorola, Paralles, Deutsche Bank. К мобильной команде в «ЛК» присоединилась в 2014-м, где решает самые амбициозные задачи.
Андрей Берюхов (@andreysber)
Android-разработчик, автор статей и докладов про Jetpack Compose, Kotlin Multiplatform и Flutter. Выпускник магистратуры ФКН НИУ ВШЭ.
Дмитрий Кузнецов (@ihppie)Ведущий iOS-разработчик.
Занимается коммерческой iOS-разработкой на протяжении семи лет. В «Лаборатории Касперского» с 2016 года. В настоящий момент тимлид двух проектов. Выпускник ВМК МГУ.
Whatyourname
Осторожно! Токсично!
Задаю вопрос не с 13, потому что это всё-таки рабочий день и с 13 до 20 я работаю.
Какую роль выполняет Каспрессо, я так и не понял, честно говоря. Посмотрел примеры отсюда github.com/KasperskyLab/Kaspresso и всё равно не понял. В пример много строчек (правда из-за скобок), которые делают в итоге полтора действия.
Вот код, который сейчас у меня под рукой:
Здесь гораздо меньше строк и гораздо больше проверок. Каждая из этих строк делает полные проверки экранов, всех элементов, то есть тут десятки проверок. Зачем бы мне завязываться на внешний фреймворк, по которому нет вообще никаких гарантий? Типа, завтра из компании уйдёт человек, который вот этим рулит и проект будет заброшен и быстро устареет.
Что касается взаимодействия и распараллеливания, то для этого достаточно несколько строчек на питоне (прошу прощения у не знаю кого, ибо на начало написания тех скриптов я ещё не ведал, что творил) или го (сейчас наступаю на те же грабли, но на новом языке :)) и тесты будут гоняться одновременно на любом количестве устройств, а также будут работать e2e тесты между несколькими устройствами одновременно.
При этом сопровождение будет несоизмеримо легче, потому что каждый дополнительный фреймворк тащит с собой дополнительные ошибки и проблемы обновлений. В случае ошибок частенько бывает так, что тестировщик напишет какой-то костыль, который её обходит. Через сколько-то времени выходит новая версия с исправлением, но никто не читает все изменения, потому что некогда, и костыли не убирают и так они остаются мусором. Сквозь этот мусор через несколько лет продираются совершенно другие люди со словами «ну и нафига, ведь и так всё работает нормально».
А ещё возникает проблема обновления, когда зависимости не обновляют по несколько лет, а потом ррраз! И ничего не работает, всё сдохло, нужно теперь разбираться с каждой отдельной проблемой, коих тут вагон. Каждый androidTestImplementation приносит свои проблемы и люди стараются в итоге как можно дольше не обновлять зависимости. Что в итоге выливается в полную неработоспособность системы, когда обновление всё-таки приходится делать.
В общем, я не понимаю сути Каспрессо, его преимуществ. Можете объяснить скептику? Только, пожалуйста, не нужно ставить в преимущества фреймворка Page Object, потому что это не является его заслугой.
Ну и вопрос общий. Как вы выбираете, тянуть какую-то библиотеку в проект или нет? Скажем, вот есть офигенный RxJava, давайте его тащить, без него жизни нет. А тут бах и корутины. Оставляем эрыкс? А зачем? Убираем? А зачем тащили? А не боитесь, что очередная библиотека притащит с собой уязвимость, о которой не предполагали? Притащили, скажем, библиотеку для отображения svg на Андроид 1.2, а потом выяснилось, что если на /sdcard/ лежит файл debug-template-lib-test.svg, то либа пытается вгрузить этот файл, чем бы он на самом деле ни был. Не боитесь такого?
AndreySBer
Я выделил несколько основных вопросов:
1) Какую роль выполняет Каспрессо?
2) Зачем бы мне завязываться на внешний фреймворк, по которому нет вообще никаких гарантий?
3) Как вы выбираете, тянуть какую-то библиотеку в проект или нет?
Отвечу по частям.
AndreySBer
1) Kaspresso – это многофункциональный фреймворк, который облегчает написание UI-автотестов для Android. Разработчики начинали с создания обертки над Kakao и Espresso для уменьшения количества флаков в тестах. По мере накопления опыта автотестирования у нас – развивался и Kaspresso. Получилось, например, ускорить в 10 раз работу с UI Automator. В планах – помощь с настройкой инфраструктуры для запуска тестов.
Более подробную информацию о фичах Kaspresso можно посмотреть в репозитории.
AndreySBer
2) Фреймворк развивается несколькими людьми внутри компании, плюс сообществом разработчиков вне её. Код полностью open-source, поэтому его можно форкать, развивать, и использовать без завязки на наш репозиторий. Если вы сможете помочь нам в его развитии – Pull Request-ы приветствуются.
AndreySBer
3) Уязвимости в используемых библиотеках, а также возможность их использования в соотвествии с лицензионным соглашением проверяются отдельными командами Лаборатории.
Первоначальное решение о необходимости затянуть библиотеку принимают разработчики. Если это достаточно узко специализированная библиотека, на которую не завязывается весь проект – тут всё просто.
На вашем примере перехода с RxJava2 на Coroutines расскажу про процедуру принятия решения.
Инициатор внедрения должен детально изучить новую библиотеку. После чего он предлагает команде рассмотреть плюсы от такого перехода и возможные проблемы. Если решение о внедрении принимается – мы стараемся подтянуть уровень знаний всей команды о ней. А инициатор становится неким "евангелистом", которому уходят наиболее сложные кейсы. Только после этого происходит переход.
В новом проекте без RxJava2 мы можем сразу начать использовать Coroutines.
Konstantin_Filatov
В случаях, когда сторонняя библиотека втягивается в SDK, к ее выбору подходим значительно более тщательно, чем при принятии такого же решения для приложения.
Библиотека втягивается только в случае, если она несет значимый функционал, самостоятельная разработка которого сложна и займет длительное время. Примером тут может быть openssl, — самостоятельно данный функционал реализовать затруднительно, и подобная реализация неизбежно будет значительно хуже оригинала.
Библиотеки, предлагающие решение какие-либо архитектурные проблем, в SDK не затягиваем.
Причин на это несколько:
— Возможные конфликты между версиями библиотек, используемых в SDK, и аналогичными библиотеками в проектах, в которые данный SDK будет встраиваться.
— Увеличение объема бинарного кода SDK.
— Появление зависимостей на сторонний код, план развития которого в будущем нами не контролируется. В качестве примера могу привести недавний коммит в код библиотеки Sqlite, полностью убравший из новых версий данной библиотеки поддержку крипто кодеков. Чем больше подобных зависимостей в проекте, тем больше вероятность того, что часть из этих внешних библиотек в какой-то момент перестанут поддерживаться их авторами. В этом случае придется их поддерживаться самостоятельно или искать какую-то замену. В случае с SDK подобные замены могут приводить к нарушению обратной совместимости и вызывать дополнительные сложности по переходу на новую версию SDK у клиентов, которые его используют.