Это же статья про то, на сколько компания известна именно как работодатель! Если так смотреть, то цифра, что 33% опрошенных знают, как работает условный Ozon внутри, вполне адекватна. Вот если бы было где-то 100%, то тогда бы надо было напрячься)
Очень частый вопрос: как вообще выделять правильно модули. Так и не смог для этого вынести какие-то формальные критерии. Получается что-то типа: отдельная фича — это кусок кода с изолированной логикой, не очень большой и не очень маленький >_<
Кризис в стране, батенька, ещё не понятно что с вашими сикуэлами будет, а вот в виду проблем с импортом качественной техники мастера-ремонтники могут озолотиться😜
А почему так мало мобильных разработчиков? Если нужна помощь в проникновение в сообщество (тот же Android Dev Podcast или Android Broadcast), пишите в личку
У нас багфиксы умещаются внутри фичи. Дело в том, что тестирование фичей проходит в две стадии. Во время разработки QA обсуждает с разработчиком, что можно уже посмотреть, а куда лезть не стоит. Таким образом, когда фича начинает подходить к релизу QA начинает тестирование (пунктир на рисунке ниже). Перед тем, как влить фичу в develop, QA уже тестирует её и все, что можно задеть, капитально.
Таким образом мы получаем практически всегда стабильный develop. Да, конечно, туда может просочиться баг из-за мердж конфликтов или по невнимательности, но их уже фиксят обычно в релизной ветке. Исключения составляют, конечно же, те случаи, когда сломался develop.
Что касается времени прогона тестов и всех проверок — у нас есть вот такой вот дашборд:
Сейчас пришли к тому, что прогон выполняется около 40 минут на Android и около 50 минут на iOS
Чисто тесты проходят за минут 25 (взял рандомную ветку, поэтому число тестов отличается от того, что написал выше)
И да, кстати я вас обманул в первом сообщении, на самом деле распределение по числу тестов наоборот:
1) iOS и Android в разных репозиториях, поэтому тесты гоняются для каждой платформы отдельно
2) Ночные тесты гоняются на каждой фиче ветке и develop (на ветках разработческих не гоняем). Для ночного среза репозитория из примера(см картинку ниже) будет 3 прогона: 2 на больших фиче ветках и 1 на develop
3) Также гоняются тесты при PR в develop. Таких моментов на диаграмме изображено 3
Если просуммировать, то после 20 дневных коммитов может и не быть прогонов, если еще не настала ночь и мы не делали PR в develop. Так понятнее стало?
У нас два приложения в активной стадии разработки. Одно для соискателей (с которым все знакомы) уже довольно давно живет. В нём картина такая:
390 iOS
452 Android
Второе приложение для работодателей мы с нуля переписали недавно (это совсем другая история), его только сейчас начали покрывать тестами
Гоняются и в ночных прогонах и на PR в develop абсолютно все тесты. Это стало возможным благодаря уходу от trunk-based — не нужно каждый чих проверять на стабильность
@benavirот себя еще предложил бы вам хотя бы временно уменьшить нагрузку на тестировщика. Вообще 1 к 7 это еще хуже чем в известной картинке!
Как можно снять нагрузку? Можно найти много способов, например:
Отправить двоих разрабов разрабатывать фреймворк и инфру для автотестов (это убьет сразу же двух зайцев, кстати)
Взять на пару месяцев аутстаф тестировщика на мануальное тестирование, чтобы разгрузить Вас (мы, кстати, так сделали, когда запускали автотестирование на втором приложении)
Дождаться, когда команда уйдет в отпуск ( перед новогодними, например)
Удачи Вам, поговорите, со своим руководителям о балансе сил!
У такого подхода, когда у вас одна сборка для обеих экосистем, есть несколько минусов, но главный из них состоит в том, что время от времени ревью-команда гугла отклоняет сборки, содержащие хуавеевские зависимости, ссылаясь на "уязвимости", "вредоносный код" и так далее. Конечно, в таких случая HMS библиотеки оперативно обновляются чтобы соответствовать представлениям гугл о безопасном коде, но некоторое количество нервов и времени это может скушать.
Все-таки хочется один артефакт — так удобнее работать, ну и можно, как и говорил в статье/видео, для пользователей HMS+GMS приоритезировать HMS для каких-либо фичей
А какие еще видите минусы / риски?
Поэтому я обычно советую не тащить в сборку те зависимости, которые там не нужны а пилить на флейворы. Единственная существенная издержка это то что надо тестировать и на GMS и на HMS устройствах (а как показал ваш опыт, то и на GMS+HMS тоже). Но на самом деле по-хорошему и ваш подход тоже необходимо тестировать и там и там, я даже не особо верю, что вы этого не делаете.
У нас только смоук делается (и то не всегда), основные проверки автоматизированы. Да, для HMS-фичей они не гоняются, так как эмуляторы Huawei не может предоставить
Я, кстати не рекомендую использовать флейворы для разных вариантов кода! При включении варианта сборки остальные убираются из индекса IDE. А еще сборки идут строго друг за другом (баг тулзов наверное). Это крайне затрудняет разработку, лучше уж сделать на модулях + два различных приложения.
Ну и про карты. Вы не стали вдаваться в детали, почему не стали в итоге интегрировать хуавеевские в финальной версии, жаль, было бы интересно узнать почему. Но даже если возникли какие-то непреодолимые сложности есть ещё один подход. Можно интегрировать те карты, которое работают и на GMS и на HMS аппаратах, те же яндексовские. Аналогичный подход можно использовать и для других библиотек.
Это больше продуктовая история. Пока что сделали MVP технической командой. Если продакт посчитает необходимым добавить карты в HMS сборку, то да, будем рассматривать в том числе и кросссервисные (слово то какое придумал😃)варианты
Имеете в виду, что если кандидат не подошел, то пусть другие компании тоже видят? С одной стороны это интересная затея, так как оценка скиллов облегчит найм другим компаниям, но с другой — это попахивает каким-то социальным рейтингом, не находите? А эта штука прямо на грани!
Помню когда начинал работать с тимлидом одной из команд, у них 1-1 проходил тимлид - проджект менеджер - член команды.
И главное, никого не смущал этот треугольник😂
Можно еще посмотреть на зарплаты на том же career.ru, вот к примеру у джавистов https://career.ru/profession/38?grade=senior
Если у вас есть крутые идеи, можете написать в телеграмм чатик с нашими разработчиками и передать их в первые руки так сказать https://t.me/hh_tech ;)
В чате обсуждаем больше технологии, архитектуру и тд, но годные идеи тоже рады будем слышать
Это же статья про то, на сколько компания известна именно как работодатель! Если так смотреть, то цифра, что 33% опрошенных знают, как работает условный Ozon внутри, вполне адекватна. Вот если бы было где-то 100%, то тогда бы надо было напрячься)
Очень частый вопрос: как вообще выделять правильно модули. Так и не смог для этого вынести какие-то формальные критерии. Получается что-то типа: отдельная фича — это кусок кода с изолированной логикой, не очень большой и не очень маленький >_<
Кризис в стране, батенька, ещё не понятно что с вашими сикуэлами будет, а вот в виду проблем с импортом качественной техники мастера-ремонтники могут озолотиться😜
Видимо поиск считает, что с Вашими набором навыков неплохо себя и в разработке попробовать😀
Вот тут в охэхэнной истории про релиз Даня рассказал, почему мы переходили на GIthub Flow и почему нас не устроил подход trunk based.
Вкратце: хотели стабильный develop, при этом минимально вкладываться в инфраструктуру
А почему так мало мобильных разработчиков? Если нужна помощь в проникновение в сообщество (тот же Android Dev Podcast или Android Broadcast), пишите в личку
У нас на iOS симуляторы, а Android вообще в k8s запускаем!
Интересно послушать, как вы с реальным устройствами справляетесь!
Мы на заре нашего UI тестирования пробовали, но не смогли добиться стабильности
Прошу прощения, в сообщении выше перепутал платформы. На самом деле у нас так на текущий момент:
±390 Android
±452 iOS
У нас багфиксы умещаются внутри фичи. Дело в том, что тестирование фичей проходит в две стадии. Во время разработки QA обсуждает с разработчиком, что можно уже посмотреть, а куда лезть не стоит. Таким образом, когда фича начинает подходить к релизу QA начинает тестирование (пунктир на рисунке ниже). Перед тем, как влить фичу в develop, QA уже тестирует её и все, что можно задеть, капитально.
Таким образом мы получаем практически всегда стабильный develop. Да, конечно, туда может просочиться баг из-за мердж конфликтов или по невнимательности, но их уже фиксят обычно в релизной ветке. Исключения составляют, конечно же, те случаи, когда сломался develop.
Что касается времени прогона тестов и всех проверок — у нас есть вот такой вот дашборд:
Сейчас пришли к тому, что прогон выполняется около 40 минут на Android и около 50 минут на iOS
Чисто тесты проходят за минут 25 (взял рандомную ветку, поэтому число тестов отличается от того, что написал выше)
И да, кстати я вас обманул в первом сообщении, на самом деле распределение по числу тестов наоборот:
390 Android
452 iOS
Нет, не правильно поняли!
1) iOS и Android в разных репозиториях, поэтому тесты гоняются для каждой платформы отдельно
2) Ночные тесты гоняются на каждой фиче ветке и develop (на ветках разработческих не гоняем). Для ночного среза репозитория из примера(см картинку ниже) будет 3 прогона: 2 на больших фиче ветках и 1 на develop
3) Также гоняются тесты при PR в develop. Таких моментов на диаграмме изображено 3
Если просуммировать, то после 20 дневных коммитов может и не быть прогонов, если еще не настала ночь и мы не делали PR в develop. Так понятнее стало?
У нас два приложения в активной стадии разработки. Одно для соискателей (с которым все знакомы) уже довольно давно живет. В нём картина такая:
390 iOS
452 Android
Второе приложение для работодателей мы с нуля переписали недавно (это совсем другая история), его только сейчас начали покрывать тестами
Гоняются и в ночных прогонах и на PR в develop абсолютно все тесты. Это стало возможным благодаря уходу от trunk-based — не нужно каждый чих проверять на стабильность
Спасибо, мне постоянно казалось, что называем неправильно — похоже мы изобрели hh-flow. Погнали патентовать😃
Не понял, а у вас кроссплатформенные тесты на java?
А какой стек целиком? На сколько флакуют?
@Calcв прошлом году было аналогичное исследование, вот тут можно посмотреть результат
@benavir от себя еще предложил бы вам хотя бы временно уменьшить нагрузку на тестировщика. Вообще 1 к 7 это еще хуже чем в известной картинке!
Как можно снять нагрузку? Можно найти много способов, например:
Отправить двоих разрабов разрабатывать фреймворк и инфру для автотестов (это убьет сразу же двух зайцев, кстати)
Взять на пару месяцев аутстаф тестировщика на мануальное тестирование, чтобы разгрузить Вас (мы, кстати, так сделали, когда запускали автотестирование на втором приложении)
Дождаться, когда команда уйдет в отпуск ( перед новогодними, например)
Удачи Вам, поговорите, со своим руководителям о балансе сил!
Спасибо, отвечу инлайн!
Все-таки хочется один артефакт — так удобнее работать, ну и можно, как и говорил в статье/видео, для пользователей HMS+GMS приоритезировать HMS для каких-либо фичей
А какие еще видите минусы / риски?
У нас только смоук делается (и то не всегда), основные проверки автоматизированы. Да, для HMS-фичей они не гоняются, так как эмуляторы Huawei не может предоставить
Я, кстати не рекомендую использовать флейворы для разных вариантов кода! При включении варианта сборки остальные убираются из индекса IDE. А еще сборки идут строго друг за другом (баг тулзов наверное). Это крайне затрудняет разработку, лучше уж сделать на модулях + два различных приложения.
Это больше продуктовая история. Пока что сделали MVP технической командой. Если продакт посчитает необходимым добавить карты в HMS сборку, то да, будем рассматривать в том числе и кросссервисные (слово то какое придумал😃)варианты
Вы крутые, так держать!
Имеете в виду, что если кандидат не подошел, то пусть другие компании тоже видят? С одной стороны это интересная затея, так как оценка скиллов облегчит найм другим компаниям, но с другой — это попахивает каким-то социальным рейтингом, не находите? А эта штука прямо на грани!