Лаборатория Математики и Программирования Сергея Бобровского

Вы до сих пор думаете, что Kubernetes - это решение? Поздравляю. Ваша платформенная команда уже выросла до семи человек, а разработчики проходят 12-шаговый квест, чтобы задеплоить простую хрень. Но главный вопрос: когда этот инструмент стал врагом народа? Ответ тихо вползает на сервера, и это не ещё один оператор в Helm.

Что не так с K8s:

Он жрёт ресурсы, время и души инженеров.
Ваши контейнеры весят по 100 мегабайт и стартуют как уставшие таксисты.
Абстракции текут, как старый кран, а новые разработчики учатся месяцами, прежде чем понять, почему под не завёлся.

Спаситель (барабанная дробь): WebAssembly. Помните мой сериал про него в Клубе несколько лет назад?

Да-да, тот самый, из браузера. Только теперь он на сервере, весит 5 килобайт и стартует за миллисекунду. Без контейнеров, без ядра, без боли.

Проект WASI делает его кроссплатформным, а Docker-папа ещё в 2019-м году сказал: "Был бы Wasm, Docker бы не родился". Но все сделали вид, что не расслышали. Ну штош.

Почему все молчат: потому что вложились в k8s по самые помидоры и сейчас пилят внутренние порталы, а не думают о будущем. Да, те, кто в 2017-м сел в поезд Kubernetes, сейчас пока в дамках. Но Wasm это тот же поезд, только экспресс, и он уже на перроне.

Что делать (чтобы не опоздать):
Дать двум миддлам неделю поиграться со Spin или WasmEdge.
Посмотреть на свои API и подумать: "А точно ли им нужен контейнер??"
Следить за CNCF: если там зашевелились, за считанные годы это станет стандартом.

Итог: Kubernetes никто пока не закапывает. Но если вы прямо сейчас не начнёте коситься в сторону Wasm, то через пару лет будете объяснять CFO, почему ваши биллинги за облако в 10 раз выше, чем у конкурентов.

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

.

Облако драгоценностей за неделю.

7-й гайд "Programming in Large" (по материалам СильныхИдей для ментатов), основной акцент на избавлении от зависимости от зависимостей.

Приватный клуб.

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


Для донов-начинающих:

(лонгрид) Прежде чем приступить к какому-либо проекту по программированию...

Продолжаю набор (эксклюзивно для донов) на занятия для начинающих с полного/около нуля, 2 места закончились за 11 минут.

Почему большинство онлайн-школ по программированию — просто красивая ложь?
Эта показная лёгкость. Эти "За полгода в ИТ средняя зарплата 170,000 рублей". Это "Доступно каждому ". Это "Гарантия трудоустройства".
Эти шаблонные лендинги и рекламные тексты от нейросетей про успешный успех в айтишке.
Я не против обучения программированию. Я против вранья...

Для донов-неначинающих:

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

99. Как и зачем отказываться от хранения логических значений в базе
Как вам такая идея, как отказ от хранения логических значений в базе? Что-то, конечно, вместо них всё равно надо хранить, но что?

(все старые материалы для донов быстро сгорают)

=

Новые материалы для ментатов Лаборатории.

null

=

"Функциональные архитектуры" 150(+3) топиков
Полиморфная консистентность, (тестовое) равенство сущностей в DDD как identity type.
После 150 материалов цена гайда (для новых) вырастет.

Last Principles Framework: готовы 21(+2) задач, закрыты 12(+2) тем из ~20 первого уровня. Вы же понимаете например, почему паттерн Builder и IoC / Callback - конструктивный отстой в сравнении с сопряжением теорката как идеальной архитектурой "API - Очередь - Воркер"? А когда формируете JOIN, это отнюдь не сборка результата, а наоборот стрелки из него исходящие (greatest lower bound)? Тотальная математическая контринтуитивщина уничтожит последние ваши мэйнстримовские иллюзии )))

=

"ЛаМПовое":

7-й гайд "Programming in Large"

=

Лаборатория идёт со скоростью самых лучших ментатов 💪🏻
(продолжаю бесконечное ужесточение правил занятий :)

=

Мыслящие машины - это зло, которое должно быть уничтожено до того, как человечество начнёт срывать плоды своей высшей награды.
Бене Гессерит, "Песчаные черви Дюны"

4/4
Потенциально скилл техлида нужен ещё больше, потому что без него никто не замечает проблем, пока не рвануло. Кризис по Gartner назначен на 2028-й, а до тех пор так массово и будет продолжаться - пока дешевле/проще - "просто закинуть ТЗ ещё раз" и бесконечные уточнения как в лотерее (шанс есть т.к. недетерминированность), чем платить профи за взрослую работу с AI.

При этом конечно рутинная часть архитектурщины будет автоматизироваться и дальше, и крупные компании продолжат пофигистично жечь токены, но стартапы например наверняка начнут снова платить белковым за спецификации, декомпозицию ТЗ итд. Скорее всего, роль "архитектор промптов/спецификаций/оркестрации агентов" станет отдельной профессией ("AI systems accountability lead"? :), но при этом такому спецу придётся следить не только за техническими аспектами, но и за бюджетом по токенам.
(сейчас собственно такое достаточно чётко и наблюдается в немалом числе стартапов, где денежки очень даже считают)

Но даже если за счёт инференса и железа токены станут бесплатны, всё равно, как говорил, кто-то всегда должен будет нести ответственность за инциденты в проде и понимать систему поглубже, чем нейронка. Этот слой спроса на архитектурный скилл не исчезнет ни при каком раскладе с токенами! При этом, в вакансиях будет например явно требоваться - как сегодня "знание веб-фреймворка" - условный скилл "резать косты токенов через спеки".
Потому что, ну смотрите - есть принципиальная - концептуальная! - разница между "закинуть ТЗ" и "сделать контролируемый пайплан для реализации ТЗ".

Когда есть чёткие спецификации, когда есть набор тестов, когда есть ясный критерий правильности, нейронки работают принципиально по-другому! Такой формальный - в идеале математический (разбираем это в частности на Функциональных архитектурах) - подход заставляет нейронку тщательно проверять каждый шаг перед ответом, контролировать всю логическую цепочку, видеть противоречия, возвращаться обратно -- это closed-loop, это мощь пошаговой самопроверки в замкнутой системе, которые сегодня в LLM активно встраиваются.
И чем больше тут будет математики (и чем она будет сильнее), тем экономнее и продуктивнее (на многие порядки!) нейронка будет работать!

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

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

Проблема не в нейронке -- проблема в уровне подготовки ленивых человечков :)

3/N

Какой сегодня уровень автономного проэкта для нейронок реален?

Вот сегодня, ментат пишет:

Как юзер еще раз попробовал MCP Figma, и то ли платная версия, то ли просто он стал лучше - результат очень хороший, с учетом того, что я в целом понимаю в react/typescript - мой фронтэндер официально мне не нужен)

Ну да, фронт уже почти умер, реально ) потому что в целом задача попроще и главное достаточно автономная. Не одно десятилетие внимательно слежу за геймдевом, сейчас за большое количество токенов можно, разбираясь в теме на уровне PO, без знания программирования за несколько дней запилить игру средней сложности, это где-то 3-5 тысяч строк кода условной логики (нейронка нахерачит конечно раз в 10 больше).

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

2/N
Какие же скиллы будут актуальны в перспективе?

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

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

А "готовый сервис на выходе" - на каком? Его ведь надо задеплоить для начала.

А точнее сперва кто-то должен взять ответственность "этот сервис реально можно в прод", и бежать разбираться, когда на живых юзверах прилетит инцидент в 2 ночи, и "просто перезакинуть ТЗ ещё раз" или "пофикси где-то там хз где" не сработает :)

То есть даже у простого SaaS-а есть точка входа (спека) и точка ответственности - кто подписался за базар (регуляторка, кибербез, эпикфейлы), и обе точки может закрыть только человек с архитектурным+devops опытом. И тут буквально 50/50 будут ли требоваться такие люди в разы меньше или в разы больше.

Но конечно пытаться предсказать "насколько вероятен тот или иной сценарий", смысла особого нету. Хвосты распределения и через 2-3 года будут такими здоровыми, что например ты в одиночку с помощью последних нейронок и топовых харнесов фигачишь тикеты как слепой крот с помощью какого-нибудь функционального DSL, а буквально за стеной толпа отупевших мидлов делает в пять раз меньше в каком-нибудь стеке жава8/11. Хотя зарплата твоя от ихних отличается от силы на +50%.

Причём ситуация с искусственным идиотом пока что лишь быстро ухудшается: сегодня впервые за семь лет мой мобильный клиент одного из крупнейших цветных банков дал вот такой сбой ))) Понимаю что навайбкодили (и нафиг вообще скулайт на клиенте прикручивать?? чем плайн файлики-то провинились), но как минимум просто версию проверить и выдать ссылочку на apk если устарела, кому-то не хватило соображалки. И дальше будет только хуже (и для нас это очень хорошо, понятно почему:).

Это я намекаю на то множество скиллов, которое с развитием AI создаёт непреодолимую пропасть между элиткой и всеми остальными. Думайте )

1/N

Ладно, давайте по-взрослому. Сермяга вот в чём: если решения в компаниях особо не чувствительны ни к деньгам, ни к скорости, то экономических оснований для спроса на скилл архитектора/техлида в его нынешнем виде действительно не остаётся (не говоря уже про все остальных разработчиков).

Kelsey Hightower (principal engineer Google), KubeCon 26: "Everyone is a junior engineer when it comes to AI".
+ Типа, AI создаёт новые риски безопасности именно потому, что инженеры перестают глубоко понимать, что происходит под капотом. Но на это менеджерам вообще пофиг, security -- самая трудно продающаяся темка в ит, никого не колышет.

Карпатый: "Раньше ограничивающим ресурсом были flops, теперь токены. Какой у тебя token throughput? Долгосрочное будущее этого туманно... это работа для экономистов, а не для меня."

McKinsey ежемесячно сжигает ~5 триллионов токенов.

etc

И вот институциональное подтверждение растущего пофигизма от Gartner с грядущим взрывом. Организации быстро переходят от экспериментов с AI к масштабному развёртыванию агентов, но многие недооценивают финансовое влияние роста потребления токенов. И сам взрыв Gartner назначила на 2028й:
В 2028-м расходы на AI-кодинг превысят среднюю зарплату разработчика из-за роста token consumption и перехода на consumption-based pricing вместо seat-based лицензий.
июнь'26
и даже дешевеющий токен не спасает от роста трат, потому что потребление растёт быстрее падения цены: агенты будут работать параллельно автономно дольше (Карпатый прямо называет это нормой).

Это именно тот момент, когда пофигизм кончается не от мифического поумнения манагеров, а чисто из бухгалтерии; CFO физически не может это больше игнорировать :) Причём первыми этот сдвиг на своей шкурке жостко прочувствуют небольшие компании.
Кстати сегодняшний кейс, как в компании 500 разработчиков вышло $340k/год на токены, и финансисты слегка офигели.

А что из этого получится к 2030-му, никто не знает. Главный вопрос как долго автономные агенты смогут приносить выручку, которая перекрывает рост расходов на токены и инфру, и насколько это сравнимо с отдачей от живых разработчиков, уровень которых продолжит стремительно падать.

Но что можно на 100% сказать про тот год, так это "everyone is a junior engineer when it comes to AI" + останется примерно на порядок уменьшившаяся в сравнении с сегодняшними техлидами прослойка элитных спецов с выросшими в десятки раз зарплатами. Какими именно характеристиками будут характеризоваться они, по секретику расскажу вам, дорогие, завтра 🤓

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

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

но есть нюанс-1: экономия в расходе токенов составляет примерно два порядка (миллионы vs десятки тысяч).

И есть нюанс-2: всем пофиг :)

Потому что токены сжигаешь корпоративные.

Соответственно даже скилл архитекторства/техлидcтва совсем скоро перестанет пользоваться спросом.

Возражения на это совершенно шаблонные и унылейшие: типа, а как же технический долг (сильная нейронка вполне его удержит), негибкая архитектура (да и плевать всем, главное сегодня выкатить фичу), главное в разработке это длительное сопровождение (сильная нейронка вполне его удержит-2), такая экономия токенов стимулируется рынком (ахаха:) наёмным менеджерам вообще плевать) и т.д.

Пока конечно вышеописанный техлид-подход актуален, но в основном потому что для бесчеловечного подхода пока всё же токенов требуется многовато, и не всё у нейронок получается норм. Но где-то в ближайшие пару лет всё то что я выше описал белковое превратится в типовой неорганический скилл, встроенный в каждой llm-ке.

Читаю разборки топовых американских математиков, как они друг друга хейтят "у тебя давно деменция" )))

Но в целом они сейчас реально объединяются категорически против AI, очень многие подписали Лейденскую декларацию:

"Компании, занимающиеся AI, и особенно MathInc ("Dedicated to verified superintelligence via autoformalization. Solve math, solve everything."), действительно подвергнут математику тщательной бомбардировке, чтобы превратить её в гигантскую радиоактивную пустошь, на которой больше никогда не сможет существовать жизнь, поэтому мы никогда не получим ожидаемых преимуществ от формализации математики."

На днях в военном агентстве передовых исследований DARPA прошёл семинар в рамках проекта expMath

"The goal of Exponentiating Mathematics is to radically accelerate the rate of progress in pure mathematics by developing an AI co-author capable of proposing and proving useful abstractions."

где присутствовал ряд этих академиков, и вот их итоговое мнение по обсуждению данной темки:

"это не было хорошо для военных; это не было хорошо для математики; это не было хорошо ни для кого."

"Математики больше не смогут участвовать в коллективных исследованиях, потому что любой открытый проект будет быстро завершён AI-агентами из конкурирующих компаний"

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

Ну а мы продолжаем заниматься формализацией всего программирования с целью его скорейшего превращения в "гигантскую радиоактивную пустошь, на которой больше никогда не сможет существовать жизнь" 🤓

на картинке: 216 символов, опровергнувшие гипотезу Римана (ai нашёл таки контрпример, реально иголку в стоге)

-2021: делать работу самому
-2024: сказать компьютеру, чтобы он делал твою работу
-2026: сказать компьютеру, чтобы он делал твою работу (но быть in a loop)
-2027+: безработный

буки казики как вариант:)
"Я в воскресение стану миллионером))) все деньги, мамин дом, поставил на стролла!!!"
(из сегодняшего чятика раскатки Формулы 1 в Венгрии; лэнс там уже заднюю подвеску ухитрился сломать :)

Продолжаю работу с ментатами 🤓

Почти ничего не делал именно в плане карьерного развития — основное внимание сосредоточил на успешном релизе приложения в продакшен...

HR очень сильно давила чтобы я принял оффер...

Очень много потратил времени просто на то, чтобы тесты запустились, так как был конфликт версий докера и библиотеки test-containers...

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

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

C одной стороны сегодня можно всё что угодно узнать у нейронки, причём с обратной связью, с другой стороны этим пользуется от силы 2% :) Поэтому у элиты (с блогами) (но и только у неё) всегда всё будет хорошо, особенно на фоне, что теория интересна от силы 2% от этих 2%.

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

Так-то мы многое подобное используем интуитивно и часто криво ("в каждой тыще строк твоего кода есть хотя бы одна монада"), цель Лаборатории как раз чтобы вытащить эти функциональные паттерны в сознание и получить кратный профит в кодинге. Только никакие книжки в этом не помогут, нужна оч. тесная теория+практика.

Если бы не была ясна идея и подводка к использованию ФП, я бы всерьёз задумался для чего это нам нужно, если задача действительно быстрее и проще решается классическим способом)

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

ФП применяйте сперва в рабочих задачах снизу: пишите чистые функции и комбинируйте их, и не смешивайте бизнес-логику с инфраструктурой для начала.

С ноутбуками знаком, со времён работы с МЛщиками, обычно их рабочие репозитории представляли собой огромные слабо-структурированные портянки)

Благодарю. Было крайне познавательно и интересно. Получил огромное удовольствие от структуризации полученных знаний (и приобретения новых :). Приобрел больше полезного опыта, чем за год работы до.
Очень благодарен за предоставляемые возможности для системного и глубокого образования. Такая редкость, что даже верится с трудом. С нетерпением жду, что дальше. Спасибо большое!

❤️

В рамках работы над Last Principles Framework познакомился с "-оидизацией": это когда мы допускаем существование некоторой фиговины  во множественном числе как сущности первого класса. Например у тебя есть моноид (монада - это моноид...), и таким превращением его (как целостной структуры) в моноидоид получаем моноидальную категорию (hom-множество само категория, а нафига это понимать программисту, разбираем на примерах в LPF: это каррирование в частности). Собственно, это ФП и есть: множество типов как объекты и функции как стрелки.
 
Далее, продолжая оидизацию, имеем моноидальный моноидоидоид :)

Ну, это всё  естественные преобразования теорката как функциональные паттерны:
трансформеры монад, линзы, оптики, разбираем их на первом курсе ФП (хотя в этом на самом деле от силы 2% функциональщиков/хаскелистов разбираются: они ещё более ленивые, чем мэйнстримщики:). Зато в работе с искусственным идиотом это всё дает мощные прорывы при составлении формальных спецификаций.
 
Но мы конечно пойдём дальше :)
 
Надеюсь вы заметили что на самом деле любую операцию можно обобщить: сначала на множество типов, потом на стрелки между стрелками, и таким образом мы можем проектировать бесконечно композируемые мета-абстракции.
 
Так, следующим шагом становится моноидальный моноидальный (не тафтология; подумайте, почему) моноидоидоидоид :)
 
Получаем преобразования между естественными преобразованиями (в продвинутых библиотеках эффектов, для формальной верификации...), но на самом деле мне это всё очень нравится прежде всего в том плане, что супер прокачивает "мышление (мета-)спецификациями" прежде всего.
 
Фишка же в том, что мета-паттерн
"когда у тебя есть тип данных, всегда можно сделать его параметрическим (обобщив до полиморфного типа или до тайпкласса например), надстроив новый уровень стрелок"
можно применять на всех уровнях!
 
А ФП - это всего лишь про обобщение максимум до 3-категории: через функторы монады естественные преобразования трансформеры оптики...

Дёшево писать код == дорого сопровождать и развивать код.

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

Внесение изменений в такой код обходится недёшево ровно потому, что сам код был прост в создании. Он будет дёшев только в том случае, если человек полноценно эээ овладеет этим кодом :)

Таким образом, разделительная линия -- это не "может ли агент это написать ". Это "можете ли вы в этом разобраться, и одобрить". Соответствует ли это вашим ожиданиям. Можно ли это протестировать. Хотите ли вы в будущем это развивать.

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

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

Выцепил сегодня у Кента Бека классную фишку: когда делаешь code review или pr-обзор, не тыкай прямо в ошибку, если такая есть. Подскажи, какой тут тест пропущен. Кодер не должен тупо фиксить тикеты, он должен думать прежде всего, быть хотя бы немножечко в контексте проекта.

Я так-то уже лет пять на моих курсах по АСД интуитивно ровно так и делаю: если человек не проходит своим решением тесты на учебном сервере и не понимает где у него ошибка, я даю тест какой надо сделать на его ошибку ("красный"). При этом "просто спросить" не разрешается, сперва в любом случае надо сделать тесты на свой вроде бы работающий код (условный "зёлёный"), так как хотя тесты и требуются, но их
особо никто не пишет (правда, в этом году я и наличие тестов теперь проверяю обязательно). И даже когда пишешь свой "зелёный", в 90% проблема обнаруживается "сама собой" :)

Но, да, здесь существует контринтуитивный разрыв между абсолютной стратегически пользой TDD, и непониманием этой пользы в повседневной практике. Например, мало того что вы автоматически получаете регрессионные тесты, вы также получаете минимум двух клиентов для вашего API (подумайте, почему), а между 1 и 2 пропасть огромная (ну, то у вас система работала на одном сервере, а то на двух - 23 - 256 - уже особо без разницы), и т.д.

Десятки других фишек от кента разберём с ментатами в СИ.

99,999999999999% программных систем чрезвычайно просты и не требуют новых и сложных решений.

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

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

Вы помните, когда вам в последний раз приходилось писать код?
Вы помните, когда вам в последний раз приходилось читать код?
Вы помните, когда вам в последний раз приходилось отлаживать код?
Вы помните, когда вам в последний раз приходилось делать code review?
Вы помните, когда вам в последний раз приходилось узнавать что-то новое в программировании?
Вы помните, когда вам в последний раз приходилось использовать свою память?
Вы помните, когда вам в последний раз приходилось использовать свой ум?

Мой 7-й гайд "Programming in Large" (по материалам СильныхИдей для ментатов), основной акцент на избавлении от зависимости от зависимостей.

Силлабус:

Избавляемся от зависимости от зависимостей
Сколько раз вы пытались удалить некоторую зависимость из проекта, но не были уверены, что сделали это успешно? Чтобы ваша кодовая база не зависела от чего-то конкретного? Или чтобы она "зависела от интерфейсов, а не от реализации"? Или старались следовать SOLID по инверсии зависимостей?

Избавляемся от зависимости от зависимостей - 2
Ключевой вопрос любой зависимости независимо от её типа, очевидно, такой: "Зависит ли А от B?".

Избавляемся от зависимости от зависимостей - 3
В первом материале по этой теме мы разобрали 9 видов зависимостей, а во втором материале изучили три характеристики любой зависимости, и как правильно о них думать. Теперь вернёмся к исходным 9 видам, и рассмотрим, как с ними разбираться. Но предварительно дадим точное и практическое определение зависимости.

Избавляемся от зависимости от зависимостей - 4
Итак, у нас есть универсальное определение зависимости. Рассмотрим теперь в его свете 9 типов зависимостей, причём в некоторых случаях мы получим ответ вида "это не зависимость, но часть зависимости".

Как извлечь пользу из сторонних зависимостей
Скорее всего, в вашем проекте имеется не одна зависимость от сторонних библиотек, на которые достаточно серьёзно опирается ваше приложение, но вы либо боитесь, либо по каким-то другим причинам не хотите (нету времени...) заглянуть под капот и изучить её исходный код.

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

Что такое баг?
Через некоторое время обнаруживается, что разработчики совершенно неправильно поняли интерфейс API...

Пишем безошибочный код с помощью Typestate-Oriented Programming
ООП позволяет достаточно хорошо моделировать мир, но основополагающим для качественного моделирования становится состояние объекта, которое, с другой стороны, частая причина ошибок и запутывания кода.

Логика бьёт порядок
Сценарии (прежде всего use cases и user stories) сегодня тотально доминируют в технических заданиях. Они опасны тем, что обманчиво хорошо смотрятся с точки зрения здравого смысла, однако не могут претендовать на универсальность прежде всего потому, что им не хватает абстракции, даже если мы предварительно тщательно формируем "проектную онтологию предметной области"...

Дополнительная сложность -- мать всех запашков кода
Я учу видеть такие недостатки в коде, которые большинство сочтёт безобидными, и программировать на более высоком уровне, чем многие вообще могут себе представить. Но, как ни странно, ещё труднее поднимать на такой уровень код.

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

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

=

12 материалов,
130 кб чистого текста,
цена до завтрашнего дня 1900 рублей,
купить на бусти

+ этот 7-й гайд добавлен в бандл (кто уже покупал бандл, просто скачайте и этот гайд себе бесплатно, и так и дальше будет с новыми - доплачивать не надо),
цена бандла пока старая 14999 рублей, завтра соответственно вырастет.

=

Предыдущие материалы (в бандле все эти материалы с большой суммарной скидкой + новый данный):
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-26
4. Вайб-проектирование
5. Software Design с акцентом на Programming in Large
6. Programming in Large: продолжение
7. this :)

Сегодня каждый должен делать свою работу только на vps с arch linux.
Никто больше не должен писать код локально, это просто глупо.

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

И именно программные сервисы, а не программные продукты - API-as-a-Service, и желательно не в json, а в более структурированном и при этом более компактном формате, например toon.

Почему? Потому что к 2030-му 98% пользователей софта будут AI-агенты, а нафиг им нужен твой UI? Им подавай Network APIs.

opencode - лучший опенсорсный AI-агент для кодинга
opencode - продукт с 7,5 миллионами пользователей в месяц
opencode - репа на гитхабе со 188 000 звёздами
opencode - компания с одним лысым инди-хакером

p.s. а я ведь говорил месяц назад: пилите ai-джуниора (и пофиг, что получится карго-культ :), всё остальное вторично.