Сценарий учебного мероприятия "Мастерская рефакторинга: от legacy-кода к чистому модулю"

Мастерская рефакторинга: от legacy-кода к чистому модулю

Формат: учебная мастерская с элементами кейс-стади и публичной защиты принятых решений.
Дисциплина / МДК: «Разработка программных модулей», «Тестирование программного обеспечения» или смежные профессиональные модули.
Участники: студенты 2–4 курсов ИТ-специальностей СПО.
Продолжительность: 90 минут (одна пара) или 180 минут (сдвоенное занятие).

Цель: сформировать у студентов компетенции, связанные с анализом, рефакторингом и документированием существующего программного кода, а также развить способность аргументированно обосновывать предлагаемые улучшения.

Формируемые компетенции (в соответствии с ФГОС СПО)

Общие компетенции (ОК):

• ОК 01 (выбор способов решения задач в различных контекстах),

• ОК 02 (использование информационных технологий для поиска и анализа информации),

• ОК 04 (командная работа и эффективное взаимодействие),

• ОК 05 (устная и письменная коммуникация),

• ОК 09 (работа с технической документацией).

Профессиональные компетенции (ПК) — на примере специальности 09.02.07:

• ПК 1.1 (анализ и рефакторинг программного кода),

• ПК 1.3 (отладка программных модулей),

• ПК 1.4 (тестирование программных модулей),

• ПК 1.5 (оформление программной документации),

• ПК 4.2 (разработка кода на основе спецификаций в части улучшения существующего кода).

Связь с профессиональным стандартом 06.001 «Программист»: отработка трудовых функций, связанных с анализом и оптимизацией существующего кода, исправлением дефектов, документированием изменений.

Подготовка к мероприятию

Преподаватель заранее разрабатывает учебный кейс — программный модуль объёмом 100–150 строк кода, который решает некоторую прикладную задачу (например, работа с коллекцией данных, парсинг строк, простые вычисления), но обладает рядом преднамеренно внесённых проблем. Кейс должен быть единым для всех команд, чтобы в дальнейшем можно было сравнивать подходы к рефакторингу.

Проблемы, закладываемые в кейс, могут включать:

• Дублирование кода.

• Длинные функции с несколькими зонами ответственности.

• Неинформативные имена переменных и функций.

• Отсутствие обработки исключительных ситуаций.

• Избыточная вложенность условных конструкций.

• Комментарии, которые противоречат коду или описывают то, что очевидно.

• Отсутствие модульных тестов (или наличие тестов, покрывающих менее половины сценариев).

Также готовятся раздаточные материалы:

• Распечатка исходного кода модуля (или доступ к репозиторию).

• Краткое описание назначения модуля (как если бы оно было оставлено предыдущим разработчиком).

• Шаблон отчёта о рефакторинге.

• Чек-лист оценки качества кода.

• Оценочные листы для преподавателя.

Ход мероприятия

Этап 1. Введение и погружение в проблему (10 минут)
Преподаватель объясняет, что в реальной профессиональной деятельности разработчик значительно чаще сталкивается с необходимостью дорабатывать и улучшать существующий код, чем писать всё с нуля. Умение понять чужую логику, выявить проблемы, не сломав работающий функционал, и предложить обоснованные улучшения — ключевой навык, проверяемый в том числе на демонстрационном экзамене. Группа разбивается на команды по 3–4 человека, каждая получает одинаковый кейс.

Этап 2. Анализ исходного кода (15 минут)
Команда читает код и выполняет первичную диагностику. Задача — найти и классифицировать все проблемы, не изменяя пока ни одной строчки. Результат анализа фиксируется в виде списка замечаний с указанием конкретных мест в коде и причин, по которым они требуют исправления. На этом этапе преподаватель следит, чтобы студенты не увлекались косметическими правками, а действительно разбирались в логике работы модуля.

Этап 3. Планирование рефакторинга (10 минут)
На основе составленного списка команда определяет приоритеты: какие проблемы являются критическими (влияют на работоспособность или читаемость в наибольшей степени), а какие можно отложить. Результатом этого этапа становится краткий план рефакторинга, в котором зафиксирована последовательность шагов и ожидаемый результат каждого из них.

Этап 4. Выполнение рефакторинга (30 минут)
Команда приступает к реализации плана. Важное правило: все изменения вносятся небольшими порциями, и после каждого значимого шага проверяется, что модуль по-прежнему работает корректно. Если к кейсу прилагались тесты, они запускаются после каждого изменения. Если тестов не было, преподаватель заранее готовит несколько проверочных сценариев, которые студенты могут использовать для самоконтроля. Параллельно один из участников (в роли технического писателя) фиксирует все выполненные изменения для итогового отчёта.

Этап 5. Оформление отчёта о рефакторинге (10 минут)
Команда оформляет итоговый документ, который включает:

• Перечень обнаруженных проблем исходного кода.

• Описание выполненных изменений с обоснованием каждого.

• Сравнение фрагментов кода «до» и «после» для наиболее показательных улучшений.

• Вывод о достигнутых результатах (что улучшилось и почему).

Этап 6. Взаимное рецензирование (10 минут)
Команды обмениваются отчётами и рефакторированным кодом. Проверка осуществляется по чек-листу:

• Сохранена ли исходная функциональность?

• Действительно ли устранены все заявленные проблемы?

• Стал ли код более читаемым и сопровождаемым?

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

• Оформлен ли отчёт в соответствии с шаблоном?

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

Этап 7. Защита решений (10 минут)
Представители команд (по одному-два человека) за две минуты докладывают: с какими проблемами они столкнулись в исходном коде, какие решения приняли и почему, что было самым сложным. Преподаватель и другие команды задают уточняющие вопросы.

Этап 8. Подведение итогов и рефлексия (10 минут)
Оценка осуществляется по следующим критериям, привязанным к компетенциям:

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

Материально-техническое обеспечение

• Компьютеры с IDE (и Git — опционально),

• Проектор для демонстрации фрагментов кода,

• Раздаточные материалы: кейс с исходным кодом, описание модуля, шаблон отчёта, чек-лист оценки, оценочные листы.

Ожидаемые образовательные результаты

Обучающиеся:

• читают и анализируют чужой программный код, выявляя структурные и стилистические проблемы;

• планируют и выполняют рефакторинг, не нарушая работоспособности модуля;

• применяют модульное тестирование для верификации изменений;

• оформляют отчёт о рефакторинге в соответствии с профессиональными стандартами документирования;

• работают в команде, распределяя ответственность за отдельные части работы;

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

Мероприятие может проводиться как самостоятельное занятие или в паре с «Хакатоном — мастерской программных модулей», формируя полный цикл компетенций: от создания модуля до его анализа и улучшения. Подходит для открытых уроков, тренировки перед демонстрационным экзаменом и конкурсов профессионального мастерства.