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

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

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

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

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

Спойлер: Программа

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

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

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

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

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

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

Теория

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

Практика

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

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

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

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

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

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

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

Пакет "Cлушатель"

Скрытая ссылка