или “Страшная сказка: продолжение-3”

В предыдущих разборах серии («О бедном луддите замолвите слово…», «Об Open-source — спасителе человечества…», и в исходной «Страшной сказке») я разбирал, кого, что и почему мы теряем в ходе AI-кризиса: воронку джуниоров, цикл воспроизводства экспертизы, frontier-фронт, наработанные в OSS анклавы. Каждый раз картина была про минусы и проблемы.

В этой статье — про другую сторону медали. Потому что у того же самого процесса, помимо потерь, есть некоторое количество “трофеев”. И стоит их упомянуть, чтобы картина была полной и честной.

Для этого я расскажу “байку”…

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

В предыдущем разборе («О бедном луддите замолвите слово…») я разобрал по единой схеме одно из ключевых возражений против катастрофического прогноза кадрового разрыва — паттерн ткацкого станка. То возражение отбрасывается структурно: условия, при которых паттерн срабатывал, в текущей ситуации не выполнены.

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

Схема та же:

Жил-был разработчик. Работал на Unity. Любил свою работу.

Разработчик любил архитектуру. Поэтому подключил DI-контейнер. Потом второй, потому что в первом не было ScriptableObject-биндингов. Потом третий, потому что во втором не работали async scope. Везде была фабрика фабрик, IServiceProvider, который под капотом резолвил IServiceProviderFactory, и пять способов сконфигурировать один и тот же InventoryService.

Разработчик любил чистый код. Поэтому развёл IInventoryService, IInventoryRepository, IInventoryFacade, InventoryDTO, InventoryMapper, InventoryValidator и InventoryQueryHandler. Семь классов, чтобы положить в инвентарь меч. Меч был один.

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

Разработчик устал.

И написал свой фреймворк.

Это не статья про конкретные техники — они описаны в документации, ссылки в конце. Это статья про принципы, из которых эти техники следуют. И про то, почему именно такие принципы. Их пять.

или "Страшная сказка: продолжение"

Когда появляется очередной прогноз катастрофического характера, в ответ всегда поступают возражения определённых типов. Эти возражения повторяются из дискуссии в дискуссию и обычно строятся на исторических аналогиях («раньше тоже боялись, и всё обошлось»), идеологических убеждениях («рынок решит», «государство справится», «технологии всегда побеждают»), психологических защитах («это не может быть так плохо»).

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

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

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

Типа предупреждение:
Далее идет нейрослоп и полет больной фантазии. Вы читаете его на свой страх и риск.


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

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