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

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

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

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

Приятного чтения!

Причины:

Нет чёткой цели

Нет чётких задач, которые решает проект в процессе работы

Сильное погружение в проработку незначительных деталей

Отказ от поддержки минимально жизнеспособного продукта (тот самый случай, когда проработка функциональности бежит дальше, чем основной скелет продукта)

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

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

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

В общем, расскажу, как на практике распиливаются монолиты огромных размеров, которые управляют всем производственным циклом. А размеры ещё те: НЛМК — гигант. Мы делаем 20% стали России и входим в TOP-20 по производству в мире.

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

Привет, Хабр! В нашей практике разработчиков электронных устройств и встраиваемых систем мы часто сталкиваемся с необходимостью хранить параметры устройства. Это могут быть, например, такие параметры как яркость дисплея, язык, рабочая частота радиоканала или IP адрес – да что угодно. Единого общепринятого подхода для решения этой задачи нет, и я предлагаю обсудить ниже наиболее очевидные варианты, их достоинства и недостатки, а также предложить реализацию, к которой я пришел в результате работы над несколькими проектами. Поехали!

В субботу 13 ноября с 12.00 по Москве пройдет следующая сессия Сколковской школы синтеза цифровых схем, в режиме онлайн. По плану на ней должны были быть упражнения на FPGA плате с последовательностной логикой. Однако мы решили изменить план и переставить на эту дату занятие по архитектуре RISC-V. Это занятие было изначально запланировано 11 декабря. Занятие по последовательностной логике будет передвинуто на 20 ноября. Почему мы решили так сделать - см. обьяснение через три абзаца.

Занятие по RISC-V проведет проектировщик российского микропроцессорного ядра Никита Поляков из компании Syntacore. В Syntacore Никита перешел из компании МЦСТ где он проектировал процессор Эльбрус. 

Занятие будет состоять из лекции с одновременными упражнениями на симуляторе RARS. RARS моделирует процессор на уровне архитектуры (системы команд, видимых программисту), в отличие от симулятора Icarus Verilog, который мы обсуждали в предыдущей заметке и который моделирует на уровне регистровых передач / микроархитектуры (внутреннего устройства схемы процессора). Разработчику процессора нужно уметь пользоваться симуляторами обеих типов.

У RARS есть три кнопки - запустить, ассемблировать и выполнить шаг. В конце занятия вы будете уметь программировать на ассемблере, даже если раньше этого никогда не делали. В этой заметке мы расскажем, как установить симулятор и запустить простую программу на ассемблере. Потом в следующей заметке я напишу, что такого особенного есть в архитектуре RISC-V и почему мы выбрали для семинара именно ее, а не ARM, x86/64, MIPS, AVR, SPARC,  Эльбрус, Z80, 6502, PDP-11 или еще что-нибудь другое.

Возможно, вы сталкивались с классической историей: поговорили с заказчиком о задаче, всем всё понятно. Начали работать — и началось: "А я думал, это и так ясно" или "Я ожидал, что ты это опишешь точнее". 

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

Как с этим бороться?

Здесь рассматривается технология отладки платы контроллера резервного питания и его программного обеспечения . Используются: адаптер SWD, осциллограф, VT100 терминал через UART, движок FreeMaster, экспорт и анализ в MATLAB. Дан пример реализации регулируемого источника напряжения. Заключительный тюнинг платы.

Вопрос, который часто задают начинающие программисты — какой язык программирования изучать? Вопрос звучит разумно. Хочется выбрать самый лучший, чтобы потом не пришлось переучиваться.

Можно ли на него ответить?

Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.

Глава про архитектурные решения сильно нас зацепила, потому что в своей работе мы напрямую столкнулись с описанными в ней проблемами. 

Не можете найти концов, почему было принято то или иное решение? Рассказываете коллегам по сто раз одно и то же? Обсуждения в мессенджерах превращаются в срачи на десятки сообщений?

Знакомо? Нам тоже. Но мы смогли победить эти проблемы.

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

И снова здравствуйте!

Первая часть. Обзор Рынка

Вторая часть. Внешние и внутренние противоречия

Третья часть. Основные действующие лица

Четвертая часть. Что есть базовая станция 4G/5G?

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

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

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

Продолжение. К предыдущим постам и карте цикла.

Знаете, что случается, когда и архитектура вроде получилась и команда подобралась нормальная? Приходит ПОЦ. Пилотная версия. Проверка боем. Да, вы уложились в сроки и даже прошли всё внутренние проверки и тестирование на стороне клиента (UAT, SIT, PPT, ETC), так что теперь вас ждёт всё более худшее – то, что не нашли. Потому что там точно что-то спрятали. Может и не вы, но в конце точно прозвучит: «доктор, это вам!».

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

Из-за меня постоянно увольняют людей. Технически увольнение выглядит по-разному – по собственному, выдавливание, иногда прям ссаными тряпками гонят. Что важно: все эти люди – не мои подчиненные.

Я расскажу несколько сценариев увольнений. Очень нужно ваше мнение по теме. Правда.

Продолжение. К предыдущим постам и карте цикла.

Будни разработчика. Цели определены, направления выбраны, задачи разжеваны. Нужно просто писать код и жевать кашку. Что может скрасить серость и однообразность существования? Конечно же daily standup - шоу, в котором есть место для каждого! Ну вот эти вот неожиданные «я посмотрел архитектуру и там ошибка» или вот «я добавил новый модуль, который нам может пригодиться в будущем» ну и, конечно, «я сделал всё проще и быстрей». Мы ведь именно ради этого делаем все церемонии груминга и планирования. Чтоб как бы подготовить почву и дать всем время посидеть молча и заготовить эти панчлайны на конец спринта. А самое обидное, что, потратив столько усилий, на сам стендап вы обычно не попадаете и панчи вам передаёт ваше начальство.