Android Software Engineer
Каждый день мы работаем над улучшением наших проектов. Будь то инициатива заказчика, продукт корпорации либо Ваш собственный. Изучая отзывы пользователей своего проекта, я столкнулся с запросом ускорить действия пользователя на одном из ключевых экранов. Это можно делать разными способами - разбиение экрана на несколько, улучшение UI… Но рано или поздно придется прорабатывать UX.
MVP - говоря простым языком, это продукт, который готов к выходу на рынок с минимальной функциональностью чтобы достичь определенных целей. Это может быть и маркетинг, и привлечение новых клиентов, и обкатывание собственных PoC. Цели могут быть разными. Я опущу этот момент, потому что набор фичей, о которых пойдет речь дальше, закрывает 90 процентов потребностей всех целей и дает возможность на маневр. Это очень важно сделать в самом начале, чтобы не забуксовать в фазе активной разработки, дать возможность проверять свои гипотезы и не тормозить бизнес в зарабатывании денег.
Готовим FeatureToggle для Android
Всем привет, меня зовут Илья, я андроид инженер. Почти три года назад, мы начали свой проект в сфере финтех. Срок запуска MVP был оптимистичным. За неделю до наступления дедлайна наша команда осознала, что срок запуска переносить никто не собирается, а одна фича вряд ли будет закончена вовремя. Рисковать не хотелось и было решено - прикрыть эту часть заглушкой. Блокируя часть нерабочей функциональности, мы питали надежды, что скоуп MVP будет закрыт. По-этому, выключить нерабочий код хотели так, чтобы по щелчку кнопки CI/Web экран стал доступен для пользователя.
Постепенно, штат сотрудников разрастался и далеко не все понимали что это такое. Гайд так же был необходим и для внутренних сотрудников. Один источник данных - одна правда для всех. Пришлось добавить не только библиотеку для форсирования, но и перестроить процесс разработки.
Откровенно говоря, разговоры внутри команды о внедрении FeatureToggling шли уже давно. Эта история стала спусковым крючком для его внедрения.
Всем привет, меня зовут Илья и я хочу поделиться своим опытом релокейта из Беларуси в Польшу.
С середины 2020 года Польша открыла возможность получения визы для сотрудников и предпринимателей в сфере IT по специальной программе PBH. В период европейского локдауна, это был один из немногих прозрачных способов получения шенген визы. Мне повезло, и моя компания предложила релокацию для желающих этого сотрудников. Как итог, в декабре 2020 года я начал путь в новой стране. В статье я постараюсь ответить на вопросы как для потенциальных релокантов, так и для тех, кто уже начал свой путь в стране.
Работая над одним проектом продолжительное время, я заметил как приходится переписывать код, который еще три месяца назад казался хорошим. Инженерам поступают новые требования, когда они не пересекаются с предыдущими - все отлично, добавили пару новых классов и побежали дальше. Иногда они касаются уже выпущенной части - взмах синей изолентой и все работает. Но наступает тот самый момент, когда цена внесения изменений катастрофически дорога и единственной рациональное решение - переписать все... А можно ли писать код, не переписывая его в будущем или хотя бы отложить этот момент на более долгий срок?
Я хочу рассказать про практики, которые не один раз уже выручали нас в проекте. Подборка примеров получилась не на пустом месте, все реальные примеры PullRequest-ов.
Все примеры НЕ выдуманные и тестировались на живых людях. В процессе сбора данных несколько людей пострадало.
- Все хорошо, только перед влитием обязательно засквошь коммиты.
- Заскво...Что?Примерно такая реакция была у меня после получения апрува первого пул реквеста на первой неделе работы в одной крупной компании. Причина такой реакции весьма простая — далеко не каждый заказчик/работодатель может себе позволить такую роскошь как большая команда на одну платформу, в особенности это касается мобильной разработки. Из-за ненадобности и возможности быстрой коммуникации в своем мирке, далеко не все вещи, которые используют крупные мастера своего дела, обретают актуальность в небольших командах. Говоря проще — а на кой мне это надо, если мы и так хорошо без этого жили и хорошо справлялись?
После перехода в новую компанию я столкнулся с той же проблемой, но уже по другую сторону баррикад. Если вы еще не догадались о чем пойдет речь дальше — это GIT, говоря точнее, его встроенный инструментарий в AndroidStudio и как он позволяет сделать нашу работу проще.
Я постараюсь не обращать внимания на банальные вещи: init VCS; new/rename/push branch; rebase/merge onto branch; setup remotes e.t.c. Я постараюсь обратить внимание на те элементы, которые по боязни своего незнания, я долгое время избегал(и жалею).
Из далекого 2012, на просторах Хабра мне запомнился коммент:
… если нет корпуса с самого начала, то устройство так и останется
недоделанным, ляжет пылиться на полке...
Топик далеко не про хардварную составляющую. Разбирая свою проблему, я убедился в верности сия суждения и постарался навести порядок на своей пыльной полке.
Недавно ко мне обратился заказчик, который попросил добавить в его проект поддержку нескольких сервисов. Задача заключалась в том, что мне нужно было подключить сервис "А" и перед выкладкой приложения в продакшн, обкатать этот сервис на тестовом окружении. Я решил проанализировать свои предыдущие решения и… ужаснулся.
Для различного типа сборок я использовал различные конфигурационные файлы с описанием переменных окружения. Но проблема заключалась в том, что только лишь для проброса значения в реальный код, на каждый тип приходилось писать один и тот же код.