Проектирование и рефакторинг *

Статья о том, какие бывают ограничения самописных планировщиков задач и как мы перевели весь процесс планирования в 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 и событийно-ориентированная архитектура». Основной акцент в ней сделан на том, как именно нужно структурировать программы, чтобы они по мере роста оставались простыми и удобными в поддержке. Это моя любимая тема из области программирования, поэтому, конечно же, книга мне понравилась. Пожалуй, я не возьмусь использовать именно те приёмы, которые авторы рекомендуют в книге — но они обсуждают классные идеи, напомнившие мне о задачах, встречавшихся в моей практике на предыдущих работах. Кроме того, отмечу, что английская версия книги есть в свободном доступе онлайн, так какие вообще вопросы?

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

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

Недавно принял участие в панельной дискуссии про микросервисы. Планировался холивар «монолит vs микросервисы», но получился, на мой взгдяд, интересный разговор с реальными кейсами. Собрались специалисты с интересным практическим опытом: Павел Куликовский (Цифра банк),Антон Мартынов (SimbirSoft), Алексей Захаров (Axiom JDK), Андрей Почтов (АЭРО) и Александр Тырышкин (DEVTALE).

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

Тестовое задание это результат работы её внутренних структур, культурных механизмов, ценностей и страхов, явно и неявно сформулированных в набор требований к новому идеальному сотруднику. Это её ДНК, упакованное в текст.

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

Привет, Хаброжители! Как стать экспертом в создании сложных и мощных приложений на Python, не тратя времени на повторение уже известных основ или перечисление ненужных функций? Аарон Максвелл фокусируется на первопринципах Python, которые действуют подобно катализаторам для всего остального: достаточно получить 5 % знаний в области программирования, чтобы остальные 95 % подтянулись автоматически.

Думай о секундах свысока - как бы говорит нам Modern C++.

Зачем нам использовать Modern C++, особенно старших версий? Дурацкий вопрос, скажут сектанты, фанаты, фанатики, адепты. Оно же необходимо для большей выразительности, читабельности и ускорения всех возможных процессов, включая метаболизм; и еще для экономии времени. Что-то в этом есть, а кое-чего нет. Давайте рассмотрим пример из жизни.

Один программист (имя сохранено в редакции) писал себе спокойно код и написал примерно такое (для справки: используемый стандарт 2017):

Привет, Хабр! Сегодня хочу поделиться с сообществом TG ботом, которого написал пару лет назад и который до сих пор актуален и работает.

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

Эта статья — не инструкция и не религиозная проповедь. Это разбор заблуждений. Причём речь пойдёт не только о критиках TDD, но и о его сторонниках.

TDD часто воспринимают как способ добиться максимального покрытия или как дисциплину «писать тесты вперёд». Но настоящая цель — не в тестах, а в итеративном проектировании поведения и архитектуры.

Если вам кажется, что TDD — это занудно, медленно, не подходит к реальному коду или убивает гибкость — возможно, вы всё делали правильно.
Но с совершенно другими целями.
Именно поэтому вам не понравилось.

Разберёмся, что такое TDD на самом деле — и почему вы, скорее всего, не знаете TDD.

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

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

В предыдущей статье мы выяснили как создать два класса (Хост и Енкодер, класс А и класс В) один из которых (А) не может работать без использования функций другого класса (В, а может, и без данных из этого класса В не может работать), но при этом совершенно не зависит от этого класса В! То есть класс А может запросто работать с любым другим классом (C, D, … ) вместо класса В, при некотором условии изложенном в предыдущей статье. По моему, та статья может быть хорошей разминкой для понимания концепции Внедрения Зависимостей. И, определенно, эта статья может считаться продолжением темы практической архитектуры ПО.

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

Я решил попробовать себя на новом амплуа писателя и писать о том, что мне интересно и чем я занимаюсь. Я постараюсь делать меньше воды и не слишком длинные посты, так как длинные посты читаются тяжело. И первый пост будет о yask

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

Решение принято: рефакторингу быть! Сразу скажу, приступать было страшно, но сейчас я очень доволен результатом. «Идеальную» структуру мы не получили, пришлось идти на компромиссы и заплатить свою цену, зато в новой структуре удалось вылечить все проблемы. Теперь в ней удобно ориентироваться и читать код, конфликты создаются очень редко, а все скрипты автоматически детектируются liquibase-ом. Но только это конец истории. А вначале было вообще непонятно, как рефакторить журнал изменений, да так, чтобы в существующие базы данных он смог пролиться, и ничего не поломал при этом!