Чем популярнее становится FastAPI, тем сильнее критикуют Django. И не просто критикуют. Брезгуют? Пренебрегают? Всего понемножку. Всё чаще слышу, что Django — пережиток прошлого. Любой проект на Django — устаревший мусор. Любой «джанговод» — просто не знает, что тоже устарел. Объективно ли это? Нет, не объективно. Если отвёртка плохо забивает гвозди, это не значит, что отвёртки устарели — просто это не их задача.
Статья является продолжением Пишем агента на Kotlin: KOSMOS, но может читаться независимо. Мотивация к написанию — сохранить читателю время на возьню с фреймворками для решения относительно простой задачи.
Автор подразумевает у читателя теоретическое понимание того, что такое агент. Иначе лучше прочесть хотя бы начало предыдущей части.
В статье хочу показать, как самостоятельно написать аналог Koog или Langchain4j. У вас не будет всех их фичей, зато будет очень простая и расширяемая система.
Статья Парнаса «О критериях...» давно стала классикой, на которую постоянно ссылаются, но мало кто ее реально читает. Высказанные в ней идеи о «сокрытии информации» как основе модульности упоминаются повсеместно, однако оригинальный текст с его тщательной аргументацией и яркими примерами остается для многих терра инкогнита. Данный перевод призван восполнить этот пробел.
В первой части мы озвучили следующие тезисы:
- автотесты нужны не для экономии на тестировщиков, а чтобы сократить до минимума циклы разработки и узнавать об ошибках практически мгновенно;
- покрытие обязано быть абсолютным - должно быть протестировано буквально все, что возможно протестировать: функционал, нагрузку, интерфейс, безопасность, миграции и т.п.;
- тесты ломают разработчики, поэтому им за них отвечать - все виды тестов должны писать и поддерживать разработчики;
- с полным автоматическим регрессом можно и нужно ставиться в прод после каждого изменения в кодовой базе;
- главный шаблон поставки в прод изменений - конвейер развертывания (Deployment Pipeline);
- конвейер делится на 2 главные фазы: commit stage и acceptance stage;
- первая фаза - быстрые тесты (до 5 минут), чтобы быстро узнать, что ветка сломана и её надо скорее чинить;
- вторая фаза - приёмочные тесты (до 1 часа), чтобы узнать, можно ли ставить в прод изменения.
Про быстрые тесты мы поговорили во второй части. Пришло время поговорить про короля автотестов - приёмочное тестирование.
Последние 4 года я занимаюсь реализациейпроектов на PHP по DDD, используя слоистую архитектуру. Каждый раз я сталкиваюсь с одной из самых насущных проблем DDD: определение границ агрегата. Ведя разработку «как удобно», очень легко не заметить, как вся бизнес логика сосредоточилась в один «божий класс».
В этой статье я поделюсь своим опытом, как проектировать и разрабатывать по DDD, не скатываясь в «один агрегат, чтобы править всеми». Поговорю о проблемах определения границ агрегата и цены чтения, гидрации и содержания больших объектов в памяти PHP процесса.
Приветствую всех! С вами старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой System Analyst. Статья основана на практическом опыте, в нашей школе мы не просто даем теорию, а любим делиться тем, что действительно работает на проектах.
Разбор legacy-системы без документации кажется сложной задачей. Но это возможно с правильным подходом и современными инструментами. Это руководство даст вам план действий, практические методы и покажет, как использовать ИИ для ускорения работы.
Около года назад я написал первую часть статьи о Single SPA — о том, как я выбирал архитектурный подход, боролся с монолитом и пробовал собрать первые микрофронтенды. В статье были разобраны базовые принципы работы Single SPA, подключение importmap, сравнение с другими архитектурными решениями и настройка сборки на Webpack и Vite.
Эта статья — продолжение цикла. Здесь я поделюсь практикой: как на самом деле живётся с Single SPA, какие есть подводные камни и что можно вынести в виде рекомендаций.
Сразу скажу: Single SPA — не «серебряная пуля» и уж точно не современный тренд фронтенд-разработки. В 2025-м появилось еще больше других подходов, которые решают похожие задачи иначе. Но Single SPA всё ещё актуален там, где есть огромные легаси-системы, которые невозможно переписать с нуля. И вот именно для таких кейсов мой опыт может быть полезен.
В первой части мы разобрали верхнеуровневую теорию автотестирования: сколько каких тестов нужно, кто должен их писать, и для чего это все. В этой части мы уже подойдем к практическим вопросам: разберёмся в том, что в первой части я назвал быстрыми тестами, то есть с тем, что обычно понимают под "юнит-тестами".
Из всех видов автотестирования этот самый популярный. Но даже несмотря на это, половина разработчиков юнит-тесты не пишет и не умеет писать вовсе, а вторая половина пишет так, что лучше б и не писала. Либо чисто ради покрытия, либо просто от балды, как сердце подскажет.
При этом, как и все модные практики в айти, юнит-тестирование - это инструмент, который используют просто потому что так надо, хотя он предназначен для решения вполне конкретных проблем. То есть, очевидно, есть проблемы, которые юнит-тесты решить не могут.
Отсюда сформулируем главные вопросы, на которые мы ответим в этой статье:
- Нужно ли вам писать юнит тесты под ваши задачи? Или лучше выбрать другой тип тестирования и ограничиться только им?
- Если все же да, то как тогда писать юнит-тесты? Какие есть подходы, и какой лучше выбрать?
Короче, всё как обычно: как и нафига?
Статья о реализации сервиса на C++ с применением TDD, DDD и событийно-ориентированной архитектуры. Проект переносит идеи из книги «Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура» на C++.
Костыль как архитектурная стратегия. Почему лучший способ улучшить сложную систему — не ломать её, а строить новые модули рядом. Примеры из IT, градостроения и биологии.
Статья о том, какие бывают ограничения самописных планировщиков задач и как мы перевели весь процесс планирования в NiFi, сделав его более прозрачным.
Привет, Хабр! Меня зовут Дарья Борисова, я системный аналитик в ПСБ.
Однажды я попробовала интеграции... и теперь они преследуют меня везде, как навязчивый мотив из песни.
Пришлось изучать и внедрять разные подходы, а заодно накопить вагон и маленькую тележку лайфхаков. Сегодня я работаю с Системой быстрых платежей в ПСБ — и готова поделиться тем, что спасло нас в критичных ситуациях.
Почти наверняка вы бывали в ситуациях, когда всё выпустили в прод, а сервер нагрузку не тянет. Или бизнес давит сроками, а времени на идеальные решения нет. Приходится подставлять костыли и ставить быстрые заплатки. Вопрос в том, могут ли они стать надежным решением? И какие компромиссы придется принять — об этом и поговорим.
А точнее: об оптимизации REST API в бою: как снизить количество запросов без потери данных, где проводить расчеты (и чем это грозит), зачем стандартизировать ответы, как кешировать с умом и почему health-check — это не просто «жив/мертв».
Архитектура — основа любого IT-продукта. Для ее создания нужно видеть систему целиком, понимать требования бизнеса и учитывать бюджет. Но вот проблема: научиться думать как архитектор непросто. Нужно держать в голове десятки взаимосвязей и находить решения, которые будут жить годами.
Меня зовут Арина Николаева, я занимаюсь развитием архитектурного сообщества в MWS. Вместе с коллегами мы придумали Arch Kata — игру, которая позволяет попробовать свои силы: участники должны решить сложный бизнес-кейс, а наши эксперты оценят проект и объяснят, что в нем хорошо или не очень.
Сегодня расскажу, откуда взялась Arch Kata, чем она отличается от привычного хакатона, как проходит и почему в ней стоит участвовать не только архитекторам, но и разработчикам, аналитикам и менеджерам. А в конце покажу пример, который мы давали участникам последней игры.
Создавайте приложения так, чтобы они могли работать без пользовательского интерфейса или базы данных. Это позволит запускать автоматизированные регрессионные тесты, продолжать работу при недоступности базы данных, а также связывать приложения друг с другом без какого-либо участия пользователя.
Я в бешенстве. Я реально зол. Зол настолько, что хочется сносить чужие песочные замки, зарядить Дэниэлю ЛаРуссо по физиономии и поливать его грязью перед его девушкойa.
Вообще-то я не из тех, кого легко разозлить, но ситуация в индустрии достала окончательно.
В данной статье я хочу рассказать про процесс разработки относительного простого модуля для ПЛИС (FPGA), а именно – контроллера (мастера) шины I2C. Он является ведущим устройством на шине. Я постараюсь показать последовательность всех этапов работ: проектирование, написание кода, моделирование и отладка в «железе».
Статья в первую очередь ориентирована на тех, кто только начинает своё знакомство с ПЛИС. Надеюсь, она будет им полезна. Возможно и опытные разработчики смогут найти что-то новое для себя, увидеть интересные им идеи.
В статье приводится большое количество исходных кодов контроллера (на языке VHDL) с их подробным разбором.
Иногда запрос на слияние (merge request) даже не стоит отправлять на код‑ревью, так как при его составлении кто‑то злоупотреблял искусственным интеллектом, и это повредило как проекту, так и команде. Например:
1. Удалив часть кода, можно значительно улучшить запрос на слияние.
2. Вы не знаете основ языка, на котором подавали запрос.
3. Спам в документации.
4. Вопиющая несогласованность материала.
5. Чрезмерно подробно рассмотрены пограничные случаи.
6. Вы добавили бессмысленные или нежелательные зависимости и сами не понимаете, зачем.
Если я прислал вам обратно ваш запрос на слияние с невычищенным ИИ и без всяких прочих комментариев — значит, какие‑то из этих пунктов вы выполнили.
Несмотря на свежие исследования и дискуссии на эту тему, мне известно, что ИИ действительно помогает писать код. Но злоупотребление ИИ — это новый феномен, и нам нужно чем‑то руководствоваться, чтобы выявлять такие случаи. Оригинал этой статьи написан в 2025 году, надеюсь, со временем улучшится ситуация как с инструментами, так и с регламентацией.
Этап «Проектирование информационных систем» (ИС) — один из ключевых в жизненном цикле разработки ИС, так как он определяет, какой будет система, как она будет устроена и как будет реализовывать требования пользователей, какие будут накладываться ограничения и прочее.
Привет, Хабр! Меня зовут Владимир Добрынин, я ведущий разработчик в МТС Web Services. Наша команда занимается плагинами DevTools, которые упрощают и ускоряют создание софта, в том числе за счет сокращения рутинных операций.
У нас уже есть целое семейство внутренних инструментов. Один из них — DevTools Copilot, который непосредственно из среды разработки позволяет взаимодействовать с LLM в режиме чата. А теперь мы реализовали DevTools Code Review, который помогает проводить самостоятельное код-ревью. В этой статье расскажу, как работает плагин и чего мы с его помощью добились.
Недавно я прочёл книгу «Паттерны разработки на Python TDD, DDD и событийно-ориентированная архитектура». Основной акцент в ней сделан на том, как именно нужно структурировать программы, чтобы они по мере роста оставались простыми и удобными в поддержке. Это моя любимая тема из области программирования, поэтому, конечно же, книга мне понравилась. Пожалуй, я не возьмусь использовать именно те приёмы, которые авторы рекомендуют в книге — но они обсуждают классные идеи, напомнившие мне о задачах, встречавшихся в моей практике на предыдущих работах. Кроме того, отмечу, что английская версия книги есть в свободном доступе онлайн, так какие вообще вопросы?
В книге рассматривается предметно-ориентированное проектирование и событийно-ориентированная архитектура (в основу которой удобно закладывать микросервисы, но это не обязательно). В этом посте я немного раскрою наиболее понравившиеся мне идеи из книги, но, прежде, чем переходить к этому, хочу артикулировать некоторые детали:
