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

[Bot]

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

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

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

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

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

Теория

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

Практика

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

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

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

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

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

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

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

Для просмотра скрытого содержимого необходимо Войти или Зарегистрироваться.