Тренинг Евгения Кривошеева «Рефакторинг 2.0»

Ваш код неизбежно станет legacy. Это только вопрос времени. Как с этим жить?

Статичны только те системы, которыми никто не пользуется. Любая успешная система требует постоянной переработки. Но именно это и приносит основную боль развития системы. Начиная с определенного «момента Ж» белая и пушистая система вдруг превращается в образец костылестроения. И внесение небольшого изменения превращается в адовый квест. Это накопление технического долга убивает мотивацию инженеров и рентабельность проекта.

Ответом является практика рефакторинга — непрерывной поддержки внутреннего качества системы. Но бездумный рефакторинг может сжечь весь бюджет и еще больше ухудшить внутреннее и внешнее качество продукта. Поэтому в этом тренинге мы сфокусируемся на трех ключевых темах: осмысленность и целеполагание при рефакторинге, технические приемы его проведения и смена парадигмы мышления от «работает – не трогай» к «я всегда готов обеспечить качество при любых изменениях».
Если Вы хотите получать удовольствие от чистого понятного кода в своем проекте — этот тренинг для Вас.

Для кого

• Для инженеров:  разработчиков и архитекторов.
• Для техменеджеров: тимлидов и техлидов.

Опыт на старте

• Ожидаемый уровень участников: базовый и уверенный.
• Желателен опыт промышленной разработки от 2 лет.
• Обязательны навыки разработки модульных тестов
• Обязательны навыки проектирования

После тренинга участники смогут

• Осознанно выбирать время рефакторинга для обеспечения бесперебойной поставки продукта.
• Осознанно выбирать компоненты системы под рефакторинг для снижения затрат на поддержку внутреннего качества.
• Технически грамотно проводить рефакторинг, не внося дефектов.
• Непрерывно поддерживать внутреннее качество продукта: это снизит плотность дефектов и оставит под контролем время внесения изменений при длительном развитии продукта.

Программа

Постановка проблем

• Знакомство и сбор проблем участников
• Обзор тренинга
• Разбивка на команды и пары

Практика локализации и обоснования проблем в коде: итерация 1

• Предусловие: 
   - Кодовая база в системе контроля версий
• Критерий приемки:
   - Код покрыт тестами >30%
   - Выписаны файндинги по унаследованному коду
   - ​Обоснована природа проблем

Как рефакторинг обеспечивает внутреннее качество продукта

• Какие знаете внутренние атрибуты качества?
• Какие важные в Вашем проекте?
• Отобразите найденные файндинги на атрибуты качества

Типовые проблемы кода (code smells) и их системы для установки общего словаря

• Какие можете выделить типовые конкретные проблемы в коде?
• Какие системы проблем знаете?

Как влияют типовые проблемы кода (code smells) на внутреннее качество продукта

• Предусловие: дана система smells Фаулера
• Для каждого smell:
• Опишите симптомы
• Почему это проблема? Обоснование в терминах атрибутов качества.
• Когда это не будет проблемой?

Практика локализации и обоснования проблем в коде с использованием вспомогательных утилит: итерация 2

• Предусловие: 
  У каждой команды своя ветка от унаследованного кода
  По веткам команд настроена система CI
  По веткам команд настроен Sonar с профилем PMD + CheckStyle + FindBugs
• Критерий приемки:
  Код покрыт тестами >50%
  Выписаны файндинги в унаследованном коде по словарю smells
  Выписаны файндинги в унаследованном коде по словарю Sonar с профилем PMD + CheckStyle + FindBugs
  Обоснована природа проблем

Как не позволить техническому долгу загнать проект в «точку Ж»

• Как Вы сформулируете понятие технического долга?
• Когда проводить рефакторинг?
• Что именно рефакторить?
• Как обосновать ресурсному менеджменту необходимость рефакторинга?

Live coding demo: использование IDE для ускорения и повышения качества рефакторингов

Практика рефакторинга малыми шагами для обеспечения внутреннего качества: итерация 3

• Предусловие:
   - Код покрыт тестами >50% по ветвлениям
   - Файндинги обоснованы и приоритезированы через атрибуты качества
• Критерий приемки: 
   - Исправлены ключевые файндинги
   - Изменилась к лучшему статистика в Sonar
• Каков был размер изменений?
• Какие именно изменения проводились (в терминах ООП)?

Как сделать рефакторинг осмысленным и направить его на повышение внутреннего качества, а не делать ненужную работу

• Опишите последний рефакторинг
• Обоснуйте, почему он полезен

Системы приемов рефакторинга для установки общего словаря

• Обобщите операции, сделанные на практике в терминах ООП
• Как эти рефакторинги меняют метрики дизайна и кода?

Конкретные виды рефакторинга и как их правильно проводить

• Предусловие: дана система рефакторингов Фаулера
• Для ключевых рефакторингов:
• Опишите действие
• Как меняются метрики дизайна?
• Как меняются атрибута качества?

Практика рефакторинга для обеспечения внутреннего качества: итерация 4

• Критерий приемки: 
   - Исправлены ключевые файндинги
   - Изменилась к лучшему статистика в Sonar
   - Рефакторинги обоснованы
• Какие рефакторинги проведены?
• Как изменились атрибуты качества?

Практика рефакторинга для обеспечения внутреннего качества: итерация 5

• Действительно ли код стал поддерживаемым?
• Общие проблемы, которые остались.

Как проводить рефакторинг проблемного, нетестопригодного унаследованного кода с минимальными затратами

• Обобщите проблемы, возникшие при рефакторинге унаследованного кода
• Предложите шаблоны работы с унаследованным кодом

Что взять с собой на тренинг
Ноутбук с предустановленными продуктами:

• JDK
• Java IDE
• Maven
• Git client

В чем отличие от других тренингов по рефакторингу

​Практическая работа участников абсолютно прозрачна — вся группа видит свои результаты в системе continuous integration и статических анализаторах кода. Это позволяет оценивать ценность от рефакторинга сразу же. Так же участники поймут важность рефакторинга на своем личном опыте — участники будут поддерживать код друг друга и короткая обратная связь от коллег в виде пары ласковых будет эффективнее любой длительной теории.

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

О тренере

Евгений Кривошеев консультирует компании TOP-50 из российского IT в направлении улучшения эффективности и гибкости ИТ-подразделений. Сторонник внедрения гибких процессов «снизу», посредством распространения инженерных практик и осознанного подхода к проектированию.

В прошлом — архитектор в крупных коммерческих проектах. Имеет более чем семилетний опыт преподавания технологий на платформах J2SE, J2EE, BEA Systems, IBM и параллельной разработки. Отличительная черта — объединение широкого кругозора и практических приемов, полученных в реальных проектах. Способен донести сложные технологические знания самому широкому кругу слушателей. Тренер компании ScrumTrek, в настоящее время активно развивает проект SkillTrek.