Почему IT Smetanin не для новичков: что получит middle в проде

Коротко. IT Smetanin — для тех, кто уже пишет боевой код и хочет навести порядок в архитектуре: где жить логике, как не раздувать классы, как объяснить решение на ревью и на собеседовании. Синтаксис с нуля здесь не учат.

Узнаёте себя?

Вы закрываете задачи в трекере. На ревью спорят не о точке с запятой, а о границах: может ли контроллер знать правила публикации поста, может ли React-компонент тянуть данные из базы напрямую. На собеседовании просят за две минуты объяснить компромисс: показать пользователю успех сразу или дождаться ответа сервера. В проде падает не функция map(), а связка «запрос → сервис на 800 строк → хранилище без договорённостей».

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

Кому подойдёт

• Middle — уже в проде, но непонятно, с чего начать приводить код в порядок.
• Senior — делаете правильно на глаз, трудно объяснить команде без «так принято».
• Tech lead — нужен общий словарь для ревью и онбординга.

Такой разработчик не ищет справочник «что делает array_map». Ищет ответы: где жить логике, как не раздуть один класс на всё, как выкатить фичу без остановки сайта.

Кому пока рано

• Не писали код в команде — нужен синтаксис и первый pet-проект, не архитектура.
• Хотите «выучить React за месяц и идти на middle» — на собеседовании спросят про границы модулей, а не про хуки.
• Пока не держали в голове связку «форма → сервис → база» на реальной задаче — сначала нужен опыт закрытия тикетов в команде, не карта паттернов.

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

Неделя middle без общего языка

Понедельник: задача «добавить статус заказа». Вы кладёте проверку в сервис — коллега в тот же день пишет её в контроллер, потому что «так быстрее». Среда: на ревью двадцать комментариев, половина про стиль, половина про границы, ни один не ссылается на принцип. Пятница: баг в проде — правило скидки продублировали на фронте и в админке, цифры разошлись.

Вы не ленивы и не «плохой разработчик». У команды нет общего словаря: что считать бизнес-правилом, что — деталью интерфейса, где заканчивается ответственность модуля. Без этого каждый спор превращается в вкусовщину, а рефакторинг откладывают, потому что «и так работает».

Именно эту боль закрывает обучение для middle+: не «ещё один синтаксис», а язык, на котором можно договориться на ревью и не бояться переписать кусок живого кода.

Какие решения вы принимаете каждый день

Даже задача «добавить поле в форму» — это на самом деле выбор:

1. Проверка в запросе, в сервисе или «пока в контроллере»?
2. Состояние на фронте — в хранилище, в сервисе или в компоненте?
3. Один формат ответа API для фронта и тестов или «фронт подстроится»?
4. Выкат через флаг или «смержим и посмотрим»?
5. Чинить старый модуль до фичи или после?

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

Возьмём ту же «форму с полем». Junior спросит: «какой компонент поставить». Middle без системы спросит: «куда положить валидацию». Middle с каркасом спросит: «какое правило домена мы проверяем, кто владеет изменением статуса, какой контракт у API, чтобы фронт и тесты не разъехались». Разница — не в стаже, а в привычке видеть границы до первой строки кода.

Чем это не туториал и не справочник

Туториал отвечает на «как вызвать метод». Справочник — на «что делает хук». Ни то ни другое не отвечает на вопросы из продакшена: можно ли дергать почту из модели, стоит ли тащить DTO через пять слоёв, когда оправдан флаг выката, а когда — отдельная ветка.

YouTube-ролик про «чистую архитектуру за вечер» показывает идеальную картинку на зелёном поле. В вашем репозитории — три года компромиссов, легаси-таблица без индекса и дедлайн в пятницу. Нужен не пересказ теории, а порядок действий: что трогать первым, что оставить, как объяснить команде без магических слов «так принято».

IT Smetanin заточен под второй тип задач. Вы не переписываете монолит за выходные — вы учитесь читать свой модуль как инженер и менять его по шагам.

Чему учат на платформе

Не «выучить 23 паттерна наизусть», а четыре навыка:

1. Видеть границы — где заканчивается бизнес-логика и начинается инфраструктура.
2. Выбирать компромиссы — быстрый минимальный продукт (MVP) или платформа; скорость релиза или проверки.
3. Чинить живой код — по частям, не переписывая всё за неделю.
4. Защищать решения — на ревью и на собеседовании.

Маршрут по уровням:

  SOLID ──► Паттерны ──► Антипаттерны ──► MCDDP
    │           │              │              │
    └───────────┴──────────────┴──────────────┘
         практика на своём модуле на каждом шаге

Берёте один модуль своего проекта — blog, billing, progress — и смотрите на него глазами принципов, а не переписываете весь репозиторий. Разборы на ошибках из реальных проектов, не пересказ Wikipedia.

По уровням это выглядит так:

• SOLID — называете, почему класс раздулся, и режете ответственность без «перепишем всё».
• Паттерны — узнаёте повторяющиеся схемы в своём коде и не изобретаете велосипед в каждом модуле.
• Антипаттерны — видите, где вы уже платите проценты: god object, связность через глобальное состояние, «умный» UI.
• MCDDP — собираете картину модуля целиком: границы, данные, деплой, наблюдаемость.

Каждый шаг привязан к практике на вашем коде, а не к абстрактному репозиторию с котиками.

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

Типичная ошибка после просмотра лекций — «надо всё переделать». На middle+ это убивает спринт. Рабочий подход другой: выбираете один модуль с понятной болью — каталог, оплата, уведомления — и проходите уровень на нём.

На SOLID вы находите один класс, который «знает слишком много», и выносите одно правило. На паттернах — заменяете копипасту одним явным механизмом. На антипаттернах — фиксируете то, что уже мешает релизам. На MCDDP — рисуете схему «кто с кем говорит» и сверяете с реальностью.

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

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

Что изменится после месяца на SOLID

Если вы в проде и проходите первый уровень на своём модуле:

• на ревью называете принцип, а не «так красивее»;
• видите, где один класс делает слишком много, и знаете порядок правок;
• на собеседовании говорите про компромиссы, а не список технологий из резюме.

Это не сертификат. Это навык читать и менять архитектуру осознанно.

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

Плохой код: всё в контроллере

Типичная картина в проде: HTTP-обработчик делает всё сам.

  Запрос HTTP
       │
       ▼
┌──────────────────────────┐
│      Контроллер          │
│  проверка прав           │
│  запись в БД             │
│  рассылка, SEO, кэш...   │  ← всё в одном месте
└──────────────────────────┘

// Плохо: контроллер решает всё сам
public function store(Request $request)
{
    $data = $request->validate(['title' => 'required', 'body' => 'required']);
    if ($data['status'] === 'published' && ! auth()->user()->can('publish')) {
        abort(403);
    }
    $post = Post::create([...$data, 'author_id' => auth()->id()]);
    if ($post->status === 'published') {
        event(new PostPublished($post));
    }
    return response()->json($post);
}

Без границ каждая новая интеграция раздувает контроллер. Завтра добавят SEO — снова сюда. Потом webhook из CRM — снова сюда. Через полгода файл на триста строк, и никто не решается трогать проверку прав, потому что «всё сломается». Именно такой код чаще всего приносят middle: он работает, но не масштабируется людьми.

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

Хороший код: тонкий вход, правила отдельно

  Запрос HTTP
       │
       ▼
  Контроллер ──► Сервис публикации ──► Правило «можно ли»
       │                  │
       └──────────────────┴──► База

// Хорошо: HTTP только передаёт команду
public function store(StorePostRequest $request, PublishPostUseCase $useCase)
{
    $post = $useCase->execute(
        PublishPostCommand::fromRequest($request, auth()->id())
    );
    return PostResource::make($post);
}

Правило публикации — отдельно, сервис можно проверить без HTTP, контроллер не растёт от каждой новой интеграции.

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

Так выглядит разница между «знаю синтаксис PHP» и «умею проектировать модуль в проде». Первое не спасает от раздувания. Второе — то, за что middle+ платят и что проверяют на собеседовании.

Три признака, что вы уже на своём уровне

Первый: вы читаете чужой pull request и видите не «мне не нравится», а «здесь смешаны два повода для изменения». Второй: вам скучны задачи «сделай кнопку», но интересны «разведи ответственность, чтобы завтра не ломать соседний модуль». Третий: на созвоне вы уже объясняете компромисс словами «быстрее сейчас / дороже потом», а не молчите или ссылаетесь на «так принято».

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

Обратная сторона тоже важна: senior, который «и так всё знает», часто находит здесь язык для команды — как объяснить джуну, почему нельзя тащить SQL в компонент, без лекции на час. Tech lead получает общий чеклист для ревью: не вкус, а проверяемые границы.

Как ответить на собеседовании за минуту

«Я не junior: в проде веду фичи end-to-end. IT Smetanin даёт не синтаксис, а каркас — SOLID, паттерны, антипаттерны, MCDDP — чтобы осознанно проектировать модули. Плюс разбор собеседований и компромиссов для middle+.»

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

Следующий шаг. Если узнали себя — начните уровень 1 (SOLID) в разделе курсов.