Генетические алгоритмы удивляли инженеров. Но так их и не заменили В 2006 году NASA вывело на орбиту три микроспутника ST5. На каждом стояла антенна, форму которой подобрал генетический алгоритм: скрученная металлическая загогулина, будто помятая канцелярская скрепка. Радиоинженер в здравом уме такое бы не нарисовал. А она по ключевым параметрам обошла классические антенны. За десять лет до этого Адриан Томпсон поставил алгоритму другую задачу: собрать чип, различающий сигналы частотой 1 и 10 кГц. Программа нашла схему из 32 логических ячеек. Пять из них вообще не были соединены проводниками с выходом. Как работала схема, не смогли до конца понять ни исследователь, ни инженеры производителя. Казалось бы, вот он, святой Грааль проектирования. Задаёшь метрику, запускаешь перебор — и получаешь решения, которые ставят специалистов в тупик. Обсудим, почему за десятилетия подобных успехов генетические алгоритмы не стали главным инструментом для создания ракетных двигателей, реакторов и операционных систем.

Пришла утром мысль:

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

Что имеется ввиду: - вам пришла идея (в этом примере был диалог во флудилке в духе «вот бы MCP прикрутить к Яндекс музыке, чтобы удобнее слушать подкасты и забирать») - вы вместо того, что создавать с нуля, идете искать референсы и примеры реализаций. И это может принести часы экономии и натолкнуть на новое, о чем вы даже не думали. ❓За прошлую неделю, на какую интересную библиотеку/проект вы наткнулись и попробовали использовать и теперь думаете приживется, либо будете делать на основе него свое?

Мобильник почти из ничего: как ИИ помог собрать телефон из деталей с маркетплейсов Радиомодуль SIM800C, микроконтроллер STM32L051, экранчик 128×32 и литиевый аккумулятор на 75 мАч, снятый с летающего шарика из «Фикспрайса». Схема заводится не сразу, потому что радиомодуль стабильно уходит в ребут. DeepSeek выдаёт таблицы соединений пинов и стартовый код, Gemini выбирает микроконтроллер и рисует корпус в OpenSCAD, ChatGPT разбирает готовое на небольшие функции и добавляет на экран уровень сигнала и часы. Дальше приезжают тактовые кнопки, колпачки превращаются в пазлы, чтобы держать друг друга, телефон принимает входящие и набирает номера, а звук автор оценивает на твёрдую четвёрку. Потом дело доходит до приёма СМС, и ни один из трёх не выдаёт код, который заработал бы и не сломал уже собранное. Выясним, как всё-таки на этом телефоне появились СМС.

Как проектировать продукты для мышления Самая частая причина провала продуктов для запоминания/обучения чему-либо не плохой движок/интерфейс, а то, что пользователь продакт не смог ответить, ЗАЧЕМ именно ЭТО нужно помнить. Решить, ЧТО достойно быть запомненным – вот главная работа, которая а) не автоматизируется; б) не решается никаким механизмом удержания и вовлечения и она первичнее того, как это запоминать. Правильный продукт для мышления открывает мысли, которые без него не могли бы случиться, поэтому правильный вопрос такого любого продукта не «что должен делать продукт», а «какие мысли он позволит подумать». Забавная игра слов и смыслов в пятницу, ага. Модель продукта для мышления ≠ Продукт Модель продукта, в которой развитие мышления строится на интервальном повторении крива и нестабильна, потому что интервальное повторение всего лишь один один из десятков механизмов для развития мышления. Строишь продукт вокруг одной модели и он станет её потолком и блоком. 10 механизмов удержания в памяти: множественность форм одного вопроса, атомарность вопроса, dual-coding (текст+образ), вариации контекста, обогащение связей, сторителлинг смысла(ов), чанкинг (укрупнение единиц восприятия), калибровка внимания. 10 механизмов мышления как такового: расконцентрация/уединение, задержка первого ответа, наблюдение ощущений до, петля инсайт↔создание, сеть связей, а не изолированные факты, смена уровня абстракций, воплощение абстракции в предмет, поиск контрпримеров и опровержений, эмоциональная включённость, вопрос без заранее заданной цели. Проектируй Сети, а не точки Единица ценности – в Сети ты знаешь сам чего Структура связей делает забывание сложным. 1) Давай знание минимум в двух кодах одновременно. Текст + образ вспоминается устойчивее вместе с параллельным каналом кодирования той же единицы смысла. Экспериментируй с ними. 2) Варьируй контекст(ы), а не только содержание. Одно и то же место, время, фон снижает удержание на 40% относительно вариативного контекста. Продукт, который всегда выглядит и ощущается одинаково при повторном касании, недоиспользует потенциал памяти сам по себе. Вариативность интерфейса это новый механизм. Плотность чанков важнее объёма знаний, а значит, что продукт должен ускорять именно сборку чанков у пользователя через укрупнение единиц восприятия форм. Чанки – это небольшие квадратные участки, на которые игры (например, Minecraft) делят свои большие миры для экономии памяти и быстрой прорисовки 🍌Но и здесь скрыта очередная ловушка мозга: так, пользователь обучается узнавать форму вопроса раньше, чем осмыслять его, и начинает отвечать на паттерн, а не на суть. Поэтому снова упаковывай один и тот же смысл, но в 2+ разных формы, иначе ты тренируешь узнавание интерфейса, а не мышление. Эмоция – несущая конструкция в продуктах, а эмоциональная связь пользователя с материалом первичней материала как объекта. Великая цель-петля таких продуктов – изменение знаний всего человечества, которое возвращается и меняет тебя, твой продукт и мир. Они рождаются только тогда, когда их создатель решает свою собственную реальную задачу и делится этим процессом с окружающими миром через свой продукт. Они растут только вместе с пользователем, расширяющееся понимание и мышление которого должно менять как пользователя, так и сам продукт, порождая у обоих новое понимание предмета мышления. Всё есть петля, пространство, круг и цикл. Ты начнёшь строишь благо, не осознавая это.

Замкнутость интерфейса Замкнутость интерфейса — это полнота и непротиворечивость правил, определяющих его состояния и переходы между ними при всех допустимых сочетаниях данных, условий и событий. Для любого допустимого сочетания данных и условий ясно, как выглядит и ведёт себя интерфейс. Например, список может быть пустым, содержать одно значение или тысячу, и мы понимаем, как они выглядят. Это состояния. В каждом состоянии определён перечень допустимых событий, включая действия пользователя, которые влияют на интерфейс, например, значения можно добавлять и удалять, и нам тоже ясно, как это всё работает. Это переходы. Самое интересное и сложное — это то, что переход должен полностью определяться состоянием и событием. Он не может зависеть от истории предыдущих состояний (если только это не буквально переход по истории состояний типа «Назад» или «Анду»). Если переход из некоторого состояния S при событии E зависит от того, попали мы в S из Q или R, то это значит, что нет никакого состояния S, а есть состояния S1 (S после Q) и S2 (S после R), и важно это осознать. Может показаться, что это какая-то заумь и вообще, какая разница. Но если не обращать внимания на это, то в интерфейсе возникают неявные состояния, в которых вид и переходы не определены. Дизайнер-то думает, что рассмотрел состояние S, да вот только это мифическое состояние, а настоящие состояния S1 и S2 он не рассмотрел. При проектировании сложного интерфейса иногда непреднамеренно возникают состояния, из которых невозможно выбраться, или до которых невозможно добраться, или до которых можно добраться только, если сразу пойти по правильному пути. Для дизайнера важно научиться видеть это. Часто бывает, что я спрашиваю, например, «А в этом случае что будет?», и дизайнер только в этот момент понимает, что такой случай вообще существует. Внимательно разбираться с замкнутостью — кропотливая работа. Обычно мы рассматривает разные состояния и переходы в контексте некоторого флоу, то есть пути пользователя. Мы рисуем экраны друг за другом и представляем, как человек проходит между ними. Нам кажется логичным, что после такого-то экрана при таком-то действии появляется сякой-то, и мы не замечаем, что в другом флоу на таком же экране при таком же действии появляется другой экран. Когда мы думаем про этот флоу и смотрим на это глазами пользователя, мы почти всегда думаем о любом состоянии в контексте предыдущих состояний, и не отдаём себе в этом отчёт. В моём примере с автодополнением отдельные решения сначала кажутся нормальным, пока не начинаешь смотреть, какие запутанные состояния и переходы они порождают. Исправление каждой возникающей неприятности создаёт исключение, усложняя систему и добавляя неприятностей: https://ilyabirman.ru/meanwhile/all/ui-completeness-example/ Я приводил примеры вопросов, которые помогают проверить интерфейс, но понятно, что ответы даже на все вопросы сами по себе не гарантируют замкнутость: https://ilyabirman.ru/meanwhile/all/completeness-questions/ О замкнутости следует думать как о математическом качестве. Возьмём такую теорему: «Число 60 делится на все числа». Это легко проверить: на 1 делится, на 2 делится, на 3 делится, на 4 делится. Мне продолжать? Ну на 5 делится, на 6 делится, сколько ещё примеров надо? Какое число ни возьми — на всё делится: 10, 15, 20... Так ведь? Но нет, это ничего не доказывает. Чтобы доказать теорему, нужно искать не удачные примеры в большом количестве, а саму фундаментальную причину, по которой она неизбежно верна. В данном случае такой причины нет. При проектировании интерфейса сложно требовать от дизайнеров рисования полного графа состояний и переходов. Не уверен, что делал такое хоть раз в жизни. Но всё же полезно хотя бы понять, что это такое. Полезен и опыт программирования — оно развивает интуицию на такие вещи. Смотришь на проект интерфейса, и чутьё подсказывает: что-то не то, сейчас найду дыры. И дыры находятся. Вообще, чем больше для описания интерфейса приходится придумывать частных исключений, тем больше возникает подозрений в том, что общее правило плохое или вообще не придумано.

Ретрофутуристичная «Виселица»: одна функция, шаговик 28BYJ-48 и полугодовая война с третью шага Оверинжиниринг — прошлый век, теперь эпатажный инжиниринг. У девайса ровно одна функция, а выглядит он как пульт управления инопланетным кораблём. Автор собрала физическую «Виселицу» с двумя вращающимися дисками букв, шаговиками, промышленным тумблером и силиконовыми накладками с детской присыпкой сверху. Крутишь энкодер, диск с механическим шуршанием подгоняет букву в иллюминатор, ошибся — экран дорисовывает виселицу. А потом началась математика. Шаговик 28BYJ-48 тратит 2048 импульсов на оборот, согласных 24. Делим и получаем 85,3333 шага на букву. Мотор не умеет делать треть шага, и это только первая из проблем, которые устроила геометрия диска. Дальше в дело вступила скрытая мистика с уползающими нулями. Посмотрим, как одна функция превращается в полгода войны с железом.

Китай подключил ИИ-агентов к проектированию чипов — разработка ускорилась в четыре раза Китайская Empyrean Technology подключила ИИ-агентов к проектированию чипов. По словам компании, оптимизация дизайна и симуляция теперь занимают около недели вместо четырёх. Разработчики смогут управлять не отдельными программами, а ИИ-агентами, которые взаимодействуют друг с другом. Поставщики EDA-софта также готовятся перейти от лицензий на рабочие места к оплате за использование ИИ-токенов. Власти КНР рассчитывают вывести китайские решения для проектирования чипов на мировой рынок к 2030 году. #eda #cadence #разработкачипа #ии 📎Подробнее 🔖 3DNews в TG | MAX | VK

Почему люди ошибаются Случайно прикусить язык во время еды это прекрасный пример, что можно облажаться, даже имея многолетний опыт. Люди ошибаются по многим причинам:  1. Необходимость научения. Любой процесс требует определенных навыков, где-то больших где-то меньших. Если мы говорим про медицину — то даже такая простая вещь как поставить укол, требует определенных навыков.   2. Люди могут находится в разном физическом и эмоциональном состоянии. Усталые и голодные люди будут совершать больше ошибок, чем отдохнувшие и с достаточным уровнем сахара в крови.  3. Вариативность, которая свойственна как человеку как сложной системе. 4. Внешние факторы и другие причины.  Но одна из самых основных причин ошибок — это когда задача не учитывает особенности людей, тому как они обрабатывают информацию и как работают. Чтобы правильно проектировать процессы, нужно понимать особенности человека и то, как он взаимодействует со средой.  Этот раздел как раз будет посвящен особенностями работы человека. ;)

Как я проектирую UI/UX (с и без ИИ) 0. Не проектируй интерфейс раньше, чем язык и слова, которыми он будет описан 1. Всегда учитывай Целое Процесс дизайна состоит из трёх шагов: 1) Перечислить все ограничения, под которые проектируется диз; 2) Рассмотреть множество решений, удовлетворяющих этим ограничениям; 3) Если понимаешь, что нужно добавить ограничение или одно можно убрать, вернуться к шагу 1.

ИИ хорошо генерирует варианты, но плохо держит ограничения, поэтому дизайни ограничения раньше, чем экраны

2. Убирай лишнее Убирай ненужное, что все (ты сам, коллеги, ИИ) так любят добавлять. Простой вопрос: "Юзер сможет без этого решить свою задачу?". Ответ в 80%: "да"

Проверяй дизайн на скорость понимания, а не на красоту

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

Проектируй UI для повторного использования UX Гибкость системы = гибкость интерфейса. И наоборот

А если решение работает только для одного экрана, то скорее всего, оно временное. Ищи где UI/UX должен(!) всплывать ещё 5. Заимствовать чужие дизайн-решения не глупо, глупо их не заимствовать, потому что большинство UX-проблем и паттернов уже давно решены. Всё что нужно это опознать ваши, найти подходящее решение и собрать всё вместе. Собранные вначале работы удачные скриншоты от конкурентов/смежных проектов дают более чистое видение проблем и вам и снова полезны для ИИ. 6. Исследуй вкус Предпочтение = это «мне нравится» Вкус = это понимание, почему нравится

Вкус – это рефлексия над собственной реакцией на что-то

7. Никогда не торопись c дизайном 😌

Часто в искусстве используют оч сложные технологические решения, забывая, что главное - это не перезадротить всех задротов, а ✨ эмоции зрителя ✨ Зритель либо испытывает что-то, либо ему скучно. В последнее время у меня вообще появился любимый вопрос ко всем проектам, которые я делаю или консультирую: "почему людям на это не будет похуй?" Неважно, это арт проект, игра, да даже пост в телеге. Оч полезный и очень емкий вопрос, всем советую! Часто кучу эмоций у аудитории вызывают какие-то простые вещи. Как тут. Ну магия же! А на самом деле это просто трекеры (крепко подозреваю, что виар трекеры от Vive), которые приспособили управлять прожекторами.

Иногда ставят такую цепочку тумблеров проверки на важных ответственных пультах управления. Ты должен повернуть каждый из них, как чек-лист, обдумывая каждый пункт: так, тип снаряда правильный, ага, азимут мы поставили, возвышение тоже - и когда ты замкнёшь последний, тебе открывается возможность совершить необратимое действие (в данном случае, выстрел). И вроде идея правильная, но с первого же раза ты просто воспринимаешь это, как цепочку действий, которые нужно выполнить перед выстрелом и просто не думая, пробегаешься по ним, как пилот включает все тумблеры перед взлётом. Только потеря времени. Небольшим улучшением контроля оператора было бы введение пауз между тумблерами, но они ещё больше бы увеличили время выполнения ключевого действия (выстрела). А вот хорошей идеей было бы поставить простейший автомат верификации: Допустим, на пункте управления башней оператор выставил наклонение 32.3 градуса и азимут 177.4, а заряжающий на своём посту уложил в лоток фугасный снаряд. Теперь оператор конечного пункта должен ввести эти же ключевые параметры у себя на пульте - когда они все совпали с теми, что сейчас реально выставлены на остальных пунктах, открывается возможность произвести выстрел. Это гарантирует стабильно высокое внимание оператора и исключает ошибки по невнимательности. Слава Кастилии! Министерство Эргономики

Проектирование дизайна как создание объяснения Прошу своих студентов придумать, как должна выглядеть и работать следующая версия их продукта. Они пишут, мол, там будет то и сё, и надо будет учесть это и это. Кажется, они думают, что они всё понимают, а я всё никак не удовлетворюсь их ответами. Периодически даже звучат слова вроде «давай мы сделаем прототип или даже навайбкодим тебе». А я говорю, да погодите, вы мне объясните сперва! Я верю в идею «кто ясно мыслит, тот ясно излагает», поэтому если вы правда способны сделать прототип, то значит вы понимаете, как всё должно работать, и можете это рассказать. По моему опыту, многие дизайнеры даже не осознают того, что у них в голове нет целостной картины продукта. При этом иногда чтобы что-то придумать, нужно какое-то время порисовать или попрограммировать, как бы пощупать задачу разными способами — это я понимаю. Я не против никаких промежуточных прототипов, если так удобнее думать, но в качестве результата я хочу описание системы. В общем, наша переписка продолжается какое-то время. Они уже пишут подробный текст, но им всё ещё моя просьба кажется удивительной: «Неужели тебе правда это удобнее, чем макет или прототип? На макете же сразу видно, где что!» Да, но не видно, почему! Какой толк от прототипа? Ведь из я прототипа ничего не пойму. Я буду видеть, что что-то как-то сработало, но я не увижу внутренних причин. У меня всю жизнь так было, я терпеть не мог прототипы, потому что я с ними как слепой. Как мне увидеть и осмыслить саму систему, а не отдельные её случайные проявления, до которых я докликал? За прототипом очень легко спрятать, что у вас ничего не продумано. После прочтения Дойча я понимаю, почему так: прототип — не объяснение. Что толку физику от результатов опыта, если у него нет объяснительной теории, которую эти опыты подтверждают или опровергают? Это же просто рандомные факты, вызывающие лишь недоумение. Чтобы понимать, почему они такие, мне нужно открыть, то есть придумать закон, который бы их объяснил. Но если мне самому нужно придумывать закон, глядя на эффекты его воплощения в прототипе, то в чём тогда была работа дизайнеров? Я ж как раз изначально попросил их придумать этот закон! А в итоге вынужден его придумывать я. Если вы его реально придумали, так просто расскажите. А если у вас только прототип, то вы его, скорее всего, просто не придумали. Это всё снова показывает, насколько качественное проектирование близко к придумываю законов физики.

Где возникают ошибки Можно предложить следующую модель получения результата: цель → намерение → действие → система → результат Все это находится в окружении, которое влияет на наши действия. 1. Намерение Насколько намерение помогает достичь цели, или насколько у меня правильный образ действия, того, что я хочу сделать. Дон Норман называл эту стадию понимание «концептуальной модели системы». В ряде случаев концептуальная модель простая: если нажать на педаль тормоза, то машина остановиться. Но в ряде случаев концептуальная модель может быть запутанной: чтобы открыть дверь — её надо толкнуть или потянуть на себя? Я уже не говорю про более сложные системы. Насколько система представляет собой ясную схему, что и как надо сделать, чтобы получить желаемый результат? 2. Действие Несовпадение намерения и действия — действительно ошибка человека. Я хотел повернуть налево, но повернул направо. Я хотел нажать на тормоз, а нажал на газ. Насколько система позволяет сделать неправильное действие. Кроме этого важную роль начинают играть другие факторы: усталость исполнителя, отвлекали ли исполнителя во время важных действий и т.д. 3. Система или черный ящик. Сама система может работать с ошибками. Люди могут неправильно понять, то что мы им говорим, информация передается с ошибками. Механизмы могут быть спроектированы с ошибками, софт ошибается. 4. Окружение Это та обстановка, в которой мы действуем. Либо это культура организации, это социоэкономические факторы и т.д. Окружение может влиять на ошибки, которые возникают в процессе. Есть ли давление, чтобы добиться хороших результатов. Насколько система требует не ошибаться или система требует достичь цели любой ценой. Это культура компании, тон сверху, психологическая безопасность и все подобные вещи. Сюда же относятся ошибки, которые можно называть «внешними событиями». Мы ехали по правилам, в нас врезалась машина. Но мы же все сделали правильно. ;) Как видно, отклонения или ошибки могут возникать на любом уровне в этой модели. Но на каждом уровне ошибки возникают по разными причинами и требуют разных методов для предотвращения. #ЧФ #ошибки

Программирование с явно выделенным состоянием Одна из моих любимых тем, про которую не устаю говорить. В модели данных часто бывает ситуация, когда состояние выражено не прямым образом, а косвенно. Буквально вчера я реализовывал кастомные тарифы под конкретных пользователей. Отличие такого тарифа от обычного сводится к тому, заполнено ли поле user_id в тарифе или нет. Если не заполнено, то значит это общий тариф, если заполнено, значит под конкретного пользователя и другие его не могут видеть. Это вполне рабочая схема и она встречается повсеместно, особенно в связке с датами типа deleted_at, но она обладает одним очень важным недостатком. Понимание того, что эта запись находится в особом состояние вычисляется через косвенный признак или, что хуже, через набор признаков. Об этом надо думать и каждый раз вспоминать и выуживать эту информацию. Сейчас, в эру агентного программирования, это стало еще важнее. Агент может догадаться до правила, но ему нужно на это время и отдельный анализ. Можно конечно написать об этом в правилах, но зачем, когда можно просто поправить модель данных? Все что требуется, это введение текстового поля со статусом, которое явным образом скажет о происходящем с этой записью. В общем не полагайтесь на то как заполнены поля, вводите нужные статусы, которые явно будут говорить о том что происходит. Заодно это дает более удобную аналитику и выборки Telegram | YouTube | AI Клуб

Отношения между сценарием и навигацией в интерфейсе При проектировании интерфейса важно проанализировать сценарии, то есть хорошо представить, как именно, в какой ситуации, с какими знаниями, целями и ожиданиями человек будет пользоваться интерфейсом. Многие забывают про это подумать, и у них получается ерунда. Но иногда ерунда получается, даже если про это подумать, а затем просто положить сценарии в основу навигации. Что будет, если просто положить сценарии в основу навигации? Когда сценариев очень мало, может получиться неплохой интерфейс. Если есть всего три-пять действий, за которыми человек приходит в интерфейс, и мы просто делаем для них кнопки, то всё будет понятно и удобно. Это то, что я предлагал для ПВЗ «Яндекс-маркета»: https://ilyabirman.ru/meanwhile/all/interfeys-pvz-yandeks-marketa/ Но такие интерфейсы встречаются редко. Даже в небольшом продукте есть множество связей между функциями, и число сценариев огромно. Если в таком случае начать строить навигационную модель вокруг сценариев, в интерфейсе станет невозможно разобраться. В заметке об архиве вакансий я как раз указываю на эту проблему: https://ilyabirman.ru/meanwhile/all/arhiv-vakansiy-ne-mozhet-byt-podrazdelom-sozdaniya-vakansii/ Когда я говорю про огромное число сценариев, необязательно представлять что-то необъятное вроде Фотошопа. Даже календарь — это уже целый мир разных сценариев. Ну вот, например: Иван понял, что не успевает на регулярную встречу, и хочет предупредить других участников о переносе. Кому-то из них удобнее написать, кому-то позвонить. В ходе одного из звонков Пётр говорит, что давайте тогда уж вообще перенесём эту встречу на час позже, потому что ему самому трудно на неё успевать всё время. Иван смутно помнит, что где-то через пару недель у него запись к зубному, и хочет убедиться, что перенос не конфликтует с ней, идёт проверяет. Выясняется, что конфликтует, но договариваются всё же перенести на час позже, а там, через две недели, просто сделать исключение. Ну и что, как построить навигационную модель вокруг этого сценария? Да никак. Во-первых, если вы хорошо провели анализ, то даже тех сценариев, которые вы рассмотрели и выделили как ключевые, будет довольно много. То есть даже если для каждого из них есть прям готовая кнопка или раздел в интерфейсе, найти их будет не так просто. Во-вторых, остальные сценарии, которых несравнимо больше, вообще непонятно, где надо будет искать. Развивать такой продукт и поддерживать растущее число сценариев — боль. Хороший интерфейс не ведёт по сценариям, он лишь создаёт для них возможности. Он даёт пользователю свободу, чувство контроля, ту самую «агентность», а не просто направляет его по одной из нескольких заранее проложенных дорожек. Разумеется, в календаре нет готовой кнопки или даже «мастера» для того, что описано в сценарии выше. Календарь просто так устроен, чтобы пройти по этому сценарию не составляет труда. Это похоже на вопрос о том, зачем нужны карты и схемы, когда в телефоне и так есть навигатор. Навигатор очень полезен, но с ним ты не чувствуешь себя хозяином положения, не можешь отклониться от пути. Карта же даёт общее понимание того, как устроен мир, и ты уже можешь сам принимать решения. На карте нет специальной секции для сценария «по пути с ребёнком из школы заехать погулять в парк», но она делает этот сценарий возможным без проблем. В навигаторе можно предусмотреть функцию «заехать по пути», но её ещё нужно будет найти, а также десятки других сценариев останутся непокрытыми. Поэтому в основу навигации в интерфейсе нужно закладывать некую модель того, как мы хотим, чтобы человек представлял себе устройство нашего продукта: какие у нас есть сущности, как они связаны, организованы, что они умеют. Эта модель должна помогать нам реализовывать все важные сценарии, а пользователю — находить способы их реализации. И эта модель должна выдерживать развитие продукта.

Архитектурные практики Прошло чуть больше полугода, как я перестал писать код руками, за редкими исключениями. Но несмотря на это, я просматриваю его глазами. Где-то внимательнее, где то по диагонали, в зависимости от степени влияния на структуру кода и логику. И каждый раз спрашиваю себя, а какими принципами я руководствуюсь? Пишу этот пост, чтобы порефлексировать с одной стороны и заложить на будущее темы, которые буду разбирать. ИИ это хорошо для кодинга, но инженерия никуда не девается. Все происходит над подсознательном уровне, я работаю в давно знакомом мне проекте и хотя бы примерно понимаю что и где происходит, задачи которые я делаю тоже понятны, все таки и в разработке давно и сам проект не гугл. Но он достаточно большой и сложный, чтобы можно было просто забить на архитектуру и делать как придется. Наверное главное, за чем я слежу и что прорабатываю глубоко это онтология проекта: сущности, свяжи между ними и границы ответственности. Причем речь не идет о том, чтобы попытаться полностью повторить реальный мир, наоборот, идет попытка создать систему, с одной стороны, простой, с другой нужно учесть все необходимые требования от нормализации до поддержки историчности при изменениях (там где это надо). Связь m2m сложнее o2m, это будет проявляться и в запросах и в коде. Можно ли не усложнять? А если мы работаем с иерархией сущностей, надо ли делать одну таблицу с полями сразу для всего, но чтобы каждый тип использовал свое подмножество или нам надо создавать разные таблицы? А как потом их объединять? Денормализация или внешний поиск? И обязательно инварианты. Какие состояния в системе вообще допустимы? Что не должно происходить никогда? Какие связи обязательны, какие опциональны. Здесь мы имеем дело и со смыслами и с технической имплементацией на уровне хранилища и, в моем случае, ORM. Можно ли в этом случае довериться ии? Обсуждать, спрашивать совет и просить рассказать плюсы и минусы разных вариантов это прямо хорошо, но принимать решение точно надо самому, потому что слишком дорого потом придется платить за неудачно принятые решения. А они точно будут. Примерно такая же история с api. Если внешние ручки спроектированы плохо, потом мы обалдеем тащить это легаси через года и пространство. Между первым (моделями) и вторым (api) собственно и лежит большая часть кода в типовых веб-приложениях. Да ее пишет ИИ, но на базе заложенной архитектуры. Причем она достаточно стандартна. У нас есть слой сервисов, где выполняются бизнес-операции и проверяются инварианты. Рядом находится слой авторизации и события. К этому примыкает инфраструктурный слой с асинхронными джобами, очередями, мидлварами и тому подобным. Я отдельно выношу обработчики http, dto и валидациями данных запроса и ответа. Все это вообще не надо писать самостоятельно, сейчас, когда легко доступен design-first, лучше пользоваться генераторами типа openapi-generator, которые создают все автоматом на базе openapi. Все что остается, это вписать в нужные места вызовы своих сервисов и правильно сформировать ответ. Даже если обходиться без генерации, ии отлично справится опираясь на существующий код, если он написан нормально. Отдельный большой блок связан с микросервисной архитектурой, но я пишу про нее редко, потому что живу в монолите (хотя и с кучей сервисов, асинхронных джоб и обвязок вокруг). Оставляю эту тему другим блогерам 🙂 Ну и фронтенд, с ним ситуация явно проще, особенно если использовать готовые библиотеки компонентов и сгенерированные sdk для api (если у нас есть openapi). Да, во фронте есть свои заморочки связанные с безопасностью, отсутствием коннекта, локальным стейтом, ошибками, идемпотентностью и другими интересными темами. И конечно без понимания базы, сделать что-то серьезное будет сложно. Все? Нет конечно, самое интересное начинается когда надо думать об обратной совместимости, следить за транзакционными границами, идемпотентностью и конкурентностью. И тесты, которые ии по дефолту пишет плохо. Вот это все не будет происходить само по себе и хорошо бы знать, как оно устроено под капотом. Что еще упустил?