🇨🇳 Приложения в Китае. Вывод

Вроде очевидная мысль, но я сам про неё регулярно забываю:

UI и UX — не универсальны.

Они сильно зависят от аудитории, языка и рынка. Где-то пользователи ждут мгновенного отклика приложения. Где-то важна эксклюзивность контента. А где-то важнее акции, или плотность информации.
Например, в китайских приложениях тебя закидают офферами ещё до того, как ты успеешь заказать такси.

И если делать продукт для другой страны, это нужно учитывать не на уровне “перевели текст”, а на уровне всей структуры приложения.

⚔️ Spec Kit vs Superpowers

Сравниваем два плагина, улучшающих Coding Assistants. Я пробовал с Claude и Copilot, в обоих использовал модель Claude Sonnet.

SpecKit реализует Spec-driven development. Этот инструмент от Github на основе AI агентов имеет набор скиллов, утилит, определённую философию разработки. Требует от разработчика соблюдения четкого процесса для достижения результата.

Superpowers — набор инструментов и скиллов. Фактически, это готовый флоу разработки, но, в отличие от SpecKit, не требует знания флоу, а сам ведёт тебя по нему.

Для обоих инструментов намеренно использовал промпт среднего качества — без сильных деталей, но больше нескольких слов. Давал ссылки на макеты, был подключен Figma MCP, верхнеуровнево описывал флоу или фичу.

Что получилось — читай дальше 👇

Superpowers

С Superpowers сделал несколько фич подряд. В том числе с нуля с использованием CameraX для сканирования QR кода. Всего было 3 фичи, по 3-5 экранов каждая.

Superpowers завёлся быстро, ничего дополнительно настраивать не пришлось.

Плагин сильно улучшил планирование — режим планирования в Copilot или Claude теперь нужен очень редко. Задаёт хорошие вопросы, оставляет хороший файл с планом, сам параллелит выполнение, сам ревьюит свои изменения.

Дизайн из Figma тоже перенёс хорошо. Использовал UI Kit, вся вёрстка — близко к макетам.

Лимиты чуть выросли, но в разумных пределах.

Очень доволен.

Spec Kit

Со Spec Kit попробовал сделать одну фичу — экран с множеством состояний. 

Настройка занимает время. Первый шаг — "конституция", уже вызывает вопросы. Уже есть CLAUDE.md. Чем будет отличаться конституция? Ответ найти оказалось непросто. Настроил по чуйке и обсуждениям

Spec Kit сгенерировал мусорную спеку, не задав ни одного вопроса. А я надеялся, что он сам выяснит нужное в диалоге.

Окей, пробуем еще раз. Дал более подробный промпт, приложил ссылки — снова ничего не спросил, спека стала чуть лучше.

Уточнил моменты вручную, попросил спланировать и разбить на задачи. Он всё сделал, хоть и медленно.

По итогу задачу выполнил плохо: поменял не все нужные файлы, дизайн очень кривой. Настолько кривой, что были проигнорированы все рекомендации CLAUDE.md по использованию Material темы и нашего UI Kit

А еще он съел все лимиты личного Claude 💀

Уже после пошел искать информацию, и наткнулся на обсуждение SpecKit creates the illusion of work, generating a bunch of text. Очень попало в мои впечатления.

Итог битвы — для меня Superpowers оказался проще в использовании, и при этом я получил лучший результат.

Инструменты решают одну задачу. Но Spec Kit не сделал ничего такого, что не сделал бы чистый Claude или Copilot с нормальным промптом.

А Superpowers — топ.

Теперь не могу развидеть тут свинку в очках

Preview Wrappers

В Compose 1.11 добавили Preview Wrappers

Раньше, если хотел показать компонент с темой в превью — писал обёртку руками каждый раз. Мелочь, но это быстро превращается в шаблонный мусор.

Теперь можно сделать один раз:

class ThemeWrapper : PreviewWrapperProvider {
    @Composable
    override fun Wrap(content: @Composable (() -> Unit)) {
        YourAppTheme { content() }
    }
}

И применять через аннотацию:

@PreviewWrapper(ThemeWrapper::class)
@Preview
@Composable
private fun ButtonPreview() {
    Button(onClick = {}) { Text("Demo") }
}

Работает с @Preview и Multi Preview

Кстати, в официальном блоге Google интерфейс и аннотация перепутаны местами — там PreviewWrapper как интерфейс и @PreviewWrapperProvider как аннотация. Судя по реальному API — всё наоборот.

Но есть нюанс, о нём — дальше 👇

Продолжение про Preview Wrappers в Compose 1.11

Фича удобная, но сразу возник вопрос: а что если тем несколько? У нас в проекте именно так

Допустим, есть две темы или больше. Хочется одной аннотацией получить превью сразу во всех. Но @PreviewWrapper сейчас не повторяемый — повесить его дважды не выйдет. И на аннотационные классы тоже не повесишь, то есть нормальный MultiPreview с враппером не сделаешь.

Решил завести issue с предложением это исправить. Чтобы можно было бы написать вот так:

@Preview
@PreviewWrapper(ThemeOneWrapper::class)
@PreviewWrapper(ThemeTwoWrapper::class)
annotation class MultiThemePreview

@MultiThemePreview
@Composable
private fun MyContent() {
    Text("Content")
}

Одна аннотация — превью сразу во всех темах.

Если тема актуальна — ставьте плюсики на issue: https://issuetracker.google.com/issues/505643423

Делитесь, у кого есть интересные кейсы использования Preview?

Jazari One

Запустились в UK в июле 2025. Прошло меньше года — и мы уже делаем второе приложение. Глобальное. На стейблкоинах. 🚀

Казалось бы, повод гордиться.

Но первое, что сделал новый продукт — это вежливо предъявил нам всё, на что мы закрывали глаза в первом.

Модуляризация, которая "не нужна в стартапе". Дизайн-система, которая "не нужна на старте". Инверсия зависимостей, которую "и так понятно где". Архитектурные решения с пометкой "пока сойдёт" — они никуда не делись, просто ждали момента.

Jazari One — часть 2

И вот момент настал. Весь долг пришлось отдавать, потому что иначе поддерживать два приложения очень дорого.

Кто занимается проектированием, знает, что идеальной архитектуры не существует. Каждое решение — это компромисс между требованиями продукта, планами на рост и тем, сколько у тебя людей и времени на обсуждения. Ошибаться в деталях нормально. Страшнее ошибиться в направлении — тогда переделывать придётся не решение, а всё вокруг него.

Стартап — это не про то, чтобы делать плохо. Это про то, чтобы делать быстро. Разница кажется очевидной, пока не начинаешь второй продукт на той же кодовой базе.

🙋🏻‍♂️ Если интересно про андроид часть — напишите в комментариях. Расскажу, какую работу пришлось проделать, какие варианты рассматривали и как в итоге сделали.

Jetpack Compose: весь changelog в одном месте

Новый Compose выходит 1-2 раза в месяц. И каждый раз обновление превращается в квест. Мне. Надоело.

Приходится вручную:

1. Идти на BOM to library version mapping, смотреть какие библиотеки поменялись
2. Для КАЖДОЙ из них открывать changelog на отдельной странице — и ещё помнить, какая версия была до этого
3. Отдельно искать What's new in the Jetpack Compose — полезно, но не очевидно где найти

Обновляешь сразу на две версии — всё это x2.

👉 Короче, собрал сайт со всеми изменениями. Лично кайфанул от того, что похоже на developer.android.com, при этом всё видно сразу

Плюс сделал AI-friendly: есть llms.txt, чтобы агентам было проще разбирать изменения и помогать с апгрейдами

Пригодится всем, кто регулярно обновляет Compose. Ну и агентам скармливать удобно — пусть сами разбираются с апгрейдами.

⭐️ Если пригодится — звёздочка на GitHub и репост приветствуются. Чем больше людей узнает, тем быстрее убедим Google выпустить свою версию.

Завёл issue, чтобы Compose BoM Changelog сделали частью официальной документации.

Если рассматривал картинку дольше секунды — с тебя плюсик под issue ➕

Jazari — UK-банкинг — запущено, стабильно работает у пользователей уже почти год. Мы решили, что хотим сделать еще приложение на стейблкоины — другая аудитория, другая регуляция, другой продукт.

Как оно будет выглядеть — не знает никто. Экспертизы по стейблкоинам в команде почти нет. Всё обсуждается по ходу и может поменяться к следующему утру. Спросить некого: мы сами и рождаем это приложение прямо сейчас.

О завершённых проектах обычно рассказывают итог: «сделали вот так, всё работает». Трейдофы — что отбросили, почему, что пошло не туда — остаются за кадром.

Я хочу рассказать именно это. В основном про Android приложение. И ещё — где во всём этом помог AI, а где нет.

Первый пост — завтра ⏳

Кажется, получится долгий рассказ, поэтому буду помечать посты:

серия → «Два приложения — один логин»

#android #kotlin #androiddev #архитектура

🪨 Монолит

Первый трейдоф появился задолго до того, как появился второй проект.

Когда делали Jazari Money, был вопрос — модуляризировать или нет. Модуляризация требует времени и на подготовку, и на поддержку. Поэтому все фичи делались в одном модуле. В условиях стартапа выбор был сделан в пользу скорости.

Так вырос один :app модуль — 600+ Kotlin-файлов, куча ресурсов, различные тесты. Логин и регистрация жили прямо внутри: app/feature/login/, app/feature/registration/. Минимум отдельных модулей.

Итак, дано: работающая куча кода 💁🏻

Задача: нужно сделать два разных (но частично похожих) приложения — и не сломать существующее 📝

Обычно к такой задаче не знаешь как подступиться. Было именно такое ощущение. И одновременно — воодушевление: казалось, что жизнь готовила меня именно к таким задачам.

Подход к проекту был последовательным: сначала подготовить почву, потом строить. Больше 100 коммитов — модуляризация монолита. В результате :app стал :app:jazari-money, логин и регистрация переехали в отдельные feature-модули, UIKit и утилиты — в core. И только поверх этой готовой структуры, тремя последними коммитами, появился :app:jazari-global.

Но прежде чем двигаться, пришлось принять несколько решений. О них — в следующих постах.

→ серия «Два приложения — один логин»

#android #kotlin #androiddev #архитектура

Почему мы не стали делить feature на api и impl

Часть фич нужно переиспользовать, а значит пришло время разделить монолит. Как организовать feature-модули? Есть два основных подхода.

1️⃣ Подход 1: api + impl. Каждая фича делится на два модуля. Фичи могут зависеть друг от друга через :api.

Этот подход активно используется в крупных компаниях. Например, именно так мы делали в Кинопоиске. Вот еще пара статей, где компании рассказывают о таком подходе:
Альфа-раз, Альфа-два
Касперский раз, Касперский два

Плюсы:
• легче изучать код — очевидно откуда куда навигируемся
• наличие api модуля позволяет четко разграничить ответственность между командами — поэтому подход используют во многих крупных компаниях

Минусы:
• фичи связаны между собой, пусть даже через контракт
• модулей вдвое больше — увеличивается время сборки, появляется бойлерплейт

2️⃣ Подход 2: один модуль на фичу. Фичи не могут зависеть друг от друга.

Плюсы:
• чёткая зона ответственности фичи
• фичи полностью независимы

Минусы:
• интеграцию нужно явно прописывать в app модуле. Это чуть усложняет изучение поведения фичи в готовом приложении.

Такой подход описывает в своей документации Google

*️⃣ Есть и другие подходы (например, api + internal в Яндекс картах)

👉 api + impl — монументальная структура: много модулей, фичи знают друг о друге. Она хороша для устоявшегося приложения с большой командой, но для компактного стартапа — избыточна. Выбрали подход 2️⃣, один модуль на фичу

И ещё один аргумент за подход 2: один фича-модуль не отрезает путь к api + impl в будущем. Обратный переход — сложнее, потому что больше кросс-зависимостей. Поэтому пока что — YAGNI

Про то, как интеграция фич выглядит на практике — дальше.

→ серия «Два приложения — один логин»

#android #kotlin #androiddev #архитектура

AI не создал новые проблемы в разработке. Он сделал видимыми старые.

Конец недели — пора расслабиться. Следующий пост про трейдофы при модуляризации будет на следующей неделе, а пока поделюсь очень интересным, на мой взгляд, видео.

Adam Bender (Google) в докладе на I/O 2026 вводит понятие «software ecology» —
программный продукт неотделим от организации, которая его строит.
Закон Конвея в действии: не только архитектура системы,
но и код-ревью, постмортемы, деплой — всё отражает ценности компании.

AI убрал узкое место там, где его почти не было — в написании кода.

Раньше инженер часами писал код. Теперь за секунды. Но дальше — стена:
— Ревью кода, который никто не писал руками
— Интеграционные тесты, которых нет или они недостаточно хорошие
— «Conjunction of Booleans»: чтобы выпустить билд, все тесты должны быть зелёными. Но что делать, если тестов миллион? Всё-или-ничего стратегия больше не работает

Узкое место сместилось. Теперь оно — верификация и деплой.

Bender называет это «capacity crunch за пределами написания кода».
Производить код легко. Убедиться, что он работает — нет.

Это меняет не инструменты. Это меняет то, во что нужно инвестировать команде.

Еще интересно то, что Адам НЕ сказал. В основном он упоминает технические вещи: деплой, пропускная способность сети, сколько коммитов в минуту может выдержать VCS. Это точно будет узким местом, но я верю, что AI поможет справится с этим

Гораздо менее понятно — что делать с узким местом в виде людей, которые должны поставлять AI прожаренные фичи с более-менее понятными требованиями. Кажется, что AI должен будет стать полноправным членом команды на всех этапах процесса: участвовать во встречах, анализировать данные рынка, составлять бэклог и приоритизировать его вместе с командой. Вот это действительно дало бы огромный буст

❓Хотели бы видеть AI членом своей команды?

#AI #googleio

Convention Plugins

Итак, будет больше одного фича модуля, а значит собираться они будут похожим образом. Нужно избежать бойлерплейта. И вот как сейчас выглядит build.gradle.kts любого feature-модуля в проекте:

plugins {
    alias(libs.plugins.jazari.feature)
}

android {
    namespace = "money.jazari.feature.login"
}

В отдельных модулях бывают дополнительные зависимости. Но всё же — несколько строк, вместо ~50 с compileSdk, версией Java, Compose BOM, всеми зависимостями Hilt, KSP, desugaring и прочим. Это convention plugins.

Бывают в виде kts скриптов или в виде kotlin/java файлов. Без них — копипаст в каждом модуле. Один раз забыл обновить compileSdk в одном месте — и привет.

Получилась иерархия, как на скриншоте. FeaturePlugin — это буквально:

class FeaturePlugin : BaseProjectPlugin() {
    override fun apply(target: Project) {
        AndroidLibraryPlugin().apply(target)
        HiltPlugin().apply(target)
        ComposePlugin().apply(target)
    }
}

Все модули получают нужную конфигурацию за одну строку.

Вот немного полезных материалов по теме, от Т-Банка:
Статья раз, Статья два

Кстати, написание самих плагинов — хороший пример задачи для AI: есть образец в виде build.gradle.kts, нужно отрефакторить, чтобы собиралось также. Особенно помогает, когда есть gradle апи, перенос которых в плагин не самый очевидный. Тут AI справился без вопросов и без помощи извне

→ серия «Два приложения — один логин»

#android #kotlin #androiddev #архитектура

Нужно ли выносить внешние зависимости в отдельные модули?

Многие архитектурные паттерны рекомендуют это делать. На практике — зависит.

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

Например, Android SDK — тоже внешняя зависимость для нашего кода. Но мы же не изолируем всё подряд без необходимости.

У нас таких случаев нашлось два: пуши и саппорт. Оба — внешние SDK, которые могут меняться или подключаться по-разному в разных приложениях.

С саппортом получился показательный кейс. Параллельно с модуляризацией мы переезжали с Intercom на HelpCrunch. Каждый SDK был вынесен в отдельный модуль, поэтому оба работали одновременно, а переключение было возможно прямо на проде — без страха что что-то сломается.

Когда миграция завершилась, удаление Intercom выглядело как удаление одной строки из build.gradle.kts.

Все остальные внешние зависимости оставили как есть. Изолировать всё подряд ради соблюдения паттернов кажется избыточным.

→ серия «Два приложения — один логин»
#android #kotlin #androiddev #архитектура