Книжный куб

[2/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management) Мы остановились в прошлом посте на платформах и их сложности. А что делать для борьбы с такой сложностью? - Для работы над сложностью отдельных инструментов ребята в Google пошли в продуктовую сторону и решили понять, а какие цели у инженеров в разработке софта. Свой подход они описали в whitepaper "Measuring developer goals", про которую я рассказывал раньше. Смысл в том, чтобы выделить фазы жизненного цикла разработки софта, а внутри них определить аля jobs to be done сценарии, которые нужны инженерам. Дальше эти сценарии можно оцифровать с помощью телеметрии от платформенных инструментов и при помощи опросов инженеров. Сами сценарии расскладываются на использование нескольких инструментов и дальше можно оптимизировать и AI-фицировать не отдельные инструменты, а весь сценарий (в перспективе его можно попробовать отдать AI агентам) - Одновременно, интересно взглянуть на ожидания самих инженеров от AI внутри платформ. Ребята из Google летом 2024 года выпустили whitepaper "What Do Developers Want From AI?" (мой обзор), где рассказали про три уровня улучшения AI для инженеров (интересно, что они провели параллели с автомобильной промышленностью и водителями) 1. Enhancing human capabilities - гидроусилитель руля и анти-блокировочная система в машинах, автодополнение кода в IDE 2. Extending human capabilities - камера заднего вида и контроль слепых зон в машинах, чат и code review suggests в разработке 3. Delegating human capabilities - улучшенный круиз-контроль и держание полосы в машинах (включая автопилот от Tesla), агентские workflow в AI, включая автоматическое удаление dead code, а также генерацию тестов В общем, этот подход неплохо показывает как AI постепенно может проникать в процессы разработки. А дальше интересно глянуть на подходы западных bigtech компаний к реализации второго и третьего уровня - Google и дизайн API. У ребят из Google были 2 научные статьи в середине 2024 года "API Governance at Scale" (мой разбор) и "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" (мой разбор). В них они рассказывали про свой подход к дизайну API, который у них отлично стандартизован (подробнее в aip.dev), а дальше они попробовали поверх этих стандартов прикрутить api architect (это LLM модель для генерации спеки по продуктовым требованиям). - ByteDance и code review. У ребят из ByteDance есть научная статья 2025 года "BitsAI-CR: Automated Code Review via LLM in Practice" (мой разбор: 1, 2 и 3). В ней они рассказывают про свой pipeline для работы с code review, где есть 200+ категорий, моделька для генерации комментов, моделька для ревью, а также feedback loop от инженеров для тюнинга эффективности все системы - Uber и крупномасштабная миграция с Java на Kotlin. Они рассказывали это докладе "This Year in Uber’s AI-Driven Developer Productivity Revolution" на конференции DPE 2024 (мой разбор: 1 и 2). Если кратко, то у ребят было много Java кода, что они хотели переписать на Kotlin. В децентрализованном варианте команды делали бы это вялотекуще 10+ лет, ребята прикрутили сначала LLM и сократили оценку в 3 раза, а потом скомбинировали LLM и AST и смогли по оценке уложиться в 18 месяцев на всю миграцию кодовой базы. - Booking и внешнее партнерство с Sourcegraph. Booking решил приобщаться к AI через внешнего партнера (подробнее здесь). Sourcegraph сделали для Uber генерации QraphQL request из API Booking по текстовому описанию запроса, сделали code review, а также вывели из анабиоза проект по миграции кодовой базы, что шел уже 14 лет. - Datadog и AI oncall engineer. Datadog - это observability платформа, которая решила сделать oncall engineer. Про это они рассказывали в начале этого года, а я писал об этом раньше В финальном посте мы обсудим как дела обстоят в Т, а также завершим рассказ выводами. #AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[1/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management) Сегодня в 17.00 я выступаю с таким докладом на CTO Conf X, профессиональной конференции для технических директоров, от компании "Онтико". Я расскажу о хайповой теме об интеграции искусственного интеллекта в жизненный цикл разработки софта в больших компаниях. Ниже я расскажу про структуру доклада и приведу ссылки на дополнительные материалы, которые я использую для референсов в моем выступлении. В своем докладе я начинаю выступление с того, что вспоминаю об copilot инструментах разработчиков: GitHub Copilot, Cursor, Windsurf, которые задали некоторый стандарт AI ассистентов для разработчиков и позволили делать многое автоматически. В феврале 2025 года Andrej Karpathy дал начало новому тренду разработки под названием vibe coding

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

Этот тренд подхватили ребята из акселлератора стартапов Y Combinator и уже в марте начали обсуждать эту тему в подкастах: - "Vibe Coding Is The Future" (я его уже разбирал) - "Интервью с CEO Windsurf про будущее программирования" (я его уже разбирал) - и даже "Vibe coding tips в их Startup Schools". Отдельно можно добавить, что хайпа добавляют заявления Сэма Альтмана, CEO OpenAI, или Дарио Амодея, CEO Antrophic. Например, Дарио три месяца назад на выступлении "The Future of U.S. AI Leadership with CEO of Anthropic Dario Amodei", про которое я уже рассказывал, выдал предсказание про будущее разработки

I think we will be there in three to six months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all of the code

Возникает вопрос, а как этого можно добиться? Ответ в использовании агентов: - В прошлом году ребята из Antrophic представили MCP (model context protocol) для предоставления LLM доступа к дополнительным инструментам - А уже в этом году Google представили протокол уже для взаимодействия агентов A2A (Agent2Agent) протокол В общем, тема сейчас хайповая и для создания MVP в стартапах или pet проектов разработчиками этот подход к использованию copilots в режиме vibe coding отлично подходит. А вот для крупных компаний не все так просто и дальше я объясню почему Инженерные процессы в крупных компаниях эволюционировали следующим образом: - Когда-то разработка и эксплуатация была разделена и этот разрыв мешал достигать бизнес-результатов. В итоге, с середины 2000х по конец 2010х евангелировался DevOps подход, который с научной точки зрения был обоснован в книге "Accelerate", про которую я рассказывал раньше в трех частях: 1, 2 и 3. - Этот подход зачастую приводил к гетерогенному ИТ-ландшафту с большим дублированием систем, что не позволяло получить эффект масштаа - крупные компании пошли в сторону разделения stream-aligned команд и platform команд, которые должны были создать платформы, навроде Internal developer platform, которая позволяла бы инженером в формате self service пользоваться инструментами навроде работы с кодом, артефактами, CI/CD пайплайнами, рантаймом, observability и так далее - Дальше платформы стали достаточно сложными и владельцы платформ решили идти в сторону user experience своих пользователей, которыми являются разработчики. Так появилась концепция developer experience, в которую входит flow state, cognitive load, feedback loops (про это можно почитать в whitepaper "DevEx: What Actually Drives Productivity", про которую я рассказывал раньше). Это важно, так как сложность платформ может зашкаливать - этом можно продемонстрировать, взглянув на картинку с CNCF landscape, где количество карточек продуктов зашкаливает и разобраться с тем, что и как обычному человеку крайне сложно. Продолжение в следующем посте. #AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[2/2] What's the Use?: The Unreasonable Effectiveness of Mathematics (Это база. Зачем нужна математика в повседневной жизни) (Рубрика #Math) Продолжая рассказ, об этой научно-популярной книге, расскажу содержание оставшихся глав 4. Почки Кенигсберга - все начинается с задачи о мостах Кёнигсберга, появления теории графов, а дальше их применения для трансплантации органов в UK. 5. Будьте осторожны в киберпространстве - здесь по классике идет речь про шифрование, дальше про ассиметричное шифрование, использование для этого разложения на простые числа, а потом переход к эллиптическим кривым 6. Числовая плоскость - здесь автор рассказывает про натуральные числа, рациональные, иррациональные и комплексные. Он рассказывает как появились комплексные числа и что их представление - это уже не числовая прямая, а числовая плоскость, где интерпретация связана с синусами и косинусами. Интересно, что для многих физических задач использование комплексных чисел позволяет проще описывать и решать задать задачи 7. Папа, ты научился перемножать триплеты - рассказ про квартернионы Гамильтона, которые позволяют проще описывать и решать задачи преобразования положения объектов в трехмерном пространстве. Это очень пригождается в трехмерной графике. 8. Вот это отскок - интересная глава, где автор переходит от расчета параметров пружин к аттракторам Лоренца и теории хаоса 9. Верь мне, я ряд Фурье - здесь автор рассказывает про разложение в ряд Фурье, дальше про преобразование Родона и как все это используется в условных КТ аппаратах для восстановления трехмерного изображения по большому количеству двумерных проекций с разных направлений 10. Улыбнитесь, пожалуйста! - коротенькая глава про сохранение изображений, где есть рассказ про jpeg, а также про использование вейвлетов для хранения изображений отпечатков пальцев в архиве ФБР 11. Мы уже почти приехали? - автор рассказывает про то, как работает GPS и какие области физики и математики нужны для работы геопозиционирования 12. Оттаивание Арктики - рассказ как модель для магнитов была переиспользована для анализа таяния прудов на поверхности льдин. Очень интересный и нетривиальный пример 13. Позовите тополога - базовый рассказ, что начинается с ленты Мебиуса, бутылки Клейна и быстро переходят к инвариантам и рассказом про гомологиям, когомологиям, а также к прикладной топологии и рассказывают про постоянные гомологии, что можно использовать для анализа покрытия некоторой территории датчиками. В общем, эту главу не так уж и просто читать. 14. Лиса и еж - эта глава завершает книгу и в ней автор размышляет о природе математического мышления и его роли в человеческой цивилизации, используя метафору лисы и ежа, а также фантастический образ математикоядных инопланетян. Стюарт опирается на знаменитое высказывание: «Лиса знает много разных вещей, а ёж — одну, но большую». Для иллюстрации он вводит образ «математикоядных инопланетян». Представьте себе цивилизацию, которая охотится на математику, чтобы выжить, и потому вынуждена искать новые математические идеи везде, где только можно. Тут она прилетает в гости к нам и начинает есть нашу математику, начиная с изысков высшей математики. Дальше у нас начинают исчезать общепринятые вещи - телефоны, компьютеры, интернет, геопозиционирование, ... Эти инопланетяне останавливаются, но у нас остается только арифметика, которой они побрезговали, а также каменный век вокруг нас. Через эту историю Иэн показывает принципиальное значение математики для окружающего нас мира, хотя большая часть людей не знает об этом. Иэн предлагает популяризировать это и увеличивать количество людей занимающихся математикой, где она воспринимается как насыщенная творческая дисциплина, а не примитивная карикатура, какой ее нередко представляют. И завершается книга фразой Да, лиса знает много секретов, а математики - всего один, но очень большой. Он называется математикой, и он преобразует наш мир. #PopularScience #Math #Physics

[1/2] What's the Use?: The Unreasonable Effectiveness of Mathematics (Это база. Зачем нужна математика в повседневной жизни) (Рубрика #Math) С большим удовольствием я прочитал эту научно-популярную книгу Иэна Стюарта (Ian Stewart). Оригинал вышел в 2021 году на английском, а русское издание в 2024, так что книга достаточно свежая:) Хотя, в название книги вынесено название статьи 1960 года Eugene Wigner про необъяснимую эффективность математики. Иэн в этой книге выбрал своей целью показать, что математика лежит в основе практически всех современных технологий и влияет на все сферы жизни. Он опровергает заблуждения о том, что с появлением компьютеров математика утратила свою значимость (видимо из-за возможностей расчетов многих вещей брутфорсом). Напротив, он доказывает, что именно математика делает возможными такие явления XXI века, как цифровая фотография, спутниковая навигация, интернет-безопасность, прогнозирование климата и многое другое. Книгу интересно читать, так как автор шарит в теме - он является профессором математики, членом Лондонского королевского общества, а также он умеет рассказывать сложные вещи на простом языке. Если говорить про саму книгу, то в первых 13 главах рассматриваются разные разделы математики с базовой теорией (но без формул) и с практическими эффектами 1. Непостижимая эффективность - введение, где автор делится основной идей книги, что я описал выше 2. Как политики выббирают своих избирателей - автор описывает проблему голосований на примере округов в США, а также тут идет речь о справедливом разделении условного торта двумя людьми 3. Пусть голубь ведет автобус - большая глава, которая начинается с задачи коммивояжера, рассмотрения вопроса сложности P и NP задач, вопросы бесконечностей, заполняющих пространство кривых Пеано и Гильберта, а дальше возможностей зрения и машин-автопилотов Продолжение в следуюшем посте. #PopularScience #Math #Physics

Круглый стол «Техлид и развитие в Individual Contributor: как превратить код в карьеру» (Рубрика #Engineering) Сегодня буду в рамках круглого стола на Techlead Conf X обсуждать этот вопрос с джентельменами из разных компаний, где у нас соберется квартет представленный ниже - Максим Вишневский, ведущий (Mindbox) - Глеб Михеев (Сбер) - Александр Белотуркин (Делимобиль) - Александр Поломодов (Т-Банк) И вместе мы точно поговорим про то - Как роль техлида влияет на бизнес: от компаний с развитой IC-веткой до тех, где влияние минимально? - Какие навыки и подходы нужны техлиду в бизнесе, архитектуре и технической экспертизе, а также как расти по IC-ветке? - Почему в российском IT IC-ветка слабо развита и какие перспективы для роста? - Как формируется роль техлида в разных компаниях, почему она часто остается неофициальной и как развивать навыки без продуктового контекста? Думаю, что мне будет, что добавить к этой дискуссии, так как раньше я уже много рассказывал на эту тему - Code of Leadership #6 Staff+ инженеры, архитектура и SDLC - Варианты роста инженера, если он уже Senior на Tinkoff Meetup 2023 - Как нанимать технических руководителей на Teamlead Conf 2023 - Архитектура в масштабе на ArchDays 2020 - System Design Interview на ArchDays 2021 - Как подготовиться и пройти System Design Interview на ArchDays 2022 - Книга Will Larson "Staff Engineer" и мои обзоры этой книги в двух частях: 1 и 2 - Книга Tanya Reilly "The Staff Engineer's Path" #Staff #SoftwareDevelopment #Software #SelfDevelopment #Career

Moving Faster and Reducing Risk: Using LLMs in Release Deployment (Рубрика #AI) Интересный lighting talk с DPE Summit 2024 от Руи Абреу из Meta на тему повышения надежности релизов при помощи LLMs. Вообще, Meta признана экстремисткой организацией и ее деятельность запрещена на территории России. Вот основные моменты из этого выступления 1. Проблема масштаба в релизной инженерии - на масштабах Meta невозможно централизованно решать, что выпускать в продакшн. Ответственность передается разработчикам, пишущим и ревьюящим код. 2. Треугольник продуктивности - для ребят продуктивность является балансом между тремя измерениями: скорость (velocity), надежность (reliability) и читаемость кода (readability). Оптимизация одного параметра влияет на остальные. 3. Система оценки рисков диффов - ребята разработали модели для предсказания вероятности того, что diff вызовет серьезный сбой, влияющий на пользователей 4. Эволюция практик code freeze - ребята перешли от полной блокировки изменений к интеллектуальному гейтингу на основе оценки рисков. 5. Многоуровневое гейтирование - ввели четыре типа ограничений: зеленый (без ограничений), выходные дни (5%), средний риск (10%) и высокий риск (50% самых рискованных диффов). 6. Сравнение подходов к ML - проверяли модели на базе логистической регрессии, BERT-based моделей (StarBERT) и генеративных LLM для предсказания рисков. 7. Превосходство risk-aligned LLM - по результатам тестов победили risk-aligned модели iDiffLlama-13B 8. Упрощение feature engineering - для LLM моделей потребовались только три входных параметра: название изменений , план тестирования и сами изменения кода (интересно, что summary изменений в модель не подаются, так как они позволяют манипуляции). 9. Практические применения - по итогу внедрения этих рисковых моделей ребята смогли прийти к рекомендациям ревьюеров для рискованных диффов, автоматическому одобрению низкорискованных изменений, ну и общему улучшению процесса релизов. 10. Баланс скорости и качества - появилась возможность "разморозить" некоторые диффы во время code freeze, не блокируя все изменения на 100%, что повышает продуктивность инженеров. В итоге, это интересный подход для повышения качества через гибкое управление рисками релизов. Интересно, насколько это реально работает в Meta и раскатано ли на все продукты/проекты. #AI #Software #Engineering #Architecture #Agents #Math #Software #ML

AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms (Рубрика #AI) В середине мая Google выпустила интересную статью про своего агента AlphaEvolve, который способен разрабатывать продвинутые алгоритмы для решения сложных задач. По-факту, это эволюционирующий coding agent на базе пары LLM от Google, который способен решать задачи оптимизации. Более подробный рассказ о внутренностях этого агента доступен в отдельной научной статье (на 44 страницы). Этот алгоритм AlphaEvolve – результат коллективной работы команды Google DeepMind под руководством восьми ведущих исследователей, внесших равный вклад: Alexander Novikov, Ngân Vũ, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov и Borislav Kozlovskii. Среди других авторов: Francisco J. R. Ruiz, Abbas Mehrabian, M. Pawan Kumar, Abigail See, Swarat Chaudhuri, George Holland, Alex Davies, Sebastian Nowozin, Pushmeet Kohli и Matej Balog. Данный коллектив объединил специалистов в области машинного обучения, алгоритмической оптимизации и математического моделирования. Если говорить про схему работы агента, то ключевые моменты следующие 1. В системе используется два типа моделей - Gemini Flash – более быстрая и эффективная модель с низкой задержкой, максимизирующая объем генерируемых идей за единицу времени - Gemini Pro – более мощная модель, обеспечивающая периодические высококачественные предложения для прорывных решений 2. Система использует эволюционный подход к модификации кода AlphaEvolve использует эволюционную структуру, где агенты предлагают программы, реализующие алгоритмические решения в виде кода. Эти решения автоматически оцениваются при помощи чего-то типа fitness functions 3.Автоматизированная оценка Система включает автоматизированные оценщики, которые проверяют, запускают и оценивают предложенные программы по объективным метрикам. Это обеспечивает количественную оценку точности и качества каждого решения, делая систему особенно эффективной в областях, где прогресс может быть четко и систематически измерен. Вот цитата из научной статьи, на которую я давал ссылку выше

The LLM-directed evolution process is grounded using code execution and automatic evaluation

В статье ребята рассказывают про крутые результаты модели - Повышение эффективности дата-центров: AlphaEvolve разработал эвристику для оркестратора Borg, которая непрерывно восстанавливает в среднем 0,7% мировых вычислительных ресурсов Google. - Оптимизация чипов: система предложила переписать код Verilog для удаления избыточных битов в арифметической схеме умножения матриц, что было интегрировано в новую версию TPU. - Ускорение обучения LLM моделей: AlphaEvolve ускорил ключевой компонент архитектуры Gemini на 23%, что привело к сокращению времени обучения Gemini на 1% - Новый алгоритм умножения матриц: AlphaEvolve обнаружил алгоритм для умножения комплексных матриц 4×4 с использованием всего 48 скалярных умножений, что превосходит алгоритм Штрассена 1969 года, что был топовым раньше. Эти достижения базируются на предудыщих исследованиях - AI Co-scientist (2025) - мультиагентная система на базе Gemini 2.0, предназначенная для помощи ученым в генерации новых гипотез и исследовательских предложений. - AlphaTensor (2022) - система от DeepMind, специализирующаяся на автоматическом обнаружении новых алгоритмов умножения матриц с использованием глубокого обучения с подкреплением. - AlphaZero - Технология глубокого обучения с подкреплением, лежащая в основе этих систем, берет свое начало от AlphaZero – самообучающейся системы DeepMind, которая освоила настольные игры, такие как го, шахматы и сёги. В итоге, у авторов этой агентской системы большие планы на ее дальнейшее развитие, но уже в текущем состоянии результаты выглядят очень круто и применимо для широкого круга задач. По-факту, авторы показали как можно перейти от специализированных систем к более гибким агентам. #AI #Software #Engineering #Architecture #Agents #Math #Software #ML

ЦСКА - Зенит (Рубрика #Sport) Был вчера на четвертом матче финальной серии между баскетбольными ЦСКА и Зенитом со средним сыном и друзьями. Интересно, что перед этим матчем ЦСКА уступал 1:2 по результатам трех встреч, поэтому мы рассчитывали на плотный и конкурентный матч ..., но что-то пошло не так. ЦСКА свои мячи забивал, а Зенит начал сыпаться со второго периода. К концу третьего периода на счету Зенита было 36 очков, а у ЦСКА было в два раза больше очков и это было похоже на разгром. Один из игроков Зенита в этот момент сел на велосипед и походу решил поехать в Питер, правда забыл, что он зафиксирован:) Но дальше на паркет со стороны ЦСКА вышли запасные и дали Зениту свести игру к респектабельному итоговому счету 85:62. В общем, мы все болели за ЦСКА и матч нам понравился. Теперь планируем сходить на следующий московский матч этих команд:) #Kids #ForParents #ForKids

How To Design Better AI Apps (Рубрика #AI) Интересное интервью с Pete Koomen, генерального партнера Y Combinator и основателя Optimizely, где обсуждаются идеи из его эссе "AI Horseless Carriages", в котором он создал демо с использование AI для работы с почтой с нуля. Собственно, в этом интервью речь идет о следующих темах 1. Проблема "AI-колясок без лошадей" Многие разработчики используют старые подходы разработки софта для создания AI-функций, не раскрывая полный потенциал технологии. Как отмечает Koomen: "Мы используем старую ментальность разработки ПО, старые техники для создания этих функций, и мы на самом деле не используем полностью то, что может AI". 2. Скрытые системные промпты ограничивают возможности Gmail AI создает формальные, безликие письма из-за скрытого системного промпта, который пользователи не могут увидеть или изменить. Это приводит к тому, что AI-помощник пишет как "универсальный писатель электронных писем для всех", а не как конкретный пользователь. 3. Пользователи должны иметь доступ к системным промптам Возможность редактировать системные промпты позволяет персонализировать AI под конкретного пользователя. Koomen демонстрирует в своем демо, как изменение промпта с универсального на персональный кардинально улучшает результат. 4. Преодоление разделения "разработчик-пользователь" Традиционное ПО требует разделения: разработчик пишет код, пользователь использует интерфейс. AI позволяет пользователям "программировать" приложения на естественном языке, что меняет эту парадигму. 5. AI-агенты для чтения писем эффективнее чат-ботов Koomen показывает пример email agent, который может автоматически сортировать, помечать и отвечать на письма на основе пользовательских инструкций. Это более мощный подход, чем простые чат-боты. 6. Важность инструментов (tools) для AI-агентов AI-агенты становятся по-настоящему полезными, когда у них есть доступ к инструментам для выполнения действий в реальном мире. Разработчики должны фокусироваться на создании богатой экосистемы инструментов. Здесь можно вспомнить про MCP протокол, который сейчас популярен для предоставления доступа агентам к внешним инструментам 7. Coding agents показывают правильное направление Coding agents как Cursor и Windsurf работают лучше других AI-приложений, потому что они дают полный доступ к возможностям модели без ограничений (ну или почти без ограничений) 8. Чат-бот парадигма ограничивает AI Большинство продуктов просто встраивают чат-агентов в существующие интерфейсы, что не использует истинные возможности AI (мы не знаем какие системные промпты есть на стороне чатботов) 9. Каждый может стать prompt engineer Написание промптов интуитивно понятно - это просто объяснение AI того, как вы принимаете решения. "Это не навык, с которым мы рождаемся, но это довольно интуитивно". 10. Переосмысление продуктов с нуля для AI Основателям стартапов следует спрашивать не "Как вставить AI в мой инструмент?", а "Как я бы спроектировал этот инструмент с нуля, чтобы максимально автоматизировать повторяющуюся работу пользователя?". В общем, это интересный взгляд на создание продуктов, но, давая доступ к настройкам AI моделей для обычных пользователей, мы оказываемся в опасном мире - представьте, что для езды на машине вам надо было бы собирать и настраивать ее двигатель и ходовую. А вот тюнить модельку, основываясь на артефактах и поведении пользователя - это уже гораздо ближе к удобному и безопасному продукту, если продолжать аналогию с машинами, то это бы значило подстройку конфигурации машины под ваше типовое поведение как водителя:) #AI #ML #Software #DevEx #Engineering #Development

[2/3] Acing the System Design Interview (System Design: пережить интервью) (Рубрика #Architecture) Продолжая рассказ про книгу о system design, расскажу про оставшиеся четыре главы первой части. 3. Non-functional requirements Эта глава целиком посвящена нефункциональным требованиям, которые часто называются архитектурными характеристиками ("-ilities") или атрибутами качества. Автор отдельно разбирает такие штуки как scalability, availability, fault-tolerance, performance/latency и throughput, consistency, accuracy, maintainability, cost, security, privacy, cloud native. Интересно, что я много раз рассказывал про НФТ или "-ilities", например с теми же ребятами из {между скобок} мы как-то разбирали работу с архитектурными характеристиками. Ну и недавно у меня был обзор whitepaper "Quality Metrics in Software Architecture" в трех частях: 1, 2 и 3. 4. Scaling databases Эта глава целиком посвящена том, а как жить с состоянием, которое надо где-то хранить. В system deisgn задачах обычно эта stateful часть одна из самых интересных и она требует умения ее масштабировать и отвечачть на вопрос, а как обрабатывать сотни миллионов пользователей и миллиарды запросов. Здесь автор рассказывает про репликацию и шардирование, аггрегацию событий, батчинг и стриминг. Дальше наступает время денормализации и кеширования, где обсуждаются разные техники кеширования, инвалидации кешей, а также их прогрева. Рекомендую почитать книгу "Database Internals", про которую я рассказывал в двух частях: storage engines и distributed systems. 5. Distributed transactions Целая глава посвящена распределенным транзакциям, хотя двух-фазный коммит вынесен в приложение и автор рассказывает о спрособах избежать распределенных транзакций. Для этого он говорит про крупные темы вида - Event driven architecture и event sourcing - интересно, что эту тему отличо разбирает Влад Хононов в книге ""Learning Domain-Driven Design", я даже делал обзор этой темы в виде статьи в своем блоге. - CDC - описание как отливать изменения из баз данных, используя условный Debezium - Использование супервизоров транзакций, а также использование саг (оркестрируемых и хореографируемых) В общем, интересная глава, но короткая - для реального понимания затронутых тем придется почитать книги поглубже 6. Common services for functional partitioning queue В этой главе автор рассказывает про общую функциональность, что нужна сервисам: - Аутентификация, авторизация, шифрование - Проверка ошибок: валидация, дедубликация - Производительность и надежность: опять кеширование, rate limiting - Логгирование и аналитика Дальше идут паттерны для декомпозиции вида service mesh (istio) и sidecars, service discovery, использование библиотек для общей функциональности или вынос сервисов. Ну и финализируется все обсуждением API, которое автор начинает с рассказа про модель OSI, а дальше идут стандартные REST, RPC, GraphQL, WebSocket и их сравнения. В общем, в первой части излагаются важные концепции, которые полезны не только на собеседованиях, но и в практической работе:) Структурированный подход к работе с требованиями, анализу trade-offs и принятию архитектурных решений помогает в реальных проектах. Особое внимание автор книги уделяет коммуникации и зрелости инженеров — умению объяснять решения, обсуждать компромиссы, адаптироваться к изменяющимся требованиям. Эти качества важны для взаимодействия с другими командами и бизнес-стейкхолдерами. #Software #Architecture #DistributedSystems #SystemDesign #Engineering

[1/3] Acing the System Design Interview (System Design: пережить интервью) (Рубрика #Architecture) Последний месяц я потихоньку читаю книгу Zhiyong Tan, что посвящена system design interview и в виде перевода выпущена издательством Питер. Книгу я решил прочесть из интереса, чтобы сравнить с тем подходом, который близок мне и про который я рассказывал и долгое время развивал у нас внутри компании. TLDR; книга мне показалась полезной и понравилась, причем больше, чем книга Alex Xu, про которую я тоже рассказывал. Начнем с того, что автор, Zhiyong Tan, сейчас engineering manager в Paypal, а до этого был senior fullstack инженером в Uber, data инженером в небольших стартапах, а также инженером в Teradata. В общем, этот опыт позволил ему посмотреть на вопросы проектирования решений и найма сотрудников в компаниях разного масштаба и уровня зрелости. Сама книга поделена на три части: 1) Первая часть состоит из 6 глав и содержит стрктурированное введение в system design interview - про эту часть мы поговорим ниже подробнее 2) Вторая часть содержит 11 примеров system design задачек 3) В приложениях есть сравнения монолитов и микросервисов, базовыый разбор OAuth 2.0 и OpenID Connect, рассказ про C4 Model, а также разбор того, как устроен двух-фазный коммит. В принципе, все эти темы так или иначе могут быть затронуты на собеседовании Дальше я расскажу про первые шесть глав, которые показались довольно здравыми 1. A walkthrough of system design concepts В первой главе автор вводит базовые понятия system design, знакомит с ключевой терминологией и объясняет, что system design - это про дискуссию вокруг компромиссов, на которые надо пойти при проектировании решения:) Дальше автор быстро и по верхам рассазывает про масштабирование различных сервисов, начиная с маленькой инсталляции приложения и накручивая сверху GeoDNS, кеширование, CDN, горизонтальное и вертикальное масштабирование, управление кластерами, разделение на функционально-независимые части. Интересно, что автор разбирает историю про работу с аналитическими данными (ETL), выделение общих сервисов, а также размещение рабочих нагрузок на bare metall, cloud или вообще внутри FaaS:) В общем, большая часть этих блоков может быть раскрыта в отдельную главу, если не книгу, но автор дает неплохое общее представление о самих концепциях 2. A typical system design interview flow Здесь автор описывает типичный процесс system design interview, акцентируя внимание на важности уточнения требований до начала проектирования. Особое внимание уделяется разделению functional и non-functional requirements. Интересно, что я как-то с ребятами из клуба {между скобок} разбирал flow собеседования, предложенный в книге Alex Xu, а также сравнивал с тем, что принято в Т. Если говорить подробнее про содержание главы, то тут идет речь про - Уточнение требований - Создание драфта спек API - Связь пользователей и данных - Моделирование моделей данных - Обсуждение логгирования, мониторинга и алертинга (я часто это оставляю на финал собеседования) Продолжение обзора первой части книги в следующем посте. #Software #Architecture #DistributedSystems #SystemDesign #Engineering

AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI) Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже 1. Реальность разработки По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях - Ментальная модель - что мы хотим сделать - Семантическая модель - как мы это будем делать - Синтаксическая модель - непосредственно сам код ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта. 2. Режимы работы разработчиков Существуют два основных режима: - Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем - Exploration - поиск информации в документации, интернете, общение с ИИ Понимание этих режимов критично для эффективного использования ИИ-инструментов. 3. Чего хотят разработчики от ИИ По мнению Евгения ожидания инженеров такие - Переложить на AI рутинные операции, например, написание юнит-тестов - Общаться на естественном языке с последующим уточнением через промпты - Получить детерминированные результаты от недетерминированного genAI Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper 4. Бизнес-приоритеты Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше 5. Проблема измерения эффективности Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании" 6. LLM ≠ Продукт Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели. 7. Правильные метрики Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок. 8. Снижение хайпа - это хорошо За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию. 9. Будущее: от генерации к агентам Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш. Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом. #AI #Software #Engineering #Architecture #Agents

Research Insights Made Simple #10 - Measuring Developer Experience With a Longitudinal Survey (Рубрика #DevEx) Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы проведения опросов инженеров "Measuring Developer Experience With a Longitudinal Survey". Для разбора этой статьи ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал - https://t.me/badTechProject За 40 минут мы успели обсудить следующие темы - Опыт Google в проведении опросов - Преимущества и процесс проведения опросов - Методология и анализ опросов - Важность коммуникации и внедрения изменений по итогам опросов - Роль менеджера и сменяемость ролей в команде - Масштабирование и частота опросов - Продуктовый подход и интеграция онлайн-опросов - Двухсторонний анализ: опросы и логи Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. P.S. Я разбирал этот whitepaper раньше в своем tg канале в двух частях: 1 и 2 #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Modular Monolith: Is This the Trend in Software Architecture? (Рубрика #Architecture) Интересный и короткий whitepaper на тему модульных монолитов, который задает вопрос насчет их трендовости. Авторы статьи сделили Systematic Grey Literature Review (SGLR) для анализа этого вопроса. По-факту, это анализ материалов, не прошедшие коммерческое академическое издание (отчёты ведомств и НКО, диссертации, доклады конференций, технические спецификации, preprint-репозитории, сайты проектов и т. д.). Они пытались понять насколько распространены модульные монолиты, стратегически сочетающие простоту разработки традиционных монолитов с преимуществами масштабируемости микросервисов, предлагая альтернативу, избегающую сложностей распределенных систем при сохранении модульных принципов. Вопрос был в том, а сможет ли modular monolith стать жизнеспособным компромиссом, дающим "лучшее из двух миров".Исследование мотивировано анонсом фреймворка Service Weaver от Google, позволяющего писать приложения как модульные монолиты с возможностью микросервисного деплоя. Интересно, что сам Service Weaver от Google и ответил на этот вопрос - с 6 июня он отправится в архив, не достигнув нужного уровня adoption. Но если возвращаться к самому whitepaper, то авторы пытались показать, что modular monolith обеспечивает: - Сохранение скорости разработки, характерной для монолитов - Четкие границы модулей, предотвращающие эволюцию в "big ball of mud" - Гибкость использования как самостоятельной архитектуры или промежуточного этапа перед микросервисами - Упрощение процессов отладки и тестирования - Эффективное масштабирование команд через распределение модулей Из исследования литературы они выделили следующие ключевые характеристики модульных монолитов - Segregation of modules: независимые модули с собственными слоями (Domain, Infrastructure, API) - Modularity: слабая связность и сильная связность внутри модулей, асинхронная коммуникация через API - Unified Database Schema: единая схема БД вместо отдельных схем на сервис - Monolithic Deployment: все модули работают в рамках одной VM или распределены по выделенным VM - Unified Application Process: единый процесс приложения для всех масштабов - Enhanced Maintainability: измеримое улучшение поддерживаемости vs традиционные монолиты В самом исследовании отмечалось, что известнейшими компаниями с модульными монолитами являются Shopify, Appsmith, Gusto, PlayTech, правда, они не использовали Service Weaver. P.S. Если отходить от самого whitepaper и оценить проблемы, что привели к закрытию Service Weaver, то можно отметить следующие 1) Низкий adop­tion rate - по-факту, это написано на странице проекта в аргументации к его закрытию

We realized that it was hard for users to adopt Service Weaver directly since it required rewriting large parts of existing applications. Therefore, Service Weaver did not see much direct use, and effective December 5, 2024, we will transition Service Weaver into maintenance mode.

2) Только go стек, что сужало целевую аудиторию 3) Опасность абстракций, когда локальный вызов может внезапно стать RPC (remote procedure call) - этим weaver напоминал концепцию CORBA/RMI, которая еще 20 лет назад показала свою непрактичность 4) Недостаточная функциональность - в фреймворке не было готовой маршрутизации/retries как в service mesh, нет встроенной mtls, нет удобного мониторинга 5) Конкуренция внутри самого Google Cloud - большинство кейсов, где weaver помогал пользователи уже решали через Cloud Run, GKE Autopilot + Istio или Functions, то есть им было проще использовать привычный стек, чем учить новую CLI и TOML-конфиги Weaver Итого, интересная идея не полетела из-за того, что не набрала критической массы пользователей, а также не предложила ответа на концептуальные вопросы вида local/remote procedure calls и их неполное соответствие друг друга в плане НФТ при разных видах deployments. Но для любителей модульных монолитов остались фреймворки вида Spring Modulith. #Architecture #Whitepaper #DistributedSystems #SystemDesign #Software #Engineering

Разработка собственного AI-ассистента для кода: спринт или марафон? (Рубрика #AI) Недавно у нас прошла конференция Platform Engineering Night, которую открывал Игорь Маслов докладом про "AI и Platform Engineering", основные мысли из которого я уже рассказывал. Но на этой конфе еще был целый ряд выступлений, одно из которых было Дениса Артюшина, который рассказал про то, как мы разрабатываем собственного ассистента Nestor, под которым зонтиком объединяются copilot вещи для SDLC (но первым делом copilot для кода в IDE). Основные мысли выступления были примерно следующими 1. В чем мотивация создания собственного ассистента? Начал Денис с объяснения, а зачем делать своего ассистента, где были несколько основных моментов - Безопасность решения, что сложно соблюсти при отправке кода внешним вендорам - Санкционные риски, которые защкаливают в текущих сложных геополитических условиях - Необходимость интеграции с внутренней инфраструктурой, которую так и так пришлось реализовывать 2. Как подходить к вопросу: как спринтер или как стайер? Сначала Денис рассказал про быстрые эксперименты в режиме спринтеров - так ребята запустили commit-сообщения, где от идеи до готового прототипа прошел один вечер пятницы. Схема была простой: берем diff, добавляем примеры, формируем промт и отдаем в модель. А потом он рассказал, что code completion требует серьезной инфраструктуры с A/B-тестами, анализом поведения пользователей и поиском похожего кода в кодовой базе, то есть тут нужен системный и размеренный подход 3. Что умеет Nestor? Основные фичи сейчас достаточно классические - Автодополнение кода - Чат с поиском по внутренней документации - Генерация commit-сообщений - Прототип редактирования кода - Генерация тестов (сейчас в разработке) 4. Какие метрики использования у ассистента? Они уже впечатляют: WAU: 5k, MAU: 9.5k. В некоторых профессиях проникновение превысило 60%, а acceptance rate поднялся до 30% на Go (пора переходить на go, ведь ассистенты на нем лучше всего ассистируют 😉) 5. Как сделали поиск по документации? На самом деле про поиск можно посмотреть в докладе Егора Прохоренко, про который я уже рассказывал. Но в Nestor пошли примерно так: структурированная документация → краткие описания → эмбеддинги → поисковая база. Также использовали русскоязычную модель TP Pro для лучшего качества ответов. 6. Как решали проблему масштабирования UI в плагине для IDE? Первоначальные чаты на TypeScript/CSS и Swing оказались немасштабируемыми. Перешли на React и Compose позволил легко добавлять новую функциональность. 7. Как балансировать тем в команде разработки? Спринты помогают тестировать гипотезы и поддерживать мотивацию олимпиадников в команде (значимая часть команды Nestor - это олимпиадники по программированию). А вот марафоны нужны для создания качественного продукта. 8. На какие метрики качества обращают внимание? Метрики есть разные - Adoption Nestor - Acceptance rate (очищенный от мусорных показов) - Внутренние бенчмарки для поиска по документации - Пользовательский фидбек и предложения по улучшению. 9. Какие планы по развитию? Планов много, но сейчас они видятся такими - Полноценное редактирование кода - Генерация тестов - Платформа агентов для всех отделов компании - Интеграция в другие продукты экосистемы (платформа для работы с данными Helicopter, observability платформа Sage) Если подводить итоги и отвечать на вопрос в названии доклада, то создание собственного ассистента требует сочетания быстрых экспериментов (спринты) для проверки гипотез и системной работы (марафоны) для качественного продукта. #AI #Software #Engineering #Architecture #Agents

Standoff на PHDays (Рубрика #Security) В этом году я был первый раз с PHDays в Лужниках и мне понравилось - масштабно, интересно, погода хорошая была:) Больше всего мне запомнилось не мое выступление на фестивале, а standoff павильон, где был создан киберполигон, воссоздающий комплексную IT-инфраструктуру различных отраслей: энергетики, банковского сектора, промышленности, транспорта и городского хозяйства. Инфраструктура включает более 600 единиц программного и аппаратного обеспечения, включая АСУ ТП, банковские системы, мобильные приложения и импортозамещенные Linux-домены. Но это было бы не особо зрелищно, если бы этот полигон был только виртуальным, но у него была реальная версия в антураже "ГрадМакет Россия" или "Макета Золотого Кольца", где у нас есть макеты промышленных объектов, чтобы зрители могли наблюдать реальные последствия успешных взломов: отключение освещения, остановку паровых турбин на ТЭЦ, сбои в банковских приложениях, задержки авиарейсов и даже падение контейнеров с портальных кранов. Это превращает абстрактную кибербезопасность в осязаемое шоу, где каждая успешная атака имеет видимые последствия. Круто, что виртуальная версия standoff 365 доступна онлайн и там есть отдельно онлайн полигон для новичков, а также для профи. P.S. В общем, организация фестиваля была на высоте, спасибо ребятам из positive technologies, что позвали выступить.. Думаю, что в следующем году опять поучаствую в этом кибер фестивале, если меня пригласят:) #Security #Architecture

Гибридный поиск на базе OpenSearch и Qdrant / Егор Прохоренко (Рубрика #Architecture) Интересное выступление моего коллеги, Егора Прохоренко, руководителя отделя поисковых технологий, про гибридный поиск в Т. Гибридный он потому, что Егор и его ребята смешали стандартный полнотекстовый поиск OpenSearch и векторную базу Qdrant для семантического поиска по embeddings. А как они это делали и для чего можно узнать из доклада, в котором были примерно следующие моменты 1. Проблематика поиска в банке Поиск нужен как клиентам (мобильные приложения, продукты, статьи), так и сотрудникам (внутренние базы, мессенджер, GitLab). В компании достаточно разветвленная инфраструктура - более 100 источников данных и сравнительно высокая нагрузка (1 млн DAU, 150 RPS), много индексов. 2. Концепция гибридного поиска Гибридный поиск сочетает классический полнотекстовый поиск и векторный (на основе близости эмбеддингов). Это позволяет находить релевантные документы, даже если в них нет прямого совпадения по ключевым словам. 3. Векторные базы данных и их особенности Векторные БД (например, Qdrant) решают задачу поиска ближайших соседей ANN (Approximate Nearest Neighbor) и часто используют графовый алгоритм HNSW (Hierarchical navigable small world). Хранят вектора и метаданные, поддерживают фильтрацию и масштабирование. 4. Архитектура реализации гибридного поиска Архитектура делится на слои - L1 — базовый индекс OpenSearch - L2 — ML-ранжирование (Catboost) - L3 — бизнес-логика Векторный поиск реализован как отдельный сервис, что позволяет быстро экспериментировать и не мешать основному поиску. 5. Эволюция реализации: от монолита к микросервисам - Первая попытка — интеграция ANN-модуля в монолит на C++ (Elastic), не дала прироста метрик, были проблемы с производительностью. - Вторая попытка — вынесение векторного поиска в отдельный Python-бэкенд (FastAPI, Qdrant), затем переписан на Rust для ускорения. 6. Фасетная фильтрация и ограничения векторного поиска В полнотекстовом поиске фильтрация реализуется легко, в векторном — сложно. Пришлось реализовать пост-фильтрацию и комбинированные подходы для отбора релевантных документов. 7. Кеширование эмбеддингов Для ускорения поиска и снижения нагрузки на эмбеддер реализовано агрессивное кеширование (до 98% cache-hit, 20 млн векторов в кеше). 8. Дообучение моделей и использование пользовательских данных Для повышения релевантности дообучают эмбеддеры на данных о кликах и релевантности из логов поиска, используют ContrastiveLoss. 9. Объединение результатов полнотекстового и векторного поиска Проблема была в разных шкалах: BM25 для полнотекста и косинусная близость для эмбеддингов. В качестве решения пробовали разные схемы: нормировка BM25, трафаретные схемы, обучение Catboost-ранжировщика на обоих факторах (это показало лучшие результаты). 10. Масштабирование и ограничения Гибридный поиск хорошо работает для коротких документов и длинных запросов, снижает число пустых выдач. Для больших документов требуется деление на чанки, поиск идеального решения пока в процессе. Гибридный подход улучшил метрики, но требует сложной архитектуры и постоянных экспериментов. В качестве вывода можно отметить, что гибридный поиск на базе OpenSearch и Qdrant позволяет повысить полноту и качество поиска, но требует глубокого понимания архитектуры, постоянной оптимизации и доработки моделей ранжирования. P.S. Я уже расскаывал про интересный обзор возможностей векторных баз данных, что был в докладе на goto конференции 2024 года "A Fun & Absurd Introduction to Vector Databases - Alexander Chatzizacharias". Этот рассказ хорошо дополняет рассказ Егора. #Architecture #Software #Engineering #ML #AI #DistributedSystems #SystemDesign

ArchDays 2025 - CFP (Рубрика #Architecture) Этой осенью пройдет уже 7 ежегодная конференция ArchDays по software architecture. Я в программном комитете этой конференции с момента ее появления, поэтому не могу не поделиться стартом CFP (call for paper). Если вы хотите выступить на конференции и рассказать доклад об одной из тем: процессы проектирования, практики, инструменты, обучение архитектуре или про собственную разработку, то you are welcome. В этом году, как и в прошлом у нас упор на практику - можно подать заявку на проведение арх каты, порешать арх кейсы или подискутировать насчет разных концепций архитектуры. В общем, если планируете стать спикером, то вам сюда. А если вы планируете прийти послушать, то уже можно покупать билеты:) P.S. Я выступал на всех предыдущих конференциях ArchDays, что были до этого с разными докладами на тему архитектуры. По ним даже можно отследить как менялась архитектурная повестка у нас в компании:) 1) "Эволюция web’а tinkoff.ru за последние 3 года" в 2019 (youtube) 2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" в 2020 (youtube, статья с расшифровкой) 3) "System Design Interview как проверка навыков проектирования систем на собеседованиях" в 2021 (youtube, статья с расшифровкой) 4) "Как подготовиться и пройти System Design Interview" в 2022 (youtube, статья с расшифровкой) 5) "Публичное интервью по System Design про бронирование отелей" в 2022 (youtube, статья с расшифровкой) 6) "Публичное интервью по System Design про простую a/b платформу" в 2023 (youtube) 7) "Архитектура в Т-Банке: вчера, сегодня, завтра" в 2024 (youtube, статья с расшифровкой) #SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

[2/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика #Engineering) Продолжая рассказ о книге, расскажу про ключевые принципы ATDD, изложенные в ней 1. Коллаборативная спецификация требований. ATDD базируется на совместной работе бизнес-заказчиков, разработчиков и тестировщиков для формулирования тестируемых требований. Цикл состоит из четырех стадий: - Discuss - обсуждение пользовательских историй - Distill - выделение критериев приемки - Develop - разработка - Demo - демонстрация прототипа Этот подход гарантирует, что все члены команды имеют одинаковое понимание целей. 2. Примеры как основа коммуникации. В ATDD команда использует конкретные примеры для описания поведения системы вместо абстрактных требований. Эти примеры служат живой документацией и должны быть написаны на языке бизнеса, понятном всем участникам процесса. 3. Автоматизация как буквальная интерпретация. Приемочные тесты должны автоматизироваться таким образом, чтобы они буквально отражали описанные примеры. Это означает, что автоматизированные тесты становятся исполняемой документацией, которая всегда актуальна и может служить регрессионным тестированием. 4. Тестирование до написания кода. Подобно TDD, в ATDD тесты создаются до написания продуктивного кода. Это помогает фокусироваться на том, что действительно нужно пользователю, и избегать оверинжиниринга. 5. Формат Given-When-Then. Для описания сценариев часто используется формат Gherkin с конструкциями Given-When-Then. Given описывает начальные условия, When — действия пользователя, Then — ожидаемые результаты. Этот формат делает тесты читаемыми как для технических, так и для нетехнических участников команды. 6. Фокус на бизнес-ценности. В отличие от unit-тестов, приемочные тесты проверяют функциональность с точки зрения пользователя и бизнес-ценности. Они отвечают на вопрос "работает ли система так, как ожидает заказчик", а не "работает ли конкретный метод правильно". 7. Интеграция с процессом разработки. ATDD не заменяет другие практики тестирования, а дополняет их. Он прекрасно сочетается с TDD на уровне модульных тестов, создавая многоуровневую систему обеспечения качества. 8. Постоянная обратная связь. Автоматизированные приемочные тесты обеспечивают постоянную обратную связь о состоянии системы. 9. Чистота и поддерживаемость тестов. Приемочные тесты должны быть написаны чисто и поддерживаемо. Они являются долгосрочными активами проекта и требуют такого же внимания к качеству кода, как и продакшен код. Рефакторинг тестов — неотъемлемая часть процесса. 10. Демонстрация как валидация. Финальная стадия цикла ATDD — демонстрация работающей функциональности заинтересованным сторонам. Это не только показывает результат, но и позволяет получить обратную связь для дальнейших итераций. Демо служит точкой валидации того, что построено именно то, что требовалось. В итоге, книга ок с точки зрения базы, но требуется обновление в части - Использования LLM для генерации тестов (подробнее в "Acceptance Test Generation with Large Language Models: An Industrial Case Study") - Использовании актуального стека (например, Playwright или Cypress). - Интеграции в процессы CI/CD P.S. Книга отправляется в booksharing уголок, что расположен в нашем московском офисе на 7 этаже (надеюсь, что она найдет себе новых читателей). #QA #DevOps #Process #Software #Engineering #AI

[1/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика #Engineering) Перечитал эту книгу Маркуса Гэртнера десятилетней давности про подходы к разработке через приемочные тесты. В те времена я как раз познакомился с BDD (behavioral driven development). а точнее с Cucumber, а дальше почитал про ATDD. Сейчас книга все еще актуальна на уровне концепций, но ручную работу по составлению приемочных тестов грозятся забрать на себя LLM модели, смотри например whitepaper "Acceptance Test Generation with Large Language Models: An Industrial Case Study" от апреля 2025 года, где предлагается двухшаговый подход

(i) generating acceptance test scenarios in natural language (in Gherkin) from user stories, and (ii) converting these scenarios into executable test scripts (in Cypress), knowing the HTML code of the pages under test

Если говорить про саму книгу, то это практическое руководство начального уровня по внедрению и успешному применению методики ATDD. Основная цель работы — показать, как заказчики, разработчики и qa-инженеры могут совместно создавать тестируемые требования, что позволяет создавать высококачественный софт в сжатые сроки. Автор демонстрирует фундаментальные принципы ATDD через два сквозных кейса: систему для оплаты парковки, а также систему для управления светофорами. А дальше он описывает основные принципы ATDD, а также рассказывает как его внедрить в организациях. В первом кейса для автоматизации используются Ruby, Cucumber и Selenium, во второй части примеры реализованы на Java с использованием FitNesse. Каждый кейс сопровождается обширным набором артефактов, включая классы автоматизации тестирования, определения шагов и полные реализации. Подробнее про содержание книги в следующем посте. #QA #DevOps #Process #Software #Engineering #AI