Меня зовут Павел Коростин, я техлид тестирования мобильного банка для юридических лиц в Альфа-Банке. Бэкенд мобильного банка — это около 300 микросервисов, работающих в k8s, развитием которых занимаются примерно 50 команд, разделённых на функциональные области. За каждой командой закреплены сервисы, которые они поддерживают, разрабатывают, тестируют и, соответственно, пишут автотесты. Раньше все тесты на сервисы «жили» в одном монорепозитории, но в определённый момент мы поняли, что дальше так работать уже не можем и нужно как-то разъезжаться.

Не буду вдаваться в подробности, почему гигантский монорепозиторий неудобен, потому что, если вы уже решили избавляться от громоздкого монолита, то основной вопрос — как дробить?

Привет на связи Федотов Михаил и Абдульманов Эдуард, мы технические лидеры Android разработки в Альфа-Банке и занимаемся приложением для физических лиц.

В этой статье вспомним наш опыт разбиения большого монолитного android приложения на мини-приложения срезки, занимались мы этим уже довольно давно, но тема все равно актуальная.

Переход к таким мини-приложениям позволяет ускорить конфигурацию Gradle и уменьшить время компиляции проекта как локально так и на CI.

Думаю это будет полезно тем кто интересуется архитектурой android приложений, KSP, Dagger, а также тем у кого крупное многомодульное приложение и есть проблемы с производительностью работы Gradle в проекте.

Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке.

Когда-то давно мне приходилось работать над стартапом, цель которого была — форкнуть основной клиент приложения Telegram и доработать его, а именно добавить в него ИИ-чат-ботов, с которыми можно было общаться. Но это было в далёкие времена, когда ИИ ещё не был на таком «хайпе», как сейчас.

Боль каждого лида — это ответы на сообщения в чатах, и вот недавно я задумался: а что, если спасти себя и заодно опробовать ИИ? Попробовать добавить в Telegram функциональность генерации ответа на сообщение и сделать это без глубокого погружения в исходный код, просто как продакт, который просит своего разработчика что-то для него сделать. Для этих целей я выбрал инструмент — Cursor, с которым общался в визуальном редакторе. Давайте посмотрим, получилось у меня или нет!

История — мастер игнора. Под катом три самых интригующих для меня вопроса, на которые она упорно отказывается отвечать.

В мире разработки программного обеспечения существует понятие, которое окружено множеством мифов, страхов и недопонимания. 

Это технический долг. 

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

Мы часто проектируем «правильно»: используем проверенные подходы, следуем best practices, применяем паттерны. Но результат всё равно может оказаться далеким от ожидаемого. Архитектура выглядит логичной, решения — обоснованными, а в реальности система становится сложнее, дороже и больнее в сопровождении.

Почему так происходит? Разберём паттерны это на реальном кейсе миграции с Legacy-системы — и посмотрим, где заканчивается сила паттернов и начинается суровая реальность.

Краткое содержание статьи:

— Как проектировать правильно?
— К чему может провести правильное проектирование на примере истории миграции
— Почему получилось что-то «неправильное»?
— Выводы.

В 2022 году мы приняли решение объединить множество показателей, связанных с разработкой, в интегральную метрику Contribution. Данной метрикой мы диагностируем Code review и считаем вклад разработчика в продукт.

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

Сейчас расскажу, зачем это нужно и как мы пришли к этой метрике.

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

Всем привет! Меня зовут Николай Луняка. В прошлой статье мы строили локальную систему для транскрибации аудио, а сегодня пойдём дальше и соберём локальную агентную AI-систему — без облаков и с контролем над данными.

В этой статье я покажу, как собрать связку из трёх ключевых компонентов:

1. LibreChat — UI для работы с LLM

2. Langflow — low-code платформа и визуальный редактор

3. MCP — стандарт для подключения инструментов

Статья построена по принципу «по нарастающей», где каждый новый уровень — это рабочий инструмент. Можно остановиться на любом этапе, а можно пройти все и тогда получите связку UI + инструменты + централизованная логика (и дальше ее можно развивать под свои сценарии).

Что вы представляете, когда кто-то говорит об AI-driven компании? Может быть, как чат-боты улучшают опыт клиентов? Может быть, как сотрудники разворачивают любые модели для своих нужд? А может, как ИИ-агенты разбирают кучу электронных писем и назначают встречи в календаре, копилоты пишут код за разработчиков и исправляют баги?

Красиво.

Но что в этой красивой истории может пойти не так и почему безопасность систем искусственного интеллекта не ограничивается защитой от джейлбрейков и промпт-инъекций, разберёмся в этой статье.

Крошка Макс ко мне пришел,
И спросила кроха:
«Если всё решаю сам —
Это, значит, плохо?»

Макс — это project manager, который живет свою лучшую жизнь. Каждую пятницу после обеда он берет латте на банановом молоке, приходит на 1-1 к своему лиду — ко мне, — и мы разбираем какие-то на первый взгляд типовые кейсы, но смотрим на них с нестандартной стороны.

Цель Макса — повысить эффективность своей команды, чтобы она могла переваривать более сложные проекты, не теряя в скорости и гибкости. При этом не изменяя своего состава, а только за счет личностного роста.

Вызов принят.

Меня зовут Епифанова Наташа, я Lead Project Manager на сайте alfabank.ru, и моя команда — это команда платформы сайта. Хочется рассказать вам о том, как мы с командой пришли к самостоятельности. Под самостоятельностью я понимаю в том числе автономность от менеджеров с сохранением ответственности за свои решения. 

Привет я Федотов Михаил, технический лидер по Android разработке в Альфа-банке. Сегодня хочу поговорить про performance (ускорение) unit тестов.

Я работаю на проекте Android приложения Альфа-банка для физических лиц. Для нашего большого проекта это время — больная тема, так как у нас около 800 модулей и большая часть кода полностью покрыта unit тестами (за некоторыми исключениями, например, view классы). Сейчас у нас почти 6000 spec (тест-классов) в которых 37 000 тест-кейсов.

Общее время прогона всех тестов на CI превышало 3 часа. Локально все тесты прогнать вообще было утопией, так как вероятнее всего сборка просто падала от нехватки оперативной памяти.

Сейчас все тесты проекта мы научились прогонять за честные 12 минут и я расскажу что для этого потребовалось.

Проблему SharedPreferences можно описать несколькими словами: ANR, блокировка перехода между экранами, явное нарушение стрик мода в Android SDK по работе в главном потоке.

В чем проблема с SharedPreferences и решит ли ее Datastore - узнаем в этой статье.

Каждая модель ИИ приносит достаточно дохода, чтобы покрыть расходы на собственные исследования и разработки. Но этот профицит нивелируется затратами на разработку следующей крупной модели. Поэтому, несмотря на прибыль от каждой модели, компания не зарабатывают.

Но это не так страшно. В быстрорастущих технологических секторах инвесторы обычно готовы идти на убытки сегодня в обмен на большую прибыль в будущем. Так что, если модели ИИ уже покрывают свои расходы, это говорит о хороших финансовых перспективах для компаний, занимающихся ИИ.

Или нет?

Я открываю старый проект 2020 года и вижу знакомые имена в package.json: create-react-app, enzyme, moment.js, axios. Пять лет назад это был золотой стандарт. Сегодня же эти технологии вызывают у коллег искреннее недоумение: «Зачем это тут?»

А ведь прошло всего пять лет.

И за эти 5 лет изменилось очень многое: SPA переживает упадок, TypeScript стал обязательным стандартом, роль фронтенд-разработчика расширяется до full-stack. А дальше что, браузеры заменят фреймворки?

Я — системный аналитик. В моей жизни так повелось: чего боюсь, в то и попадаю. В начале своего пути столкнулась с проектом, где работали настоящие архитекторы решений. Глядя на них, я думала: «Они боги! Знают и понимают так много… ВАУ!». Они одновременно и привлекали, и пугали. С ними было легко, потому что они внушали доверие: нет нерешаемых задач, нужно просто подумать. И в то же время объёмно — от глубины их знаний захватывало дух.

Недавно мне раскрыли тайну: архитектор — это не тот, кто знает всё, а тот, кому доверяют построить систему для решения бизнес-задачи. И я поняла, что в начале пути меня привлекали их спокойствие и уверенность. Всё остальное — опыт, знание технологий — это hard skills, которые можно наработать. 

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

Развивать платформенные продукты не просто. С бизнес-продуктами всё более менее понятно: развивать надо то, что приносит деньги. Тут главный вопрос, как узнать, что именно приносит деньги. Это тоже очень не просто, и на эту тему написано десятки статей и даже учебников.

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

Оценка знаний и навыков — это тяжелый вопрос и больная тема. Если хочешь увидеть драку, заходи на любую общую встречу с руководителями и вкидывай вопрос про оценку знаний и навыков сотрудников (желательно анонимно) — холивар между сотрудниками, техлидами и руководителями обеспечен. Можно ли сделать этот процесс менее болезненным, более честным и близким к идеалу? Вопрос на миллион.

Меня зовут Бастина Алина. В Альфа-Банке работаю уже более 5 лет, прошла путь от системного аналитика до руководителя группы разработки инструментов для IT-сотрудников. Один из этих инструментов — сервис ассессмента. 

Что будет в статье? Сначала немного формальностей, а далее погрузимся в тему: как ассессмент связан с (другими) процессами развития сотрудника внутри банка, как оценка навыков проводилась раньше, почему пришлось ее менять и как мы дошли до того, что имеем сейчас.

Меня зовут Артём Дружляков, я техлид QA в направлении кредитования. Сегодня я хочу рассказать о проекте, который мы реализовали в направлении тестирования микросервисов в Альфа-Банке, — о разделении автотестов по микросервисам.

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

Чтобы решить эти проблемы, команда перешла на микросервисный формат. Теперь автотесты на каждый микросервис хранятся в отдельном репозитории, который создаётся автоматически с помощью шаблонизатора и уже содержит все необходимые файлы. Можно использовать генерацию по спецификации OpenAPI, а общие решения вынесены в отдельные библиотеки, покрытые юнит-тестами и подключаемые при необходимости.

Я — системный аналитик. Но долгое время я не применяла системное мышление к себе, я проектировала архитектуры, создавала диаграммы, детализировала процессы и уточняла требования... Но когда речь заходила о моей собственной карьере, я ощущала растерянность. Меня мучил вопрос: «К кому мне подойти, чтобы расти профессионально?»

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