Как стать автором
Обновить

Что лучше – 1 команда мобильной разработки или 15?

Время на прочтение5 мин
Количество просмотров8.8K
Всего голосов 24: ↑20 и ↓4+16
Комментарии24

Комментарии 24

Заценил архитектуру, весьма напоминает Riblets от убера. А что используете для Android?

В Android используется clean architecture (адаптированный под него). В presentation слое ребята используют MVP.
Ай, как больно это звучит
В presentation слое ребята используют MVP
Рекомендую изучить опыт построения интерфейсов приложений у «забугорных» банков. Например у Millennium можно увидеть баланс не вводя пин в приложении. Очень удобно. Многие велосипеды уже изобретены, нужно уметь подобрать комплектующие под наших «велосипедистов» )
Спасибо! У нас команда дизайнеров днями и ночами трудится над удобством интерфейса. Ребята проводят кучу разных исследований и экспериментов. А по поводу баланса – у нас тоже можно :) На iOS достаточно добавить виджет в центр уведомлений или использовать 3D Touch на иконке приложения.
Удивительно, но наши ИТ решения, в частности сайты и приложения, зачастую превосходят зарубежные. Видимо, сказывается доступность разработчиков.
Насколько я правильно понял, у вас несколько «модулей» разработки и в каждом по одному iOs/Android? Вам не кажется, что данный подход завышает «Bus Factor»?

В описании было сказано, что после сборки на Jenkins проект отдается QA на тестирование. Как обстоят дела с написанием AT (Automation Tests)?

Вы нанимаете «Middle & Middle+» — в целом, это обычная ситуация для рынка найма в России (Не хочу винить вашу компанию). И, на мой взгляд тут все гораздо проще. В России цены на Junior завышены (Вы можете нанять iOS Junior и он может просить у вас 1-1.3k$ и это нормально, вы потратите больше ресурсов на обучение). Middle же стоит дороже, но по бизнес модели это лучший способ вложения денег (1.5-2.2k$) и вы уже не тратите денег на обучение, однако он выполняет задачи бизнеса (Зачастую с косяками, но это работает… сейчас). Однако если вы хотите нанять Senior (3 — 4к$) то в рамках бизнеса это дорого. Гораздо проще нанять мидла, потратить полгода год на его заточку, а потом возникает «Период оседлости» когда уже и место нагрето и привык к команде.
Да, все верно. В одном «модуле» находится один представитель каждой роли. Такой подход позволяет сфокусироваться на определенной функциональности и реализовать её максимально качественно. Наша архитектура позволяет нам строго разделять ответственность каждого компонента, поэтому разобраться в новом модуле разработчику не составляет труда. Кроме того, у нас проводится кросс-командное ревью кода.

После сборки проект не отдается QA в прямом смысле. Представитель QA уже находится внутри команды. По поводу автотестов – они пишутся внутри команды, параллельно разработке. Таким образом, по завершению итерации разработки, у нас есть функциональность, юнит тесты и автотесты. Автотесты пишет тестировщик (тот самый представитель QA).

А тесты в процессе разработки пишутся по TDD? Или потом, когда весь код уже написан?

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

Ну и в каких командах разработчики счастливее? В тех, что используют TDD, или в тех, где TDD не используется?


Считаете ли вы важной возможность повторного использования кода? Практикуется ли повторное использование кода, в том числе кода, написанного другой командой?

Разработчики, которые познали дзен TDD, как минимум меньше переписывают свой код. Мы сейчас проводим внутреннее обучение, так что скоро все наши разработчики будут уметь разрабатывать код с использованием TDD.

При таком количестве команд и том количестве кода, которое они производят было бы неразумно отметать возможность переиспользовать что-либо. У нас есть дизайн система и библиотека UI-компонент, которые позволяют достаточно быстро собирать UI для новых разделов или целых приложений. Бизнес логика, которая может быть переиспользована тоже выносится в отдельные компоненты (и обязательно покрывается тестами).

Улучшает ли использование TDD внутренний дизайн приложений? Позволяет ли качество написанных тестов считать их исполняемой документацией по коду?

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

Бальзам на душу. А я то уж думал что у меня одного такое положительное ощущение от использования TDD.

Как-то непонятно в течении статьи пропадает Android разработка.
Сначала упоминается в составе команды Android разработчики,
а потом swift, appstore и остался только iOS. По ходу статьи всех разработчиков под Android уволили?

Никого не уволили :) Статья описывает общие процессы, которые в Android-разработке очень похожи. Если есть какие-то конкретные вопросы, то я с радостью узнаю у коллег и напишу ответ.
А под Windows уже все? Обновлений не будет?
Имеется в виду Windows Phone? Если да, то Microsoft остановил разработку и поэтому мы больше не развиваем приложение под эту платформу.
Windows 10 Mobile.
Жаль :( — MS, конечно нехорошие люди! По мне так платформа гораздо лучше, чем Android.
на какой-то раздел приложения заходят только 2 процента пользователей, а остальные 98% – игнорируют его. Обычно это намекает на удобство расположение раздела или на его смысл вообще

Можете рассказать, почему в недавнем апдейте андроид приложения экран "информация о счёте" переместился на один тап вглубь? Раньше была кнопочка рядом с суммой денег на карте.


(Неужели я вхожу в те 2%, которые в приложении только смотрят, когда кончается льготный период.)

Мы проводим много экспериментов и это как раз один из них. Раздел дорабатывается и скоро будет ряд улучшений.
Используете ли вы A/B Testing?
Да, мы разработали гибкую систему, которая позволяет проводить большое количество экспериментов одновременно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий