codemonsters.log

Привет.
Две книги, на которые не жалко ни одной из четырёх тысяч недель.

Первая — «Четыре тысячи недель на всё». Оливер Беркман объясняет, почему попытки всё успеть — ловушка. И предлагает смотреть на время иначе.
Не как ресурс, который надо оптимизировать, а как ограничение, с которым стоит подружиться.
В сущности, я и есть время. Несмотря на то, что я старался держать мысли о конечности жизни в оперативке(вспоминал Хагакурэ), последние два года изрядно выбили из меня всю дурь.
Я иначе смотрю на своего пса, которому 9 лет — и времени вместе осталось не так много.
Я вернулся к вопросу: а чего хочу действительно я? Что мне дорого?

Обожаю мысленный эксперимент: как бы я провёл последний день на этой прекрасной планете?

Пошёл на Физикл 3.0, добавил больше прогулок, активности, силовых. Хочу выстроить для себя в систему адекватный ЗОЖ.
Недель у меня не так много. Хочу прожить и качественно. Энергии прибавилось, настроение улучшилось.

Вторая — «Как устроен мир на самом деле». Вацлав Смил настойчиво снимает розовые очки и показывает, на чём мир реально держится. Сталь, бетон, аммиак, энергия.
Без этого ни электромобили, ни ИИ — ничего нам не скажут.

После прочтения берегу две эти книги.

Если читал — поделись в комментах: чем тебя зацепила книга? Что изменил в своей жизни?

#codemonsterslog

Увлекательная статья

https://cursor.com/blog/self-driving-codebases

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

Увлекательный отрывок словно из соцреализма

Когда мы требовали 100% корректности перед каждым коммитом, это приводило к серьёзным проблемам с сериализацией и замедлению эффективной пропускной способности. Даже одна небольшая ошибка, например, изменение API или опечатка, могла привести к полной остановке всей системы. Рабочие выходили за рамки своих полномочий и начинали исправлять несущественные вещи. Множество агентов набрасывались друг на друга, пытаясь исправить одну и ту же проблему.

#vibe

Математическое доказательство корректности программ

Собрал очень ценную статью про математическое доказательство правильности программы и формальное доказательство, которое мы используем при кодировании. https://codemonsters.team/blog/2025/12/30/program-correctness/

Для меня это особенно важная работа.

Показывает, как от математики мы переходим к инкапсуляции в ООП и типизации (формальному доказательству)

Правильная архитектура даёт нам 100% покрытие бизнес-логики юнит-тестами. Управляемое тестирование, а не тестирование ради процентного покрытия.

Взгляд на пирамиду тестирования уточняется.
Компонентные тесты превращаются в точную верификацию API, а не попытку протестировать крайние точки. Т.е. так мы можем на простом языке описать инструкцию к API нашего черного ящика, которая будет тестироваться автоматом и тут BDD раскрывается в полную силу.
Я напишу далее про это с отсылками к трудам отцов основателей.


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

Бежим дальше.

#codemonsterslog

Модульность программы: как писать код, который не превратится в хаос

  Модуль — это последовательность логически связанных фрагментов кода, оформленных как отдельная подпрограмма (функция, класс, сервис).

  Ключевой принцип: один модуль — одна функция.

  5 главных правил модульного кода:

  1. Один вход, один выход — модуль должен возвращать управление тому, кто его вызвал
  2. Небольшой размер — обычно 20-200 строк. Если больше — разделяй
  3. Единственная ответственность — функция модуля должна выражаться одной фразой: "Валидировать email", "Создать карточку клиента", "Вычислить возраст"
  4. Вертикальное управление — модуль может вызывать только подчиненные модули уровнем ниже. Главные решения принимает головной модуль
  5. Черный ящик — вызывающий модуль не должен знать о внутреннем устройстве вызываемого

  Почему это важно:
  - Проще тестировать
  - Легче вносить изменения
  - Меньше багов
  - Код можно переиспользовать

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

  Головной модуль — это краткий конспект всей программы.

 Читать полностью: ссылка на статью

https://codemonsters.team/blog/2025/12/15/program-modules/

#codemonsterslog

В конце года в 4-м квартале мы запустили Бэкенд Академию для аналитиков и тестировщиков, чтобы переквалифицировать сотрудников в бэкенд инженеров и дать возможность развиваться по бэкенд треку.
Для меня это стало настоящей отдушиной в конце необычного и классного года.
Я люблю инженеров и видеть рост компетенций у ребят - это большая радость.
Меня это сильно заряжает и мотивирует.

Я собрал команду единомышленников, мы провели первичный отбор из 67-ти инженеров отобрали 26.
Выстроили и постоянно улучшаем процессы, например процесс поэтапной аттестации, чтобы отслеживать насколько качественно усваивается материал и выполняются домашки.
Наша цель на выходе получить настоящих инженеров.
Программу построили от теории к практике, так как я убежден, что универсальные теории студенты смогут применять в карьере вне зависимости от стека.
Обучение построено по стандарту, который мы разрабатываем в параллель с инженерами.
От API First, Doc as Cod, до компонентных тестов и качественного проектирования софта до установки в кубер и сопровождения.
Про тестирования мы отдельно даем теорию и практику, чтобы инженер понимал, что от количества тестов качество софта не зависит. Что писать код программы и код тестов нужно меньше - так как это работа, которая стоит денег, а мы строим эффективное производство при котором меньше пишем, больше катим и меньше ошибаемся, а если ошибаемся и роняем, быстро поднимаем.

Про мифы тестирования и введение в структурное программирование собрал материал из классических трудов отцов основателей, просто понятно раскрыта суть вопроса без лишних модных терминов.
https://codemonsters.team/blog/2025/12/12/structured-programming-essential/

Дай пять.🙌

#codemonsterslog

https://youtu.be/mfv0V1SxbNA?si=-1iRVOo0xTJYLob1

Linus собирает Linus-у комп и обсуждает много тем
#vibe

Spec-driven development: программируем через спецификацию

Сначала была лаконичная спецификация. Потом был код на Go.
Без some-driven development сейчас ты не девелопер.

Наткнулся на статью, которая отлично дополняет мой эксперимент по кодированию с ИИ. Я тоже описывал задачу в README машине — и это работает.

Написать лаконичную спецификацию перед тем, как начнёшь кодить — правильный цикл разработки.
Причём сейчас, в эпоху ИИ-ассистентов, это не просто best practice, а рабочий инструмент.

Я заметил, что многие привыкли работать без предварительных «зарисовок» и описания желаемого результата.

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

Цикл разработки прост:

1. Отредактируй спецификацию в main.md или README.md
2. Попроси ИИ-агента скомпилировать её в код Go
3. Запусти и протестируй приложение
4. Если что-то работает не так — обнови спецификацию

Повторяй, пока не получишь нужный результат.

Подробнее: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-using-markdown-as-a-programming-language-when-building-with-ai/

#codemonsterslog #dev2dev

🚀 Со-творчество с машиной: как я создал валидатор контрактов без единой строки кода

Представьте: инженер надевает "костюм супергероя" в 5 утра, садится за Claude терминал и за 10 часов создает production-ready инструмент на Go с 300+ тестами, НЕ НАПИСАВ НИ ОДНОЙ СТРОКИ КОДА вручную.
Научная фантастика? Нет, реальность 2025 года.

🎯 Суть эксперимента:
Вместо Pact создал с машиной валидатор контрактов между микросервисами по AsyncAPI 3.0 спецификациям.

Идея простая: зачем писать дополнительные pact тесты в BDD-стиле, если спецификации уже содержат всю информацию о контрактах?

💡 Ключевые открытия:

TDD + ИИ = магия
- Маленькие итерации от тестов к коду
- Машина обнаружила 2 критических бага в процессе
- Ноль переписываний благодаря четкому проектированию модулей и структур сообщений для модулей

Проектирование решает всё
- Схемы иерархии модулей на бумаге
- Псевдокод основной функции
- Railway-oriented Programming для обработки ошибок, для упрощения потока программы
- "Один модуль — одна функция"

Роль инженера меняется кардинально
Из кодировщика в архитектора: формулируешь техзадание, рисуешь схемы, валидируешь результат. Машина делает всю рутину.

🔥 Результат:
Полнофункциональный валидатор контрактов с модульной архитектурой, исчерпывающим тестированием и стандартизированной обработкой ошибок. Готов к production.

💭 Главный инсайт:
Принципы структурного программирования 70-х + современные ИИ-ассистенты = мощнейшая комбинация.
Качественное проектирование становится единственным критическим навыком.

Читать статью

Мы живем в уникальном срезе реальности, где сбываются мечты программистов о "средствах автоматизации кодирования" из 1973 года.

Читать код валидатора контрактов

#codemonsterslog

Вирт:

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

Дорабатываю фрагмент статьи, нашел прекрасную цитату.

Всем хорошего дня.

#codemonsterslog

Митап о первоисточнике истины: как мы меняем подход к документации

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

Говорили про Doc as Code — подход, когда документация живёт рядом с кодом и обновляется вместе с ним.

Мы меняем устоявшиеся привычки и становимся современным финтехом.

На митапе инженеры:
- Показывали реальные примеры качественного описания сервисов и спецификаций
- Демонстрировали генерацию кода по OpenAPI, Async Api спекам
- Рассказывали, как каталог софта (Backstage) упрощает навигацию по ИТ-ландшафту компании

Формат изменился — стало меньше абстрактных вопросов и больше практики. Инженеры отвечали на вопросы коллег, показывали живые примеры из своих проектов, на деле демонстрировали, как работают новые подходы.

55 человек оффлайн

Онлайн:
Уникальные зрители более 700
Всего просмотров 1 322

крутится мысль

Сижу в такси после митапа, смотрю в окно и радуюсь.

5 лет назад я недоумевал: почему в корпоративной культуре не используют практики из open source сообщества? Почему не делают как на GitHub зрелые проекты?
И вот мы внедряем именно такие подходы в Газпромбанке.
Пишем документацию в Git. Больше не нужно блуждать по ресурсам среди устаревших страниц и собирать контекст.

Не нужно придумывать велосипеды — лучшие практики уже отработаны сообществом.

Если тебе интересно следить за трансформацией ИТ в ГПБ — подписывайся на наш Telegram-канал.

P.S. Мне очень нравится этот бульдоня. Розовый ему определённо идёт. Стиль.

#codemonsterslog

Проводим митап по Doc as Code

Классная атмосфера
Интересные актуальные доклады ребят из команд.
Многие выступают впервые.

Наконец-то. 💥

#codemonsterslog #vibe@codemonsterslogs

День прокрутил на хорошей скорости

С пленки вайб идёт по проводам
Продолжаю писать

Ты стримовый или аналоговый звук слушаешь?

#codemonsterslog #vibe@codemonsterslogs

Я помню, когда я прочитал доклад несколько лет назад про ROP и программирование на типах в пустой колодец. Инженеры просто молчали. А ведь это крайне полезные подходы.

Недавно один инженер мне рассказывал о подомном случае, когда аудитория не реагирует на важные простые технические концепции.

ROP (Railway-oriented Programming) и программирование на типах действительно очень полезные подходы, особенно для создания надежного кода.

из серии: воспоминания деда

#codemonsterslog

Вчера я прочувствовал всецело "кость в горле".

Подавился костью рыбы. Так было больно, одновременно досадно саднило. И вдохновило.

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

Курица кажется безопаснее.
Она не пытается меня убить из тарелки.
С другой стороны: мою собаку убивает сильная аллергия на курицу.
Мы окружены, Гарри.

Ты давился костью рыбы? На сколько она была большая?
Я в этот раз задумался и пропустил большую.
Ты так не делай. Будь в моменте))

#codemonsterslog

Растворился в множестве потоков и притаился

1. Подготовил интересную программу Бэкенд академии для QA инженеров.
Доволен результатом. Будет левел ап.

Собрал крутую команду кураторов для студентов

Это невероятно интересный вызов.
Круто, что есть запрос на переквалификацию в организации и мы на него отвечаем положительно.

2. Дописываю статью про то, как за 12 часов спроектировал с машиной инструмент для проверки контрактов сервисов

3. Снял немного видео как катался в Байк-Парке Архыз
Осталось его смонтировать. Как же там красиво.

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

#codemonsterslog