Корпоративный архитектор — это «демон Максвелла», и его задача — бороться со сложностью ИТ-ландшафта. У нас в Банке это добрый демон, оперирующий подходами Just Enough Enterprise Architecture (JEEA) и Lightweight Architecture Governance (LAG). Именно корпоративные ценности и культура в Банке делают демона добрым. Поверьте мне, ведь я один из них.

Привет, Хабр! Меня зовут Дмитрий Клецких. Я Chief Enterprise Architect в Райффайзен Банке. До этого много лет работал корпоративным архитектором в других компаниях: МКБ, СБЕР, Транснефть, Правительстве Москвы. Поговорим об изменениях ИТ-ландшафта, организационных и технологических трансформациях, о роли архитекторов и изменении этой роли с приходом ИИ.

В Райффайзен Банке 14 профессиональных сообществ и 262 Agile-команды. Все эти люди взаимодействуют между собой, создают артефакты и проекты с разной скоростью, качеством и своими решениями. Чтобы все это не превратилось в хаос, в корпорации начали выстраивать инженерные практики — для унификации/стандартизации решений.

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

Привет, Хабр! Вы когда-нибудь тратили слишком много драгоценного времени на поиск нужного testTag в иерархии Compose Screen? А потом ещё полдня чинили тесты после каждого чиха в UI? Или, может быть, несколько недель ждали, пока в дизайн-систему добавят недостающий тег или семантику, чтобы вообще начать писать свой UI-тест? Если вы хоть на один вопрос ответили «Да», эта статья для вас. Давайте навсегда покончим с этой рутиной и займемся более креативными задачами!

Цель статьи — НЕ представить очередной фреймворк написания UI-тестов для приложений на Android, а упростить их написание с помощью всем знакомого Page Object. Мы будем прятать рутину поиска нужных компонентов и одновременно повышать устойчивость тестов к изменениям. Всё для того, чтобы тесты стали удобнее, надёжнее и проще поддерживались.

Меня зовут Дмитрий Омельченко, я Android-разработчик в Райффайзенбанке. Несколько лет назад мы с командой начали внедрять автоматизацию тестирования в приложение online-банка, и за это реализовали несколько интересных решений, об одном из которых хочу вам рассказать.

В 2018 я впервые познакомился с Kotlin, и он мне практически сразу понравился. Да и как можно не полюбить язык, названный в честь тотемного животного всех программистов? Шучу, на самом деле в честь острова.

Я уже несколько лет пишу бэкенд на Kotlin. До этого писал на Java, но переход совершил практически одномоментно, потому что тогда мне  казалось, что Kotlin закрывает множество минусов Java и привносит более простой и лаконичный синтаксис.  Но при этом я стараюсь следить за тем, как развивается Java.

У любого процесса есть своё бутылочное горлышко. Если разобрать его на одной стадии процесса, оно непременно появится на другой. Но одно бутылочное горлышко может соответствовать максимальной эффективности команды, а другое будет тормозить поставку вашей ценности заказчику. При этом заранее угадать на старте проекта, где будет ваше бутылочное горлышко — очень сложно.
Мы расскажем, как искали путь выхода из подобной ситуации. Почему при достаточном соотношении QA и DEV-инженеров в команде у нас сформировалось бутылочное горлышко на стадии тестирования. Как обсуждения пирамиды тестирования и распределения зон ответственности за качество продукта помогли избавиться от недоверия в команде и ускорить поставку ценности.

Будет полезно тем, кто ищет реальные кейсы по оптимизации процессов тестирования и хочет узнать, как построить работающий QA-процесс в условиях ограниченных ресурсов и быстро меняющихся требований.

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

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

Термин «artificial intelligence» в английском языке означает не столько «интеллект», сколько «умение логически мыслить». Это значит, что ИИ — это не аналог человеческого интеллекта, способного познавать мир и понимать суть вещей (согласно определению Линды Готтфредсон), а лишь система, которая способна делать выводы, решать задачи, понимать сложные концепции, быстро осваивать новое и учиться на основе полученного опыта.

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

Всем привет!

Меня зовут Илья, я работаю в Райффайзен Банке. Мы пишем свои бэкенд-сервисы на Java и Kotlin, поэтому зачастую приходится переключаться с одного языка на другой. Из-за этого невольно начинаешь сравнивать подходы и механизмы одного языка с его JVM-собратом. Сегодня я бы хотел поговорить об одном из таких механизмов — пропагации ошибок и исключений.

Используете ли вы в своем коде исключения? Ответ кажется странным, так как исключения являются неотъемлемой частью Java. Но что, если я спрошу, используете ли вы исключения для управления логикой своей программы?

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

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

­­­Какие предметы вам нравились в школе? Я очень любила математику.  Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.

Сейчас, проектируя программные системы, я тоже решаю задачи, но они принципиально отличаются от математических, где всегда есть единственно верное решение. Если в школе небольшого условия задачи было достаточно, при проектировании это не так. Как говорил итальянский программист Альберто Брандолини: «В прод идут не знания экспертов в предметной области, а предположения разработчиков». Поэтому важно не просто полагаться на своё понимание, а проверять предположения на практике.

Для этого необходимо организовать совместное исследование сложной предметной области бизнеса: собрать команду, построить модель процессов и сверить свои гипотезы с реальными знаниями экспертов. По моему опыту, снизить неопределенность в понимании предметной области и проверить предположения на соответствие действительности помогает — Event Storming. Эта техника выявляет и минимизирует влияние ошибочных предположений на качество конечного продукта.

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

Большинство стандартов безопасности описывает лучшие практики настройки управляющих компонентов — control plane. Нечасто встречаются рекомендации по грамотной настройке рабочих единиц — подов. В статье попробуем восполнить этот пробел. Выполним обзор источников, рассмотрим хорошие практики работы с образами. Изучим, как ограничить привилегии контейнера и почему это важно. Поговорим о инструментах автоматической проверки манифестов и разберем примеры GItlab CI пайпланов.

Мы долгие годы писали сервисы исходя из каких-то своих внутренних ощущений правильности их написания. Но синхронизироваться по хорошим практикам в разных командах бывает довольно сложно и часто хорошие практики не выходили за рамки одной команды, а такого хотелось бы избежать. Поэтому мы решили объединить все хорошие по нашему мнению практики в единый справочник. Этот справочник получил название «Архитектурный гайд». Про него и поговорим в данной статье.

Привет, Хабр! Меня зовут Алёна, я senior фронтенд-разработчик отдела разработки ПО для розничного бизнеса в Райффайзенбанке. Недавно передо мной встала задача улучшения пользовательского опыта обработки ошибок запросов к бэкенду. Я решила комплексно исследовать эту тему на примере HTTP-клиента Axios.

Если при отправке запросов с помощью Axios возникает ошибка — клиентское приложение получает аргумент, который может быть экземпляром объекта, производного от системного класса Error, или любым типом. Он может содержать много информации и не всегда понятно, что самое важное для определения типа исключения и способа обработки. Поэтому я выделала 4 категории ошибок запросов, сделанных при помощи Axios, которые нужно по-разному интерпретировать.

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

Статья будет полезна не только дизайнерам, но и разработчикам. Так вы сможете посмотреть на себя и свою работу со стороны, понять, как вас воспринимают дизайнеры, и, возможно, пересмотреть свое отношение к дизайн-процессу. Давайте начнём!

Представьте, что вы приходите в «дикую» команду, которая долгое время или всегда жила без дизайнера. В ней уже сложились коммуникации и процессы, в которые дизайнер не вписывается. Поэтому вас не хотят слушать, не слышат сильной аргументации, не понимают процесса дизайнера и зачем он вообще нужен. Для них вы просто руки, которые рисуют. Хотя это может быть актуально и для команд с опытом работы с дизайнером.

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

В этой статье расскажу, как мы объединили несколько разных команд разработки Райффайзен Онлайн общим Observability и с помощью исключительно технических метрик отслеживаем здоровье бизнес-процессов. Как всё это помогает мгновенно находить первопричину сбоя. Как устроен OpenTelemetry и как с его помощью рассчитать доступность приложения в девятках, а также MTTR (Mean Time to Recovery).

Мы так гонимся больше знать и уметь, что не заметили, как стали менее устойчивыми. Мы прокачали свой IQ, но оставили за бортом наш EQ. А высокий эмоциональный интеллект и навыки общения от природы имеют единицы. Большинству же необходимо работать над своим EQ, чтобы стать более эмоционально устойчивыми. И этот путь не имеет финальной точки.

Привет, Хабр! Я старший системный аналитик Федор Качан. Попробую рассказать, почему эмоциональный интеллект может быть важнее IQ. Зачем соблюдать баланс между IQ и EQ. Что такое эмоциональная шкала и как развить свой эмоциональный интеллект в любом возрасте.

Привет! Меня зовут Максим Черноусов, и я занимаюсь iOS-разработкой в Райфе. Я обожаю использовать и дизайнить классные API. А один из самых часто используемых строительных блоков для хороших API в Swift — это KeyPath'ы. Сегодня о них и поговорим.

Первый открытый митап iOS Community: приглашаем 2 февраля слушать интересные доклады и вовлекаться в дискуссии! Поговорим про Dependency Injection, подход async/await в задачах с многопоточностью и snapshot-тестирование.

Под катом — видео митапа и презентации спикеров :)

В ноябре dgtl-команды Райффайзенбанка рассказали о шести продуктах на открытом демо-дне. Трансляция была в прямом эфире для всех, кому интересно заглянуть под капот банковских сервисов и узнать подробнее о технологиях.

Всем привет! Меня зовут Николай Первухин, я Senior Java Developer в Райффайзенбанке. В последнее время я активно занимаюсь BPM-системами Camunda и Zeebe (основа Camunda-cloud). Если вы, как и я, с ходу не можете ответить на вопрос, кто быстрее — Camunda или Zeebe, насколько, и в каких случаях они могут тормозить, то добро пожаловать под кат.

Всем привет! Меня зовут Аникин Денис, я тимлид в команде Chat в Райффайзенбанке. А также представитель внутреннего Python-сообщества, так называемый «community lead» (об этом как-нибудь в другой раз). В этой статье я хотел поговорить про отношение к Python среди разработчиков и обсудить все основные претензии, которые очень давно следуют за языком по пятам.