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

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

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

Агенты 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-генерацию графа зависимостей.