Сергей Калабонга

Стоит ли сегодня начинающему разработчику вообще изучать паттерны проектирования и DDD, если ИИ-инструменты всё чаще сами предлагают структуру решения?

Стоит, и даже больше, чем раньше — тем лучше. ИИ-инструменты предлагают структуру решения на основе шаблонов, которые уже где-то видели, — но не умеют объяснить, почему именно этот паттерн подходит вашей задаче, а не соседний. Без базового понимания DDD и паттернов проектирования разработчик не сможет отличить удачную подсказку от той, что превратит проект в набор случайных абстракций.

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

Знание паттернов и DDD — это как раз тот словарь, на котором можно вести содержательный диалог с ИИ-инструментом, а не просто принимать его вывод на веру.

мысли

Sep 22 04:14

Основные типы моделей ИИ и их применение

А задумывались ли вы, какие еще бывают типы моделей?

Level required:

Простой

models

classification

Sep 21 07:46

Полезные советы: Claude Projects

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

Level required:

Простой

claude

мысли

советы

Sep 19 09:37

Подключаем Claude Code к новому проекту

Я хочу в этом видео показать, что я делал и как, чтобы подключить к старому проекту ИИ-агента (Claude Code).

Level required:

Продвинутый

claude

nuget

Sep 18 09:26

Какую архитектурную ошибку вы допускали чаще всего за карьеру — и как теперь, зная DDD и Clean Architecture, спроектировали бы то же самое иначе?

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

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

Сейчас, применяя предметно-ориентированное проектирование (Domain-Driven Design) и чистую архитектуру (Clean Architecture), я закладываю границы контекстов (bounded contexts) и явные интерфейсы между слоями с самого начала — даже если проект выглядит небольшим.

Это кажется избыточным в начале проекта, но именно оно спасает через полгода, когда в проекте появляется третий разработчик и вторая интеграция.

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

мысли

Sep 18 06:13

Приятные вещи: ИИ отвечает "всё понятно"

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

И смотрит на эту задачу, изучает и в конце концов выдает фразу: "всё понятно, подтвердите реализацию".

мысли

Sep 15 09:25

Меняет ли ИИ роль архитектора: если нейросеть может сгенерировать код по паттерну, в чём теперь главная ценность разработчика с большим опытом?

ИИ действительно неплохо справляется с типовым кодом — контроллером по шаблону, DTO, простым CRUD-сервисом. Но он генерирует код на основе того, что его попросили, а не на основе понимания, зачем это нужно бизнесу и как это будет жить через два года после релиза.

Именно здесь и остаётся роль архитектора (разработчика): перевести "расплывчатое" требование в "границы контекста" (bounded context), понять, где действительно нужна очередь (queue) и гарантии доставки (delivery guarantees), а где это избыточная сложность.

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

Я всё чаще воспринимаю ИИ как очень быстрого, но совершенно неопытного стажёра: writes fast, но ответственность и итоговое решение — на мне.

мысли

Sep 13 08:23

Как за 35+ лет в разработке изменился сам процесс написания кода — и что из старых практик (Pascal, Clipper, FoxPro) неожиданно оказалось полезным даже сегодня?

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

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

С того времени неожиданно полезной оказалась дисциплина работы с ограниченными ресурсами. В FoxPro и dBase IV нельзя было просто «закинуть побольше памяти на проблему» — приходилось заранее продумывать структуру данных и алгоритм.

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

мысли

Sep 12 09:21

Настройка ИИ-агента Claude Code (3 из 3)

В этом видео покажу примеры технического задания (ТЗ), которые я пишу для Claude Code.

Level required:

Продвинутый

claude

настройки

Sep 05 09:18

Настройка ИИ-агента Claude Code (2 из 3)

Чтобы экономить токены, нужно задавать правильные запросы. Чтобы описание работы было более понятным для Claude - нужны правила!

Level required:

Продвинутый

claude

настройки

rules

Showcase and bundles

About

Стоит ли сегодня начинающему разработчику вообще изучать паттерны проектирования и DDD, если ИИ-инструменты всё чаще сами предлагают структуру решения?

Какую архитектурную ошибку вы допускали чаще всего за карьеру — и как теперь, зная DDD и Clean Architecture, спроектировали бы то же самое иначе?

Приятные вещи: ИИ отвечает "всё понятно"

Меняет ли ИИ роль архитектора: если нейросеть может сгенерировать код по паттерну, в чём теперь главная ценность разработчика с большим опытом?

Как за 35+ лет в разработке изменился сам процесс написания кода — и что из старых практик (Pascal, Clipper, FoxPro) неожиданно оказалось полезным даже сегодня?

Простой

Продвинутый