У плагина из статьи есть один серьезный недостаток - чтобы переделать шаблон, надо перевыпустить плагин. В Geminio мы сделали так, чтобы файлы шаблонов были отделены от плагина.
В современных Android-приложениях для выноса общей конфигурации давно можно использовать стандартную фичу Gradle, которая называется convention plugins.
Для примера использования можно посмотреть на проект Google Now in Android или же на проект команды Avito - avito-android.
Лучше потратить пару вечеров и разобраться, чем создавать своё решение с нуля.
Привет!
Ты имеешь в виду, что у нас нет отдельного этапа, где мы новичку показываем как работать в Jira?
Действительно, какого-то явного выделенного этапа знакомства с Jira у нас нет. Но новичок присоединяется к ежедневным синкам уже со второго дня. И мы сразу поясняем, что вот есть доска, на ней такие статусы, вот так мы проходим по нашим доскам, чтобы отследить прогресс по задачам. Через пару недель новичок уже сам проведёт синк, и закрепит то, что будет слышать каждый день.
В целом, Jira — это стандарт в индустрии, все с ней более-менее знакомы, процессы в мобильных командах не такие уникальные и сложные, чтобы для их освоения нужен был отдельный курс =)
Типов задач у нас действительно много — тут и PORTFOLIO, и MOB-ы, и FEAR-ы, и HHS-ки и т.д, и т.п. Но стоит ли вкидывать в нового человека информацию сразу обо всех?.. Кажется, что нет. С PORTFOLIO (набор связанных задач) и MOB (обычные задачи) всё станет ясно на первом синке.
В первые недели новичок мало что делает с Jira самостоятельно, кроме перевода задач из OPEN в NEED REVIEW. Если его заинтересуют непонятные аббревиатуры типов задач — есть ментор, он ответит.
Привет! Спасибо за статью.
Возникло несколько вопросов:
Насколько вам удобен получившийся формат вывода отчёта? Со стороны кажется, что придётся тратить дополнительное время, чтобы отыскать нужное место в коде. Мы такое у себя решали с помощью вывода специальной ссылки и плагина Remote Call. Разработчик нажимает на ссылку, переходит в Android Studio, а там у него уже открыт нужный файл и курсор на нужной строке стоит.
Я правильно понял, что у вас отдельные docker-контейнеры под сборку APK и под запуск статического анализа? Если да, то не очень понятно зачем это нужно, буду рад пояснениям.
Немного оффтопный вопрос: а почему используете ktlint, а не detekt? У detekt-а же есть набор правил из ktlint-а, плюс у danger-а уже есть плагин для detekt-а.
Если вы разделяли вёрстку и логику работы экрана — у вас поменяется только UI-слой. Если же было всё вперемешку, тогда конечно, у вас произойдут какие-то изменения.
Мы в hh экраны делаем с помощью UDF-подхода, фрагмент — это только про UI, логика контролируется из ViewModel. Поэтому для нас просто поменялся код UI-слоя.
Про лапшу в коде View — могу согласится лишь отчасти: да, в Jetpack Compose-е получается больше переносов строк, больше скобочек, но так как сами функции не очень большие, читать-то по-прежнему удобно. В XML-е не всегда так легко получалось выносить общий код, как с Compose.
А ещё — «другими людьми» — это кем? Мы просто не делим разработчиков на «UI-верстальщиков» и хардкорных «логиков», которые не имеют к UI отношения =) Все пишут всё =)
По сравнению с самописными декларативными фреймворками, Compose, конечно, впереди планеты всей — хотя бы за счёт официальной поддержки от Google и уже встроенными перерисовками нужных кусочков, рекомпозициями, мемоизациями. Самому такую махину функциональности поддерживать, мягко говоря, непросто =) А накидывать UI в стиле Telegram-а — трудно потом код будет читать.
До Compose-а уже были попытки занять нишу декларативных фреймворков:
— Был Litho от Meta-а. У Сергея Рябова был прекрасный доклад на Mobius-е про этот фреймворк. Там тоже были переиспользуемые кусочки UI, автоматическое построение UI на основе «спек». Плюс Meta очень заморачивался над тулингом (делали специальный плагин для preview, свой layout inspector, etc) и оптимизациями (рассчитывали самое оптимальное количество View на экране, без ViewGroup, старались не использовать тяжёлые Android View, заменяли их на TextDrawable / ImageDrawable / etc). При этом был annotation processor, когда смотрел — была только экспериментальная поддержка Kotlin-а. На мой вкус, код на Compose выглядит попроще, нет java builder-ов, удобный Kotlin DSL.
— Ещё был Inkremental. На канале Android Broadcast у Кирилла было когда-то интересное интервью с ребятами, разрабатывающими этот фреймворк. У ребят был похожий на Jetpack Compose синтаксис, тоже Kotlin DSL, они тоже смогли сделать изменение UI на основе state-а. Мы в hh даже хотели одно время его попробовать, но пока собирались, уже вышел Compose =))) Чем нас тогда привлёк этот фреймворк, миграция на него выглядела даже проще, чем миграция на Compose, потому что создали Inkremental смапили уже имеющиеся вьюшки из Android SDK максимально похожим образом.
В общем, решений раньше было много, но я не уверен, что нужно ли что-то сейчас кроме Compose-а, если вы до этого не использовали других фреймворков.
Привет!
Давайте по порядку отвечу на каждый вопрос.
1. Стал бы делать это на своём проекте
Зависит от проекта. Если это проект не горящий, который можно разрабатывать не торопясь, то да, однозначно стал бы. Мне нравится Compose, нравится декларативный подход, нравится писать маленькие и переиспользуемые кусочки интерфейса.
Если же проект был бы срочным, я бы задумался. Но, пожалуй, всё равно стал бы затаскивать, тем более что интероп работает, и к фрагментам и XML-вьюхам можно всегда перейти.
2. Ради чего вы это делали
Пара причин:
— интересно пробовать новую технологию, чтобы не отставать от трендов и не чувствовать себя мамонтом
— за Compose-ом будущее Android-разработки (а то и мультиплатформенной), уже сейчас хочется понимать, насколько больно будет на него мигрировать.
3. Стал ли код проще
В каких-то кейсах — стало проще в разы. Я привёл в статье пример с ячейками — на XML-е у нас получилось довольно громоздкое решение со множеством подводных камней.
В некоторых кейсах — наоборот, стало сложнее, за счёт того, что Jetpack Compose всё ещё молодая технология и нет каких-то готовых решений для привычных в XML-е вещей: тот же CollapsingToolbar в нашем примере (да, есть уже Material-вариант с Top App Bar, но у нас сходу это не завелось), или отсутствие minLines в TextView.
В остальных кейсах — получается примерно 50 на 50 — где-то проще, где-то посложнее.
4. Стал ли код читабельнее
В Compose-коде приходится делать множество переносов строк, куча вложенных конструкций, куча фигурных скобок, порой немного теряешься. Но в какой-то момент привыкаешь и начинаешь читать так же, как в XML. Субъективно, стало чуть тяжелее.
5. Стал ли размер приложения меньше
Нет, стал даже больше =) Мы не сразу выпилить весь XML-код, который мы писали последние 8 лет, поэтому мы подключили ещё библиотек к приложению, не выпиливая другие.
6. Стала ли работа быстрее
Пока что разрабатывать стало сильно-то и быстрее. Потому что, как я уже говорил, технология молодая, далеко не на каждый вопрос есть ответ на StackOverflow, далеко не всё получается быстро нагуглить. Иногда после походов в google ты находишь только открытое issue в Issue Tracker-е с той же проблемой, что и у тебя.
А вопросов пока что возникает много и часто, особенно у коллег, которые только-только начинают пробовать работать с Compose-ом. Иногда мы сталкиваемся с тем, что реализованный по-быстрому компонент работает плохо, его неудобно использовать, и нам приходится тратить дополнительное время на дотюнивание написанного кода.
Но зато когда все компоненты для экрана готовы, UI накидывается довольно быстро и весело.
7. Если бы использовался старый программный подход, результат был бы хуже / лучше?
Результат точно не был бы хуже, хотя бы за счёт уже полностью готовой дизайн-системы на XML и множества отлаженных решений в нашей кодовой базе.
Был бы результат лучше — в смысле, с точки зрения удобства / скорости разработки? Тут скажу, что на XML просто привычнее разрабатывать, особенно если вы программируете под Android давно. Каждый вопрос легко гуглится, у всех коллег есть опыт решения тех или иных проблем, костыли известны. Поэтому разработка с использованием XML пока что более предсказуема по времени, чем разработка с Compose-ом.
Уточните, пожалуйста, про какую статью говорите? Вроде бы под статьёй про GraphQL наши разработчики ответили на все вопросы, которые им задали.
Если насчёт статьи про отправку уведомлений, то автора статьи уже пинганули, ответит в ближайшее время.
Когда заметите где-нибудь ещё, пишите — можете либо мне в личку, либо автору в личку, либо в наш телеграм-канал «HH Tech Talks», там сидят практически все авторы нашего блога, они ответят на любые вопросы.
1) Про писать текст доклада заранее — для себя я обычно так и делаю, многие наши спикеры тоже это практикуют, но далеко не все. Некоторые предпочитают иметь просто хорошую структуру и наговаривать текст исключительно по ней.
Когда у нас есть написанный текст, мы, разумеется, отдаём его нашему расшифровщику, чтобы тому было проще (я сам когда-то расшифровывал наш первый видос про дизайн-систему, к концу не хотелось ничего). У меня чешутся руки как-нибудь попробовать какую-нить питоновскую библиотечку для распознавания голоса, чтобы вообще автоматически расшифровывать видео, но всё никак не доберусь.
2) Официально в hh нет DevRel-а, в плане, что действительно нет такой ставки =) Я нигде не работал DevRel-ом, но активно пользуюсь опытом своих более опытных коллег, плюс чемпион — не единственный член команды, такого я нигде не говорил) Со статьями на основе докладов нам помогает редактор, со съёмками и монтажом — режиссёр и монтажёр, с переводами — переводчик. Я со своей стороны помогаю нашим спикерам готовиться к записи: отсматриваю тексты докладов, их прогоны, отписываю им обратную связь. Хочется верить, что после этого их доклады становятся лучше.
Текст для этой статьи взят из моего выступления, над ним немного поработал редактор, я добавил ссылочек, картинок, спойлеров, потом снова отдал редактору. Всё происходит ровно так, как я описал в статье =)
3) Сколько времени уходит на чемпионство — очень зависит от количества докладов, которые надо подготовить к определённой дате. Когда готовить никого не нужно, а нужно заниматься только project management-ом, это отнимает не очень много времени. Когда надо подготовить трёх спикеров за одну неделю — это серьёзная нагрузка, которая действительно может отъесть половину рабочего времени.
Страдает ли основная работа: большую часть времени я работаю в платформенной команде, где сроки не так критичны, как в продуктовых командах. Когда работаю в продуктовых командах, тут, конечно, сроки начинают сдвигаться, чтобы не сдвинулся я сам =)
З.Ы. Если у вас есть на примете полезные видео и статьи по теме — скидывайте, мне интересно =)
Согласен, можно пользоваться и Psi Viewer-ом. Однако, если включить internal-инструменты, можно получить доступ и к куче других полезных инструментов =)
Про codegen через Gradle — расскажите поподробнее, не очень понял, как бы это делалось. Если есть какие-то статейки на примете — отлично.
Обычно именно с Gradle-ом начинаются «танцы с бубнами» =)
Зачем мы запускаем дебажное приложение — чтобы менять значение флагов внутри приложения. Это полезно и для тестировщиков, и для разработчиков, так что мы от этого не уйдём. Просто увидеть все эксперименты в проекте можно было бы и навигацией по коду, типо «найти всех наследников интерфейса Experiment» — нам этого недостаточно =)
Нам нужно было собрать все классы для последующего инстанцирования и использования.
1) Посмотрел видео, по диагонали почитал книгу.
Моя статья мало имеет отношения к тому, о чём говорит профессор Шалыто =)
Он рассказывает о построении логики программ на основе стейт-машин / конечных автоматов (или об «автоматной парадигме программирования», если в терминах профессора). Стейт-машины — полезный инструмент, который Android-разработчики давно взяли на вооружение. Мы в hh практически каждую фичу описываем именно с их помощью.
Но писать абсолютно на каждый чих стейт-машины — это, во-первых, лишнее усложнение программ, во-вторых — не всегда возможно. Вот перед вами задача: в зависимости от объекта, пришедшего от сервера, покрасить кнопку в зелёный или синий цвет. Здесь стейт-машина не нужна, тут нужен простой boolean-флаг.
По сути, о таких простых флагах и идёт речь в статье.
Иногда флаги появляются и для описания переходов внутри стейт-машин, кстати. Немного странно делать 2 стейт-машины в этом случае, гораздо проще описать дополнительный if для одного перехода.
P.S. Лично мне показалось, что структура тех стейт-машин (автоматов), о которых рассказывает профессор, недостаточно гибкая. В частности, не увидел в структуре способе отдать единичное событие из машины наружу. А такое иногда требуется — например, показать снекбар при переходе в состояние ошибки. Каким-то полем внутри State-а это делать неудобно.
2) «Надо не собирать, надо не разбрасывать.»
Недостаточно понятная для зумера сентенция =) Уточните, что имеете в виду, как именно надо было «не разбрасывать»?
Вот есть проблема: если «не разбрасывать» и помещать код в один-единственный файл (неважно, в виде enum-а, в виде отдельных функций или ещё как-нибудь) — появятся merge-конфликты, от которых мы хотели уйти.
Если размещать в разных файлах (то бишь, «разбрасывать»), merge-конфликты уходят, но надо будет собирать всё обратно в единый список.
Хочется увидеть конкретное решение, которое вы предлагаете, реализацию в коде. Необязательно на Java, но тогда есть шанс, что вы используете какую-то специфичную для определённого языка конструкцию, которой просто не существует для Android-разработки.
Это, конечно, правда =)
Но автор статьи вроде писал про android-проекты :thinking_face:
Спасибо за статью!
Вопрос - чего не хватило в Geminio (https://github.com/hhru/android-multimodule-plugin/tree/master/plugins%2Fhh-geminio) от hh?
У плагина из статьи есть один серьезный недостаток - чтобы переделать шаблон, надо перевыпустить плагин. В Geminio мы сделали так, чтобы файлы шаблонов были отделены от плагина.
В современных Android-приложениях для выноса общей конфигурации давно можно использовать стандартную фичу Gradle, которая называется convention plugins.
Для примера использования можно посмотреть на проект Google Now in Android или же на проект команды Avito - avito-android.
Лучше потратить пару вечеров и разобраться, чем создавать своё решение с нуля.
Две недели, ого!
А новичок пояснил, что его так задержало?..
Привет!
Ты имеешь в виду, что у нас нет отдельного этапа, где мы новичку показываем как работать в Jira?
Действительно, какого-то явного выделенного этапа знакомства с Jira у нас нет. Но новичок присоединяется к ежедневным синкам уже со второго дня. И мы сразу поясняем, что вот есть доска, на ней такие статусы, вот так мы проходим по нашим доскам, чтобы отследить прогресс по задачам. Через пару недель новичок уже сам проведёт синк, и закрепит то, что будет слышать каждый день.
В целом, Jira — это стандарт в индустрии, все с ней более-менее знакомы, процессы в мобильных командах не такие уникальные и сложные, чтобы для их освоения нужен был отдельный курс =)
Типов задач у нас действительно много — тут и PORTFOLIO, и MOB-ы, и FEAR-ы, и HHS-ки и т.д, и т.п. Но стоит ли вкидывать в нового человека информацию сразу обо всех?.. Кажется, что нет. С PORTFOLIO (набор связанных задач) и MOB (обычные задачи) всё станет ясно на первом синке.
В первые недели новичок мало что делает с Jira самостоятельно, кроме перевода задач из OPEN в NEED REVIEW. Если его заинтересуют непонятные аббревиатуры типов задач — есть ментор, он ответит.
Спасибо за ответы)
Наверное потому что нигде не упоминалось, что вы эту настройку встроили в уже существующий контейнер) Хорошо, что я неправильно понял просто)
Привет! Спасибо за статью.
Возникло несколько вопросов:
Насколько вам удобен получившийся формат вывода отчёта? Со стороны кажется, что придётся тратить дополнительное время, чтобы отыскать нужное место в коде. Мы такое у себя решали с помощью вывода специальной ссылки и плагина Remote Call. Разработчик нажимает на ссылку, переходит в Android Studio, а там у него уже открыт нужный файл и курсор на нужной строке стоит.
Я правильно понял, что у вас отдельные docker-контейнеры под сборку APK и под запуск статического анализа? Если да, то не очень понятно зачем это нужно, буду рад пояснениям.
Немного оффтопный вопрос: а почему используете ktlint, а не detekt? У detekt-а же есть набор правил из ktlint-а, плюс у danger-а уже есть плагин для detekt-а.
Мы в hh экраны делаем с помощью UDF-подхода, фрагмент — это только про UI, логика контролируется из ViewModel. Поэтому для нас просто поменялся код UI-слоя.
Про лапшу в коде View — могу согласится лишь отчасти: да, в Jetpack Compose-е получается больше переносов строк, больше скобочек, но так как сами функции не очень большие, читать-то по-прежнему удобно. В XML-е не всегда так легко получалось выносить общий код, как с Compose.
А ещё — «другими людьми» — это кем? Мы просто не делим разработчиков на «UI-верстальщиков» и хардкорных «логиков», которые не имеют к UI отношения =) Все пишут всё =)
По сравнению с самописными декларативными фреймворками, Compose, конечно, впереди планеты всей — хотя бы за счёт официальной поддержки от Google и уже встроенными перерисовками нужных кусочков, рекомпозициями, мемоизациями. Самому такую махину функциональности поддерживать, мягко говоря, непросто =) А накидывать UI в стиле Telegram-а — трудно потом код будет читать.
До Compose-а уже были попытки занять нишу декларативных фреймворков:
— Был Litho от Meta-а. У Сергея Рябова был прекрасный доклад на Mobius-е про этот фреймворк. Там тоже были переиспользуемые кусочки UI, автоматическое построение UI на основе «спек». Плюс Meta очень заморачивался над тулингом (делали специальный плагин для preview, свой layout inspector, etc) и оптимизациями (рассчитывали самое оптимальное количество View на экране, без ViewGroup, старались не использовать тяжёлые Android View, заменяли их на TextDrawable / ImageDrawable / etc). При этом был annotation processor, когда смотрел — была только экспериментальная поддержка Kotlin-а. На мой вкус, код на Compose выглядит попроще, нет java builder-ов, удобный Kotlin DSL.
— Ещё был Inkremental. На канале Android Broadcast у Кирилла было когда-то интересное интервью с ребятами, разрабатывающими этот фреймворк. У ребят был похожий на Jetpack Compose синтаксис, тоже Kotlin DSL, они тоже смогли сделать изменение UI на основе state-а. Мы в hh даже хотели одно время его попробовать, но пока собирались, уже вышел Compose =))) Чем нас тогда привлёк этот фреймворк, миграция на него выглядела даже проще, чем миграция на Compose, потому что создали Inkremental смапили уже имеющиеся вьюшки из Android SDK максимально похожим образом.
В общем, решений раньше было много, но я не уверен, что нужно ли что-то сейчас кроме Compose-а, если вы до этого не использовали других фреймворков.
Привет!
Что имеете в виду?
Если "работает ли NavBar внутри вашего приложения" — то, что мы в hh называем NavBar-ом — работает и используется на множестве экранов.
Если "работают ли ссылки на реализацию NavBar-а" — да, ссылки, которые я прикрепил открываются корректно, ведут на правильные куски кода.
Если имеете в виду что-то другое, уточните, пожалуйста.
Давайте по порядку отвечу на каждый вопрос.
1. Стал бы делать это на своём проекте
Зависит от проекта. Если это проект не горящий, который можно разрабатывать не торопясь, то да, однозначно стал бы. Мне нравится Compose, нравится декларативный подход, нравится писать маленькие и переиспользуемые кусочки интерфейса.
Если же проект был бы срочным, я бы задумался. Но, пожалуй, всё равно стал бы затаскивать, тем более что интероп работает, и к фрагментам и XML-вьюхам можно всегда перейти.
2. Ради чего вы это делали
Пара причин:
— интересно пробовать новую технологию, чтобы не отставать от трендов и не чувствовать себя мамонтом
— за Compose-ом будущее Android-разработки (а то и мультиплатформенной), уже сейчас хочется понимать, насколько больно будет на него мигрировать.
3. Стал ли код проще
В каких-то кейсах — стало проще в разы. Я привёл в статье пример с ячейками — на XML-е у нас получилось довольно громоздкое решение со множеством подводных камней.
В некоторых кейсах — наоборот, стало сложнее, за счёт того, что Jetpack Compose всё ещё молодая технология и нет каких-то готовых решений для привычных в XML-е вещей: тот же CollapsingToolbar в нашем примере (да, есть уже Material-вариант с Top App Bar, но у нас сходу это не завелось), или отсутствие minLines в TextView.
В остальных кейсах — получается примерно 50 на 50 — где-то проще, где-то посложнее.
4. Стал ли код читабельнее
В Compose-коде приходится делать множество переносов строк, куча вложенных конструкций, куча фигурных скобок, порой немного теряешься. Но в какой-то момент привыкаешь и начинаешь читать так же, как в XML. Субъективно, стало чуть тяжелее.
5. Стал ли размер приложения меньше
Нет, стал даже больше =) Мы не сразу выпилить весь XML-код, который мы писали последние 8 лет, поэтому мы подключили ещё библиотек к приложению, не выпиливая другие.
6. Стала ли работа быстрее
Пока что разрабатывать стало сильно-то и быстрее. Потому что, как я уже говорил, технология молодая, далеко не на каждый вопрос есть ответ на StackOverflow, далеко не всё получается быстро нагуглить. Иногда после походов в google ты находишь только открытое issue в Issue Tracker-е с той же проблемой, что и у тебя.
А вопросов пока что возникает много и часто, особенно у коллег, которые только-только начинают пробовать работать с Compose-ом. Иногда мы сталкиваемся с тем, что реализованный по-быстрому компонент работает плохо, его неудобно использовать, и нам приходится тратить дополнительное время на дотюнивание написанного кода.
Но зато когда все компоненты для экрана готовы, UI накидывается довольно быстро и весело.
7. Если бы использовался старый программный подход, результат был бы хуже / лучше?
Результат точно не был бы хуже, хотя бы за счёт уже полностью готовой дизайн-системы на XML и множества отлаженных решений в нашей кодовой базе.
Был бы результат лучше — в смысле, с точки зрения удобства / скорости разработки? Тут скажу, что на XML просто привычнее разрабатывать, особенно если вы программируете под Android давно. Каждый вопрос легко гуглится, у всех коллег есть опыт решения тех или иных проблем, костыли известны. Поэтому разработка с использованием XML пока что более предсказуема по времени, чем разработка с Compose-ом.
Если насчёт статьи про отправку уведомлений, то автора статьи уже пинганули, ответит в ближайшее время.
Когда заметите где-нибудь ещё, пишите — можете либо мне в личку, либо автору в личку, либо в наш телеграм-канал «HH Tech Talks», там сидят практически все авторы нашего блога, они ответят на любые вопросы.
Я имел в виду адаптирование большого монстра hh к новому фреймворку) ну или наоборот, приспособление Compose-а внутри нашего приложения)
Слово «Адаптация» сильно повлияло на ваше восприятие статьи? Чего не хватило?
1) Про писать текст доклада заранее — для себя я обычно так и делаю, многие наши спикеры тоже это практикуют, но далеко не все. Некоторые предпочитают иметь просто хорошую структуру и наговаривать текст исключительно по ней.
Когда у нас есть написанный текст, мы, разумеется, отдаём его нашему расшифровщику, чтобы тому было проще (я сам когда-то расшифровывал наш первый видос про дизайн-систему, к концу не хотелось ничего). У меня чешутся руки как-нибудь попробовать какую-нить питоновскую библиотечку для распознавания голоса, чтобы вообще автоматически расшифровывать видео, но всё никак не доберусь.
2) Официально в hh нет DevRel-а, в плане, что действительно нет такой ставки =) Я нигде не работал DevRel-ом, но активно пользуюсь опытом своих более опытных коллег, плюс чемпион — не единственный член команды, такого я нигде не говорил) Со статьями на основе докладов нам помогает редактор, со съёмками и монтажом — режиссёр и монтажёр, с переводами — переводчик. Я со своей стороны помогаю нашим спикерам готовиться к записи: отсматриваю тексты докладов, их прогоны, отписываю им обратную связь. Хочется верить, что после этого их доклады становятся лучше.
Текст для этой статьи взят из моего выступления, над ним немного поработал редактор, я добавил ссылочек, картинок, спойлеров, потом снова отдал редактору. Всё происходит ровно так, как я описал в статье =)
3) Сколько времени уходит на чемпионство — очень зависит от количества докладов, которые надо подготовить к определённой дате. Когда готовить никого не нужно, а нужно заниматься только project management-ом, это отнимает не очень много времени. Когда надо подготовить трёх спикеров за одну неделю — это серьёзная нагрузка, которая действительно может отъесть половину рабочего времени.
Страдает ли основная работа: большую часть времени я работаю в платформенной команде, где сроки не так критичны, как в продуктовых командах. Когда работаю в продуктовых командах, тут, конечно, сроки начинают сдвигаться, чтобы не сдвинулся я сам =)
З.Ы. Если у вас есть на примете полезные видео и статьи по теме — скидывайте, мне интересно =)
Про codegen через Gradle — расскажите поподробнее, не очень понял, как бы это делалось. Если есть какие-то статейки на примете — отлично.
Обычно именно с Gradle-ом начинаются «танцы с бубнами» =)
Зачем мы запускаем дебажное приложение — чтобы менять значение флагов внутри приложения. Это полезно и для тестировщиков, и для разработчиков, так что мы от этого не уйдём. Просто увидеть все эксперименты в проекте можно было бы и навигацией по коду, типо «найти всех наследников интерфейса Experiment» — нам этого недостаточно =)
Нам нужно было собрать все классы для последующего инстанцирования и использования.
1) Посмотрел видео, по диагонали почитал книгу.
Моя статья мало имеет отношения к тому, о чём говорит профессор Шалыто =)
Он рассказывает о построении логики программ на основе стейт-машин / конечных автоматов (или об «автоматной парадигме программирования», если в терминах профессора). Стейт-машины — полезный инструмент, который Android-разработчики давно взяли на вооружение. Мы в hh практически каждую фичу описываем именно с их помощью.
Но писать абсолютно на каждый чих стейт-машины — это, во-первых, лишнее усложнение программ, во-вторых — не всегда возможно. Вот перед вами задача: в зависимости от объекта, пришедшего от сервера, покрасить кнопку в зелёный или синий цвет. Здесь стейт-машина не нужна, тут нужен простой boolean-флаг.
По сути, о таких простых флагах и идёт речь в статье.
Иногда флаги появляются и для описания переходов внутри стейт-машин, кстати. Немного странно делать 2 стейт-машины в этом случае, гораздо проще описать дополнительный if для одного перехода.
P.S. Лично мне показалось, что структура тех стейт-машин (автоматов), о которых рассказывает профессор, недостаточно гибкая. В частности, не увидел в структуре способе отдать единичное событие из машины наружу. А такое иногда требуется — например, показать снекбар при переходе в состояние ошибки. Каким-то полем внутри State-а это делать неудобно.
2) «Надо не собирать, надо не разбрасывать.»
Недостаточно понятная для зумера сентенция =) Уточните, что имеете в виду, как именно надо было «не разбрасывать»?
Вот есть проблема: если «не разбрасывать» и помещать код в один-единственный файл (неважно, в виде enum-а, в виде отдельных функций или ещё как-нибудь) — появятся merge-конфликты, от которых мы хотели уйти.
Если размещать в разных файлах (то бишь, «разбрасывать»), merge-конфликты уходят, но надо будет собирать всё обратно в единый список.
Хочется увидеть конкретное решение, которое вы предлагаете, реализацию в коде. Необязательно на Java, но тогда есть шанс, что вы используете какую-то специфичную для определённого языка конструкцию, которой просто не существует для Android-разработки.