Перейти к основному содержимому
DevScallix

Как мы учим

Learn. Build. Review. Defend. Ship.

Программированию нельзя научиться, наблюдая. Мы учим так, как работают команды: код пишут, проверяют, объясняют и сдают в рабочем состоянии.

Метод

Вы учитесь, работая как инженер, а не просматривая видео.

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

  1. 01

    Learn

    Вы изучаете тему с преподавателем — сначала «почему», потом «как».

  2. 02

    Build

    Сразу превращаете её в рабочий код. Задания похожи на реальные требования.

  3. 03

    Review

    Ваш код проверяют как Pull Request. Вы получаете конкретную обратную связь и улучшаете его.

  4. 04

    Defend

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

  5. 05

    Ship

    Вы сдаёте работу законченной, протестированной и работающей — а не «почти готовой».

Каждый цикл усиливает следующий. Со временем в этом и есть смысл Scale: системы больше, ответственность больше.

Code Review

Как проверяют ваш код

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

  1. 01

    Отправить Pull Request

    Вы сдаёте задания как Pull Request на GitHub — так, как работают команды.

  2. 02

    Конкретная обратная связь

    Объяснённые комментарии о названиях, структуре, тестах, обработке ошибок и дизайне.

  3. 03

    Итерации

    Вы дорабатываете код по обратной связи — здесь и происходит основное обучение.

  4. 04

    Защита

    Вы объясняете, почему сделали именно так. Обсуждаем альтернативы и компромиссы.

Инженерные доказательства

Вот как выглядит настоящая инженерия.

Три коротких учебных примера: code review, инженерное решение и доведение кода до работающего состояния. Через это проходит каждое задание программы.

PR #27 · Найти заказ по id

OrderService.java

public Order findOrder(Long id) {
Удалено: return repository.findById(id).get();

Ментор

`.get()` бросает NoSuchElementException, если заказа нет, и пользователь видит 500. Бросьте понятное исключение, чтобы API вернул 404.

Добавлено: return repository.findById(id)
Добавлено: .orElseThrow(() -> new OrderNotFoundException(id));
}

OrderServiceTest.java

Добавлено: @Test
Добавлено: void throwsWhenOrderIsMissing() {
Добавлено: assertThrows(OrderNotFoundException.class,
Добавлено: () -> service.findOrder(42L));
Добавлено: }

Ментор

Хорошо. Этот тест защитит поведение, когда кто-то в следующий раз изменит метод.

Почему попросили это изменение

  1. Пользователь получает понятный ответ: 404, а не 500.
  2. Название исключения само объясняет проблему.
  3. Тест защищает это поведение от будущих изменений.

Учебный пример · не работа реального студента

Туториал против реальной инженерии

Туториал спрашивает «работает ли?». Инженер спрашивает больше.

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

Requirements
Туториал: Повторить шаги
Реальная инженерия: Понять задачу, уточнить требования
Trade-offs
Туториал: Есть один правильный ответ
Реальная инженерия: Сравнить варианты, обосновать выбор
Clean Code
Туториал: Работает — и ладно
Реальная инженерия: Другой человек должен суметь прочитать и изменить
Testing
Туториал: Один раз проверить руками
Реальная инженерия: Защитить поведение автотестами
Code Review
Туториал: Никто не смотрит
Реальная инженерия: Каждое изменение читают и обсуждают
Architecture
Туториал: Всё в одном файле
Реальная инженерия: Разделить ответственность, провести границы
Deployment
Туториал: У меня работает
Реальная инженерия: Работает одинаково везде
Observability
Туториал: Угадывать, когда сломалось
Реальная инженерия: Видеть происходящее по логам и метрикам

Learn. Build. Scale.

Подайте заявку в первую группу Java Backend.

Первая группа будет небольшой, её ведёт основатель. Заявка не обязывает платить.