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

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя.

А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

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

На основе личного опыта, обсуждений на конференциях и историй крупных компаний можно утверждать, что задачи меняются, технологии обновляются, но поведение команд и лидеров остается удивительно стабильным: предубеждения (bias) все так же заставляют нас наращивать усилия там, где правильнее было бы остановиться.

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

Привет, Хаброжители! Овладейте искусством дизайна архитектур и станьте успешным архитектором решений. Книга, написанная опытными техлидами AWS Саурабхом Шриваставой и Ниланджали Шривастав, выходит за рамки традиционных руководств для подготовки к сертификации. В ней вы найдете подробную аналитику и описания передовых методов, предназначенных для удовлетворения конкретных потребностей клиентов и решения проблем, с которыми сталкиваются современные архитекторы решений.

При разработке сложной системы приходится сталкиваться с использованием nginx в качестве reverse proxy: роутинг, список правил, регулирующих путь запроса во внутренние системы или между подсистемами.
Быстро развивающиеся сервисы обрастают правилами, назначение которых не очевидно или имеет недокументированные особенности. Проверенный способ рефакторинга таких систем: зафиксировать и вылечить упростить. Фиксировать будем тестами.

Как проверить корректность вашей конфигурации Nginx'а? Как проверить ее безопасность и нет ли уязвимостей ? Какие есть для этого варианты, их плюсы, минусы, практическая применимость и как эти проверки встроить в CI пайплайн ?
Ответы на эти вопросы под катом. Будет полезно, погнали.

Это начинается незаметно. Сначала — просто «временное решение». Потом — «сделаем рефакторинг». Но «потом» не наступает никогда. Мы называем это техническим долгом, словно он когда-то будет погашен, но прекрасно знаем — чаще всего это просто красивое описание хаоса. 

Меня зовут Алекс Гусев. Я продолжаю публикацию заметок о своём персональном опыте использования агента Codex от OpenAI для разработки веб-приложений. В этой статье я расскажу о своих выводах относительно организации каталогов верхнего уровня в проектах, разрабатываемых в паре с ИИ-агентами.

Посмотреть результат применения излагаемого подхода можно в проекте "flancer64/pwa-home-call".

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

Когнитивная сложность при проектировании приложения часто возникает из‑за смешения архитектуры кода и архитектуры приложения. В большинстве случаев эти термина никак не разделены, а также эти термины не имеют однозначного толкования, как по содержанию так и по контексту использования. В практике и литературе эти понятия часто используются как синонимы или в пересекающихся контекстах, что приводит к неоднозначности. В зависимости от контекста (например, обсуждение микросервисов, монолитов, паттернов проектирования или рефакторинга), один и тот же термин может обозначать как уровень организации кода, так и более высокий уровень организации приложения или системы. В профессиональной литературе и стандартах (например, TOGAF, ArchiMate) архитектура программного обеспечения охватывает оба аспекта и организацию кода, и организацию приложения, что еще больше стирает границы между этими понятиями.

Пора этой порочной практике сказать решительное НЕТ!

Микросервисная архитектура уже давно стала нормой для IT-продуктов. И одну из центральных ролей в таком подходе занимает API Gateway.

В этой статье разберём, что такое API Gateway, зачем он нужен в микросервисной архитектуре, какие 10 ключевых функций он выполняет, и является ли он потенциальной точкой отказа в системе.

Внутри вы найдёте много картинок и примеров схем архитектуры, чтобы объяснения были максимально понятными.

Материал будет полезен системным аналитикам, начинающим архитекторам, разработчикам и тестировщикам, особенно при подготовке к собеседованиям в продуктовые компании.

Оглавление:
Что такое API Gateway
10 главных функций API Gateway
Виды API Gateway
API Gateway - центральная точка отказа
Примеры схем архитектуры с API Gateway в нотации C4 (и не только)
Заключение и полезные ссылки

Из первых уст рассказываю как переход на Temporal обеспечил надежную доставку клиентских услуг в контексте обычного хостинга.

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

Если бы меня 5 лет назад об этом спросили, я бы уверенно сказал, что не сможет. Но сейчас я уже сомневаюсь в этом.

Я уже 26 лет работаю в сфере ИТ и за это время написал немало кода. Месяц назад решил проверить, насколько действительно эффективен искусственный интеллект, и попробовать создать с его помощью сайт. И я его создал — точнее, создал его не я, а он. Вот результат: https://windowrepino.ru/. Я лишь ревьюил код и делал рефакторинг.

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

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

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

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

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

Все разработчики знают, что такое техдолг.

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

Предлагаю разобраться, что же это такое, откуда берется и что с этим всем можно делать.

Почему одни команды релизят предсказуемо и без героизма, а другие тушат пожары на продакшене каждую неделю?

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

Исследование 100+ респондентов.

Когда начинал разработку системы многомерного анализа данных временных рядов Dimension-UI, для внедрения зависимостей в исходном коде решил использовать Dagger 2. Практический опыт показал, что для приложений с большим количеством динамически создаваемых объектов инверсия зависимостей, реализованная в Dagger 2, не подходит.

Да, создание графа зависимостей в compile-time — это, во-первых, очень быстро, и, во-вторых, удобно: получаешь сообщения об ошибках конфигурации уже при компиляции.

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

Чтобы реализовать scope-зависимости, приходится писать и поддерживать много инфраструктурного кода внутри объектов, куда мы внедряем зависимости. В Dagger 2 такая реализация, во-первых, «загрязняет» код, а во-вторых, серьезно осложняет тестирование. Изолировать методы удобным способом не получается: в тестах нужно писать очень много кода, чтобы прокинуть необходимый контекст и корректно мокировать внешние зависимости. Я туда просто не полез — покрывал unit- и UI-тестами только базовую функциональность, где были Singleton-зависимости.

Даже с одними Singleton’ами приходится поднимать отдельную тестовую инфраструктуру для запуска приложения в тестовом режиме. Это не просто неудобно — это очень затратно по времени. Если сравнить усилия, которые надо потратить на реализацию тестирования подобного функционала в Spring и Dagger… Сравнение будет не в пользу Dagger. В целом я начал думать о переходе на runtime-генерацию графа зависимостей.

Mobile System Design — один из ключевых навыков мобильного инженера.

Именно он часто определяет уровень зрелости: в реальной работе, на собеседованиях и в матрицах компетенций компаний.

Но вокруг этой темы полно разночтений и разных трактовок — отсюда споры, путаница и хаос.

В этой статье я систематизирую Mobile System Design как дисциплину: покажу, какие навыки действительно важны и как они проверяются. Это не личное мнение, а выжимка из опыта инженеров, требований собеседований, литературы и практики команд.

Чем популярнее становится FastAPI, тем сильнее критикуют Django. И не просто критикуют. Брезгуют? Пренебрегают? Всего понемножку. Всё чаще слышу, что Django — пережиток прошлого. Любой проект на Django — устаревший мусор. Любой «джанговод» — просто не знает, что тоже устарел. Объективно ли это? Нет, не объективно. Если отвёртка плохо забивает гвозди, это не значит, что отвёртки устарели — просто это не их задача.

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

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

В статье хочу показать, как самостоятельно написать аналог Koog или Langchain4j. У вас не будет всех их фичей, зато будет очень простая и расширяемая система.

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

В первой части мы озвучили следующие тезисы:

- автотесты нужны не для экономии на тестировщиков, а чтобы сократить до минимума циклы разработки и узнавать об ошибках практически мгновенно;

- покрытие обязано быть абсолютным - должно быть протестировано буквально все, что возможно протестировать: функционал, нагрузку, интерфейс, безопасность, миграции и т.п.;

- тесты ломают разработчики, поэтому им за них отвечать - все виды тестов должны писать и поддерживать разработчики;

- с полным автоматическим регрессом можно и нужно ставиться в прод после каждого изменения в кодовой базе;

- главный шаблон поставки в прод изменений - конвейер развертывания (Deployment Pipeline);

- конвейер делится на 2 главные фазы: commit stage и acceptance stage;

- первая фаза - быстрые тесты (до 5 минут), чтобы быстро узнать, что ветка сломана и её надо скорее чинить;

- вторая фаза - приёмочные тесты (до 1 часа), чтобы узнать, можно ли ставить в прод изменения.

Про быстрые тесты мы поговорили во второй части. Пришло время поговорить про короля автотестов - приёмочное тестирование.

Последние 4 года я занимаюсь реализациейпроектов на PHP по DDD, используя слоистую архитектуру. Каждый раз я сталкиваюсь с одной из самых насущных проблем DDD: определение границ агрегата. Ведя разработку «как удобно», очень легко не заметить, как вся бизнес логика сосредоточилась в один «божий класс».

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