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

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

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

Незавершенные дела заставляют нас страдать. Мы возвращаемся к ним снова и снова, мысленно создавая бесконечный цикл упреков к себе, сожалений и оправданий. А еще брошенные проекты нередко создают сложности окружающим.

О том, чем вызван этот массовый недуг и как с ним справиться, поговорим в этом посте.

Привет, Хабр! Меня зовут Александр Кувакин, я backend-инженер в команде Engineering Excellence в Авито. В этой статье разберём, как backend-разработчикам выстраивать систему тестов на бэкенде и разберём основные проблемы. Речь пойдет прежде всего о тестах, которые проверяют бизнес-логику.

Меня зовут Анатолий Бобунов, я работаю SDET в компании EXANTE. Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения - без переписывания тестов с нуля. В статье расскажу, какие проблемы у нас возникли и как мы их решали.

Привет! Меня зовут Фёдор Засечкин. С 2023 года я руковожу группой разработки операционной платформы в Купере. Наша команда отвечает за стабильность и развитие сервисов, которые обеспечивают сборку и доставку заказов, а также найм и выход партнёров в смены.

Последние два года наша ключевая задача — микросервисная трансформация. Мы постепенно распиливаем монолит, перераспределяя нагрузку по сервисам. На сегодня более 1 000 RPS HTTP-трафика уже ушло с монолита; до полного завершения осталось около 30 RPS и часть межсервисных интеграций.

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

Асинхронность — слово, от которого у разработчиков дергается глаз и теплеет сердце. Корутины, горутины, event loop, трэдпулы — за этими терминами скрывается целая философия, меняющая взгляд на то, как писать высоконагруженные системы.

Привет, Хабр! Меня зовут Дмитрий Буров, я Golang-разработчик, автор Telegram-канала Go Advocate, а также лидер Go-сообщества в Lamoda Tech. В IT свитчнулся из военного дирижера. В коммерческой  разработке — более 10 лет, начинал как фуллстек-разработчик на стеке JS, PHP, CSS, а последние шесть пишу только на Go. В этой статье по мотивам моего доклада для GolangConf расскажу про асинхронность и её роль в современных высоконагруженных системах. Разберём исторический аспект, концепцию и реализацию корутин в разных языках, эволюцию асинхронных подходов, сравним корутины и горутины, выясним, зачем Go добавил в рантайм пакет coro и чем это может обернуться.

Как выглядят паттерны DDD (Domain Driven Design) в большом проекте? А самое главное, стоит ли их вообще использовать? Рассмотрим, какими инструментами можно реализовать DDD на Go и оценим, насколько это больно.

Меня зовут Илья Сергунин, я backend-сочинитель в Авито: занимаюсь тем, что передаю смартфоны в хорошие руки. В этой статье попытаюсь объяснить, как можно натянуть DDD на Go без синтаксического сахара и магии Java-подобных языков, и без больших крутых ORM c Data mapper, которые также отсутствуют в Go.

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

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

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

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

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

В этой статье мы сделаем небольшой экскурс в эволюцию архитектурных подходов – от классического шаблона MVC, популярного на начальных стадиях разработки, до более современных решений, таких как SOA, DDD, Modular Monolith и микросервисы.

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

Привет! Я Андрей Леонтьев, тимлид разработки в вертикали Авито Товары. В этой статье рассказываю, зачем тимлиду осознанно прокачивать visibility — управляемую «видимость» инженеров — и как это напрямую влияет на калибровки, промо и скорость получения ресурсов. Покажу, куда «светить фонариком», как выровнять систему ценностей и подбирать инструменты под мотиваторы. Материал пригодится тимлидам, техническим лидерам, PM/PO и инженерам.

В этой статье я расскажу об основах внедрения зависимостей (англ. Dependency Injection, DI) простым языком, а также расскажу о причинах использования этого подхода. Эта статья предназначена для тех, кто не знает, что такое внедрение зависимостей, или сомневается в необходимости использования этого приёма. Итак, начнём.

Привет, Хабр!

Protobuf, или Protocol Buffers, это бинарный формат сериализации, разработанный в Google для эффективного обмена данными между сервисами. Это как JSON, только компактнее, быстрее и типизированнее. Если JSON был вашим первым крашем в мире сериализации, то Protobuf – это тот, с кем вы хотите серьёзных отношений.

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

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

Разобрался на собственных фейлах — делюсь, как перестать саботировать себя и свой код.

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

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

Формат Use Case помогает избежать этих проблем. Он описывает сценарии взаимодействия пользователей и систем в четкой, последовательной форме. Это не просто техническая документация, а «инструкция» для всех участников проекта: аналитиков, разработчиков, тестировщиков и бизнес-пользователей.

Автор: Борис Абрамов, lead system analyst

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

Примерно 5 годами ранее появления FastAPI была обнародована идеология построения легковесных микросервисов на Django, которая стала актуальной только после внедрения асинхронности в этом фреймворке.

Хотя в последней (на момент написания статьи) версии Django 5.0.5 асинхронно решается только часть задач, но уже сейчас можно начать создавать асинхронные микросервисы воспользовавшись технологией µDjango.

Привет, Хабр! Меня зовут Ильяс. Мы с командой делаем собственный Service Mesh в Ozon Tech, и в этой статье я расскажу, как можно за вечер реализовать свое супер кастомное межсервисное взаимодействие. К концу статьи мы с вами напишем современные алгоритмы балансировки, настроим канареечные деплои, а также узнаем, как реализовать кучу других супернеобычных механизмов межсервисного взаимодействия на основе, не поверите, библиотеки gRPC :D И да, мы с моей командой уже раскатили это на весь Ozon Tech, состоящий из более чем 4500 сервисов. Пристегнитесь — мы начинаем… :-)

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.