Берёзка

Уже послезавтра расскажу как мы ускорили CI в Додо Пицце замедлив тачки. Успевайте зарегаться!

Берёзка pinned «Хочу вам помочь Я в разработке около 15 лет. Последние 7+ лет в Додо делаю так, чтобы приложение стабильно работало на всех рынках. В основном шарю за iOS и мобильную инфру. Ещё могу помочь с доступностью: Dynamic Type, контрастными темами, адаптацией для…»

Bookshelf.dev: новая книга — про автотесты на iOS Сейчас у тестов вторая жизнь: • ИИ может легко написать любой тест; • ему критически важны тесты, чтобы проверять результат работы; • при этом разработчикам нужно как-то быстро понимать что в проекте вообще есть; • но если вы не знаете каким тестом проверить задачу, то ИИ за вас это не придумает; • вы все еще должны сделать тестируемую архитектуру, чтобы код вообще можно было протестировать! Выходит, что 4 из 5 пунктов я могу показать: как это выглядит, куда идти и как пользоваться. А вот последний пункт про архитектуру вы должны пройти сами, выбрав что вам нужно, что можно сделать сейчас и насколько вы готовы менять проект. Зато после книги конечная цель будет сильно понятней! Книга будет выходить постепенно, первые шесть глав уже доступны. • Как тесты помогают масштабированию приложения. • Примеры тестов в пирамиде тестирования. Бесплатная глава • Как тесты и ИИ помогают друг-другу. • Что приходится изменить в архитектуре. • Что такое TDD-ката и туториал по ней. • Что такое DSL Затем я расскажу про самые разные виды тестов (примеры в бесплатной главе) и к концу вы узнаете как написать стройную систему автотестирования без мок-фреймворка на сценариях использования приложения. Доступно на русском и английском, $30 вместо 50 пока книга пишется. https://bookshelf.dev/testing-book

Миша — гуру в тестах. Как бы хорошо вы не писали тесты — прочитайте книгу и научитесь новому. А если ещё не писали тесты — ну, пора уже, это лучшее вложение в техническое качество проекта, особенно с учетом всего этого ЛЛМ-бума.

Хочу вам помочь Я в разработке около 15 лет. Последние 7+ лет в Додо делаю так, чтобы приложение стабильно работало на всех рынках. В основном шарю за iOS и мобильную инфру. Ещё могу помочь с доступностью: Dynamic Type, контрастными темами, адаптацией для дальтоников. Ну и с процессами в команде. Много че повидал и поменял, знаю, что работает, что не работает и почему. Короче, запускаю платные консультации. Можно прийти, например, если: • не понимаете, как подступиться к мобильной инфре • приложение нестабильно, а куда копать - непонятно • хотите разобраться с доступностью • в команде что-то не работает, но че именно - хрен поймёшь Консультация стоит 10 000 ₽ за час. Для первых клиентов сделаю за 5000 ₽. Взамен попрошу честный отзыв, который смогу разместить у себя на сайте. С вас - проблема и контекст. С меня - разбор, че происходит и что с этим делать. Пишите в личку.

Долистали до главного релиза августа — iOS-митапа от hh.ru 🛠 Наши эксперты и специалисты Dodo Engineering представят четыре доклада об инфраструктуре, CI, мобильной аналитике и архитектуре. Ждём iOS-разработчиков и техлидов, которые развивают крупные приложения и хотят ускорить рабочие процессы! 🛠 iOS-разработчик hh.ru Виталий Барабанов расскажет, как устроена iOS-инфраструктура hh.ru и какой путь проходит приложение от коммита до релиза. Обсудим CI/CD, сборочные машины, авторелиз, кодогенерация аналитики и сокращение ручных операций 🛠 iOS-техлид Dodo Engineering Алексей Березка рассмотрит, как находить узкие места в CI и ускорять сборки. Поговорим об интеграции OpenTelemetry с GitHub для мониторинга очередей, прогонов и статусов, а также поиска узких мест. Практические способы ускорить парсинг тестов, распараллелить джобы и оптимизировать сборку с помощью кэшей 🛠 iOS-разработчик hh.ru Андрей Максимкин разберёт перезагрузку мобильной аналитики и объединение подходов iOS и Android. Проанализируем переход к единому масштабируемому подходу в мобильной аналитике для iOS и Android, а также организацию совместной работы команд, результаты внедрения и применение AI 🛠 iOS-разработчик hh.ru Тимур Шафигуллин поделится какой получилась MVVM на проекте из 17 тысяч Swift-файлов и 164 модулей. Разберём причины отказа от чистого SwiftUI, объединения бизнес- и UI-состояния и создания собственных опенсорс-библиотек, а также альтернативы и решения возникших проблем. 📆Когда: 20 августа в 18:30, начало в 18:30. У ✌️Участие: бесплатно, онлайн Регистрируйся тут

Скоро выступлю и расскажу как сделать вашу инфру быстрой. Запишитесь, придите и послушайте. ТАКОГО ВЫ ЕЩЁ НЕ СЛЫШАЛИ.

А ещё мы снова ищем iOS-разработчика! На этот раз в команду лояльности — додокоины, персональные скидки и всё такое. Успевайте откликнуться, пока никто не занял это золотое место — проекты там и правда клёвые. https://dodoteam.ru/vacancy/?vacancyId=15043

Берёзка pinned a photo

Новый публичный технический дашборд Додо Пиццы Старый дашборд работал сомнительно из-за технических ограничений, да и выглядел плохо. Хотя и решал свою задачу. Но хочется же чтобы было красиво. Поэтому я поднатужился и выдал новый дашборд взамен старого. Заодно и метрик добавил — и версии языка, и варнинги, и разбивка по диприкейтам. Короч стало вау, зацените: 💅дашик 💅

LLM-фабрика, часть 6: ишьюс сам пишет себе план В прошлой части триаж разложил живой бэклог по лейблам. Если прямо ща нужен человек — ставил awaiting-answer, задавал конкретный вопрос и вставал ждать. Ответили на вопросы — пора планировать. Ишьюс получает planning. Каждую ночь LLM Plan берёт три такие задачи — те, которых дольше всего никто не касался. Читает описание и весь тред, связанную таску из тасктрекера, её эпик и доку из базы знаний, правила проекта и сам код. И ничего в коде не меняет. Не потому что мы попросили — у него просто нет доступа на запись. Только чтение, поиск и коммент в ишьюсе. На этом этапе фабрика разбирается: • каким из способов делать и чем за это платим • в каком модуле ваще должна жить правка • что уже есть и можно переиспользовать • чем это потом проверить • где можно случайно сломать соседнее После ресёрча бот кладёт план прямо в комменты ишьюса: контекст, выбранный подход, шаги, конкретные файлы, тесты, риски и крайние случаи. Не «поправить сервис и добавить тесты», а какие именно файлы, че в них менять и какой результат проверять. Главное: план можно перехватить руками. Ради этого отдельный этап и появился. План лежит в ишьюсе обычным текстом до того, как написана хоть строчка кода — и любой из команды может прийти и сказать «не, так не надо». Такой коммент сразу тормозит задачу, дальше по конвейеру она не уедет, а следующей ночью бот перечитает тред и пересоберёт план с учётом сказанного. Спорить с планом в комментах сильно дешевле, чем на ревью гига-ПРа. Перед тем как запостить, бот прогоняет свой же план через нашу доку — те самые страницы из первой части. Нашёл в плане нарушение — переписывает план. Не уверен, что правило тут применимо — выносит это человеку отдельным вопросом. Тихо разойтись с докой план не может. Если по дороге нашлась развилка, которую из кода не решить — возвращаемся в awaiting-answer из прошлой части. Фабрика задаёт вопрос и ждёт. Сюда же попадает и «делаем одним ПРом или разбиваем на три» — из кода это не выводится, это решает человек. Если вопросов нет — в конце плана бот ставит маркер: всё исследовано, можно двигаться дальше. Причём поверить одному маркеру недостаточно. Отдельный тупой скрипт проверяет, что в комменте реально есть план и список файлов, что после него никто не задал новый вопрос, что рядом не открыт ПР по этой же задаче и что awaiting-answer уже снят. Никакой ЛЛМ в этом месте не участвует — тут нечего решать, тут всё проверяется строкой и лейблом. И только тогда planning заканчивается. Какой лейбл приходит следующим — в следующей части. Жмите 👀 если продолжать.

LLM-фабрика, часть 5: бэклог разбирает сам себя В прошлой части фабрика прошлась по старым ишьюсам и выкинула те, которые делать уже и не надо. Остался живой бэклог — можно брать и пилить. Но тупо отдать ЛЛМ первый попавшийся ишьюс тож нельзя. В одном написано «переименовать опечатку» — там всё понятно и работы на десять строк. В другом «переделать авторизацию» — че именно переделать, зачем, какой из пяти вариантов выбрать и кто ваще решает как правильно? Если оба сразу отправить писать код, первый превратится в нормальный ПР, а второй — в уверенно написанный абсолютно неверно ПР. Поэтому следующий кирпичик фабрики — LLM Triage. Каждую ночь он берёт три самых старых ишьюса без решения и читает всё, что про них есть: описание, комменты, связанный таску из тасктрекера, доку из базы знаний и сам код. Если для ишьюса уже открыт ПР, триаж его ваще пропускает. Работа и так идёт, не надо запускать рядом вторую. Остальным ставит один из нескольких лейблов. У каждого дальше свой кусок фабрики, поэтому давайте не пихать всё в один пост. Сегодня только про awaiting-answer. Он появляется, когда прямо ща нужен выбор человека. Фабрика задаёт вопрос прямо в ишьюсе — не абстрактное «а че вы хотите?», а конкретную развилку, на которую можно ответить одной строкой: переименовать старое API или оставить совместимость, делать через вариант А или вариант Б. Заодно тегает автора ишьюса и тех, на кого оно назначено. И всё, фабрика встаёт и ждёт. Не начинает писать код наугад, не выбирает сама и не долбит человека одинаковым вопросом каждую ночь. Пока нового ответа нет — молчит. Когда человек отвечает, фабрика не просыпается мгновенно. Следующей ночью LLM Plan снова приходит в ишьюс, перечитывает весь тред, берёт последний ответ и пересобирает план с учётом него. Если из ответа вырос ещё один вопрос — оставляет awaiting-answer и спрашивает дальше. Если всё понятно — снимает лейбл, публикует обновлённый план и ставит маркер «вопросов больше нет, можно двигаться дальше». То есть awaiting-answer — не метка «мы запутались и сдались». Это прям состояние фабрики: вот конкретный вопрос, вот кого ждём, вот с какого места продолжим после ответа. А что делают остальные лейблы — уже в следующих частях. Про planning там прям отдельный кусок фабрики, а до написания кода ещё доберёмся. Наваливайте 🤔 если продолжать.

Пандус для Фигмы Сделал плагин который позволяет легко описать разметку для VoiceOver в Фигме. О таком инструменте меня спрашивали десятки компаний, так что забирайте. https://www.figma.com/community/plugin/1658465990761157788/voiceover-annotator Главное: он задает формат описания элементов и показывает ограничения, которые есть у скринридера. Но это цветочки: если подключить API-ключ для нейронки, то с помощью скила можно сгенерировать все описание! А мелочи потом руками доправить. Главные фичи: • Повторяет интерфейс приложения VoiceOver Designer. Если пользовались, то будете как дома. • Умеет подписывать как под фреймом, так и в аннотациях для Dev Mode. • Можно экпортнуть в формате .vodesign и послушать превью в VoiceOver Designer Плагин опенсорсный, пишите баги в ишьюс https://github.com/AccessibilityTools/voiceover-annotator-for-figma С плагином и дизайном мне помог Матвей Мясоедов. Матвей, спасибо!

Мишаня дропнул бомбу. Показывайте дизайнерам и улучшайте доступность ваших приложений.

Ищем QA Fullstack Engineer в команду меню 🍕 Открыли вакансию в юнит App&Web в команду, которая отвечает за меню. Это весь путь от сторис и баннеров до выбора товара, кастомизации и корзины. Зона, где любое изменение сразу отражается на количестве заказов и среднем чеке. Пара вещей, которые стоит знать до перехода по ссылке: QA в команде будет один. Это значит полную автономию: сам решаешь, что и как тестировать, сам держишь качество. Никакого согласования каждого шага, но и ответственность целиком на тебе. Тестировать придётся преимущественно мобилку, изредка бэкенд. Плюс покрывать свои кейсы автотестами сразу на обеих мобильных платформах: Swift + XCTest и Kotlin + Kaspresso. С автоматизацией у нас хорошо: - 734 UI-теста на iOS - 781 на Android - 92% регресса под автотестами - есть отдельная core-команда автоматизации, которая помогает развиваться и делает крутые штуки для упрощения тестирования (клиент-генератор, бот в Mattermost и т.д.) Помимо продуктовых задач есть мобильная гильдия — 5 человек. Каждый квартал ставим цель по улучшению процессов в мобильном тестировании, и в этом участвует каждый. С полным описанием можно ознакомиться по гиперссылке в заголовке поста

LLM-фабрика, часть 4: сначала разберёмся со старыми ишьюсами В прошлой части фабрика сама подкидывала новые ишьюсы в бэклог. Ишьюсы появились, копятся — красота. Конечно же никто их не решает. Ну а кому ваще придёт в голову пойти разгребать старый бэклог, когда рядом лежат фичи, которые надо пилить прям ща. Так у нас накопилась уже сотня открытых ишьюсов. Часть всё ещё ждёт своего часа, часть мб давно починилась другими ПРами, а часть описывает код, которого уже нет — всё таки проект быстро меняется, особенно когда у всех есть доступ к ЛЛМ. И вот тут приходит следующий кирпичик фабрики — LLM Stale Issues. Каждую ночь он берёт самые давно неактивные ишьюсы и проверяет, актуальны ли они ещё: • читает ишью, где не было активности 30 дней и все их комменты • проверяет связанные ПРы — не починил ли кто-то проблему по дороге • идёт в текущий код и смотрит, существует ли ваще то место, про которое написано • ищет дубли среди других открытых ишьюсов Важно: старое не значит неактуальное. Возраст сам по себе не причина что-то закрывать. Боту нужен конкретный пруф: влитый ПР, решившый проблему, отсутствие упомянутого кода или это дубль другого ишьюса. Если пруф есть — бот пишет короткую причину и закрывает ишьюс. Если нет — оставляет коммент, почему задача всё ещё актуальна, и не трогает её ещё 30 дней. Если для ишьюса прямо ща открыт ПР — ваще пропускает, там работа уже идёт. Получается немного наоборот: прежде чем научить фабрику брать задачи в работу, сначала пришлось научить её выкидывать те, которые делать уже и не надо. В следующей части пойдём дальше — как из живого бэклога фабрика сама выбирает, что можно брать в работу. Ставьте 🌭 если продолжать.

Додо Пицца переехала на Swift 6 и Strict Concurrency Начали переезжать в октябре 2024, закончили в июле 2026. Теперь все внутренние либы, все модули и основной монолит по-честному* потокобезопасны. Ваши вопросы?

💥 Агентская фабрика на CI: автоматизируем весь цикл разработки Лёша Берёзка, техлид iOS в "Додо Пицце" и автор канала о разработке, покажет онлайн, как построить «фабрику» агентов в CI‑пайплайне — систему, которая самостоятельно закрывает полный цикл от создания issue до влития Pull Request. ➡️ Разберём, как организовать оркестрацию нескольких агентов и обеспечить их согласованную работу. ➡️ Посмотрим, как фабрика автоматически заводит issue, сама их планирует, уточняет детали, реализует и доводит Pull Request до успешного слияния. ➡️ Разберём типовые проблемы и способы их решения. Когда? Завтра, 15 июля, в 13:00. Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы Лёше!

Я вот вам про фабрику рассказываю раз по частям, а тут ребятам сразу всё вывалю. Если не хотите ждать недели пока я всё расскажу в канале — приходите посмотреть на меня в лайве. Обнял.

LLM-фабрика, часть 3: ишьюсы появляются сами В первых частях был бот-ревьюер: сам разбирает PR и оставляет комменты в тредах. Я уже два поста обещал показать команду, которая по этим тредам потом сама бегает. Вот она. Команда /pr:resolve-comments. Лежит в нашем приватном плагине llm-toolkit, ставится в Claude Code, Cursor и Copilot CLI. Как работает: открываешь PR, на нём висят ревью-треды, клод бежит по каждому — фиксит, отвечает, резолвит. Но эт скучное. А вот теперь интересное. Часть комментов на ревью — валидные, но не в скоупе этого PR. Типа «а ещё вон там бы переименовать», «эта проблема глубже, надо ваще переделать иначе» или «а вот тут баг» — а он с нами уже много лет был, и прям ща мы это место не трогали. Раньше я на такие комменты тупо забивал. Ну то есть отвечал что-то типа «да, согласен, как-нибудь починим», резолвил тред — и всё, тикет нигде не висел, в голове не оседал, через неделю забыт. В скилле же прописано прямо: 1. Create a GitHub issue via `gh issue create`. If the repo has a task issue template, use its structure. 2. Reply in the thread: explain that it's out of scope, attach the link to the created issue. 3. Resolve the thread. Клод сам распознаёт что коммент не в скоупе, идёт в шаблон ишьюса в репе, заполняет всё по нему, линкует обратно на тред, отвечает в треде «не в скоупе, завёл #NNN», резолвит. Дальше работает фоном. Целый день пилишь свои PR'ы, на каждый прилетает ревью от ллм-ревьюера, ты гоняешь по этим тредам ту же команду — и к вечеру в репе сама собой появилась пачка новых ишьюсов. Я их руками не заводил, они выросли из моих же ревью-комментов. Вот это и входная точка фабрики. Пока ещё не «LLM пишет код», но «LLM сам подкидывает работу в бэклог». Дальше будет больше: следующие части про то, как эти ишьюсы потом сами и закрываются. Бахайте ✍️ если хотите продолжения.