Начнем с различий в типах команд разработки: 1- и кросс- платформенных/функциональных.
Насколько интересно для вас сравнение опыта в таких командах и работали ли вы в обоих типах?
🤔
41.2% Интересно - работал🤔
17.6% Не интересно - работал🤔
29.4% Интересно- только в одной🤔
11.8% Не интересно - только в 1Большинство голосует за "интересно" - продолжаем 😎
Мне удалось поработать и в той и другой.
Интерес к новому для меня формату стал одной из основных причин подтолкнувших к переходу между компаниями.
Начнем с 1-платформенных.
Больше 4 лет я проработал в одной команде разработки Кaspersky Intеrnet Sеcurity 4 Andrоid.
И попал в неё совсем случайно стажёром-тестировщиком (но не про это сейчас).
Постепенно перешел в стажёры-девелоперы, а затем уже вверх по лестнице.
В моём опыте 1-платформенная команда (одного продукта), это когда примерно 6-10 Android-разработчиков, 5 тестировщиков, PM и пара аналитиков делают один продукт под одну платформу.
Конкретно в Лаборатории эта команда входила в большую единицу - Мобильный департамент, где разрабатывают другие приложения под Android, iOS и не только.
Фронт работ в этом департаменте в основном ограничен клиентской разработкой под мобилки. Backend, frontend, десктопные продукты - это отдельные команды, в другом здании.
Даже до Covid было минимальное количество пересечений с ребятами из других функций, а уж тем более понимания, как они работают.
А контракты API приходили к нам обернутыми в C++ библиотеку из третьих команд.
К тому же у бека почти всегда не хватало ресурсов, и часто было проще сделать какую-то логику на клиенте, чем дождаться бек.
От этого клиент становился довольно таким толстым и давал возможность попробовать разные архитектурные подходы.
Если резюмировать, плюсы работы в Android-only команде:
Глубокое понимание платформы
Хорошая возможность для роста - множество коллег одного профиля работают рядом и помогают
2а) В моем случае вообще повезло - т.к. тимлидом был сам @e_matsyuk
Как сейчас - в кросс-функциональной команде:
1-Android, 1-iOS, 1-2 - Web, 1-3 - Back, 2 - аналитики, 1 - product manager.
И все эти люди придумывают и разрабатывают примерно одинаковые части для одной фичи - авторизации.
В силу доменной специфики, большая часть логики - на беке. Основная сложность логики на клиенте - навигация между различными флоу регистрации и авторизации.
Для примера: TFA, вход через социальные сети, восстановление доступа и их различные комбинации.
Теперь к минусам кросс-функциональных команд.
В команде я - один разработчик под Android. Чтобы что-то спросить/узнать - нужно идти в другие команды или на встречи Android Community. Это может быть не очень комфортным на ранних этапах карьеры.
(продолжение минусов кросс-ф.)
2) Зона ответственности ограничивается одной функциональной областью - версткой и логикой в ней. Чтобы узнать что-то больше, нужно идти "помогать" в платформенные команды (для погружения) или брать задачи других продуктовых команд (смена домена).
Плюсы кросс-функциональных команд:
Бек рядом. Можно обсудить удобные для всех контракты, либо реализовать сценарий с меньшими сложностями.
Можно посмотреть, как сделано на беке и узнать про корнер-кейсы.
(продолжение плюсов кросс-ф.)
3) Можно сходить посмотреть, как то же самое сделано у других клиентов (iOS, web), перенять какие-то подходы.
4) Можно задуматься о реюзе кода с клиентами.
5) Легче начать t-shape / отдохнуть от своей платформы.
Андрей Берюхов