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

Мы в Ситидрайве строим микросервисную архитектуру. Сегодня у нас 200+ сервисов, за которыми стоят свыше 20 автономных команд — всего больше 150 инженеров. Казалось бы, идеальная модель: каждая команда быстро выкатывает свои фичи без лишней бюрократии. Но была и обратная сторона — нет единого понимания, какие сервисы действительно критичны, как они связаны друг с другом и куда развивать систему дальше.

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

Здравствуйте, меня зовут Дмитрий Карловский и я.. да не важно кто я. Важно о чём я говорю, и как аргументирую.

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

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

Статья поможет разработчикам и архитекторам осознанно применять паттерн Буфер для создания производительных и устойчивых решений.

Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.

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

Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО.

А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад.

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

Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!

Невероятно!

Но я забегаю вперёд…

Меня зовут Миша, я бэкенд‑разработчик в платформе Яндекс Еды, и в этой статье я расскажу о принципах работы Temporal: почему мы его выбрали как основу нового процессинга, в чём его сильные стороны и как изменилась наша жизнь после перехода. 

Раньше для такого требовались: стейт‑машина с полудюжиной состояний, очереди и воркеры, обработчики на каждое событие и блокировки от race conditions. Теперь всё это описано в одной функции, которая вообще выглядит как псевдокод. 

Магия? Нет, Temporal. 

С тех пор как мы перенесли процессинг на Temporal, разработка существенно упростилась. Пользователь оплачивает заказ, ресторан его подтверждает и готовит, курьер забирает и привозит — ровно это и отражено в коде. Ну разве не прелесть?

Контроль импеданса - это основа проектирования современных высокоскоростных цифровых и высокочастотных аналоговых схем.

1. Что такое контроль импеданса?

Контроль импеданса (ImpedanceControl) – это совокупность мер при проектировании и производстве печатных плат (ПП), направленных на то, чтобы волновое сопротивление (импеданс) проводников на печатной плате имело строго заданное значение.

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

Зачем это нужно?

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона.  Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день.

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

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

Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу?

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

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

Но почему важно иметь точное понимание, что такое операционный процесс и что такое процесс управления?

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

Несмотря на то, что книга «Чистый код» привнесла в наш лексикон прекрасный термин, она также снискала и дурную славу. Это руководство от 2008 года представляет собой сборник принципов и исследований, которые «дядя Боб» (Uncle Bob, то есть Роберт Мартин) выработал за годы программирования.

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

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

Можно подумать...

Как можно Cursor IDE превратить в полноценную мультиагентную среду разработки, где каждый AI‑агент выполняет роль члена команды: аналитика, архитектора, планировщика или разработчика?

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

Как добиться сходимости к стабильному результату в ходе длительной самостоятельной работы команды ИИ-агентов?

Рассказываю, как я пришёл к таким результатам с помощью команды агентов под управлением оркестратора и применения принципа разрабокти «сверху вниз», когда код рождается постепенно, но осмысленно: от общей идеи до рабочего решения.

На днях подходит ко мне коллега с вопросом: «Слушай, а как в Go сделать замену логики функции в тесте?»

Я уточняю, что он имеет в виду. А он такой: «Ну, хочу monkey patching, чтобы подменять функции из коробки. Типа time.Now возвращала фиксированное время, uuid.New конкретный ID. Чтобы удобно тестироваться».

И тут я, конечно, немного завис :D

Да, технически в Go есть способы делать monkey patching (еще и есть библиотека) через unsafe, через подмену указателей на функции в рантайме. Но это настолько хрупкое и непредсказуемое решение, что я бы не советовал тащить его в продакшен-код. Особенно когда есть нормальный, идиоматичный способ решить эту задачу.

У аббревиатуры 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 обеспечил надежную доставку клиентских услуг в контексте обычного хостинга.