Дизайн Rails-приложений: как победить монстра

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

Знание принципов хорошего дизайна кода и методов их достижения поможет вам:

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

Программа:

День 1. Дизайн Rails-приложений. Верхний уровень

Что такое дизайн приложения, какой дизайн считается хорошим. Чем хорошее рельсовое приложение отличается от другого хорошего приложения.
Как удерживать сложность на низком уровне.
Почему большие приложения не могут быть простыми: accidental complexity и essential complexity.
Как язык влияет на дизайн приложения.

Уровень кода приложения

Именование классов, именование методов.
Разбор реализации биллинга в приложении. От монолитного класса до нескольких объектов.
Обзор паттернов проектирования: формы, фабрики, сервисы, middleware, воркеры

В результате вы:

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

День 2. Рефакторинг приложения

Теория

Рефакторинг — метод улучшения дизайна кода приложения
Когда стоит рефакторить приложение
Проектирование против рефакторинга
Как понять, когда нужно рефакторить конкретный метод, конкретный класс или переписать приложение?
Запахи в коде, инструменты для автоматического детектирования запахов
Хорошо спроектированное приложение с хорошим дизайном тоже нуждается в рефакторинге?

Практика

Рефакторинг сложного и длинного метода.
Рефакторинг большого класса.
Рефакторинг жирной модели.
Рефакторинг жирного контроллера.
Разбор примеров из зала.

В результате вы:

Разберетесь, что такое рефакторинг в контексте дизайна приложения.
Поймете, почему детальное проектирование не отменит того, что приложение нужно будет рефакторить.
Структурируете знания о запахах в коде.
Попрактикуетесь в рефакторинге и улучшении код-дизайна.

День 3. Системные решения для улучшения дизайна

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

В результате вы:

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

Тариф Слушатель:

Записи всех эфиров без домашних заданий

[Thinknetica] Дизайн Rails-приложений: как победить монстра. Тариф Слушатель [Алексей Наумов]