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

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

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

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

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

Я собрал минимальный набор практик, без которых микросервис очень быстро превращается в «чёрный ящик»: логи, трассировка, метрики, конфигурация, feature flags, тестирование и чуть-чуть документации. Это не теория — это вещи, которые я выстрадал, пока делал Go-шаблон для коллег, переходящих после Ruby/PHP, и пытался сделать так, чтобы сервис было реально удобно запускать, отлаживать и поддерживать.

Внутри — простые объяснения, почему эти штуки окупаются, и примеры на Go: как разделить логи и связать их с trace_id, как руками добавить span, какие метрики имеет смысл считать, как организовать конфиг, зачем OpenFeature, почему testcontainers — это не боль, и почему Makefile иногда экономит больше времени, чем очередной «идеальный рефакторинг».

Публикуем новый полный перевод хрестоматийной статьи Эдсгера Дейкстры. Этот текст, опубликованный в 1968 году в журнале Communications of the ACM в формате письма в редакцию, заложил основы структурного программирования, впервые строго аргументировав отказ от оператора go to в пользу использования циклов и условных конструкций.

Наверное, каждый программист, работавший с объектно-ориентированными языками, хотя бы раз слышал о законе Деметры. Многие знают его смысл, но мало кто читал оригинальный текст 1989 года, где закон был не только сформулирован, но и подробно обоснован. В этой статье авторы, Карл Либерхер и Иэн Холланд, рассказывают о проекте «Деметра», дают строгие формулировки для разных языков и обсуждают, когда законом можно пренебречь.

Мы в Ситидрайве строим микросервисную архитектуру. Сегодня у нас 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 пайплайн ?
Ответы на эти вопросы под катом. Будет полезно, погнали.

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