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

Команда получает в наследство модуль выставления счетов, который никто до конца не понимает. В нем отсутствуют тесты, защищающие существующее поведение. Предлагается спринт для «доработки», и планируется переписать ядро ​​в новой структуре. Никто не может сказать, как узнать, что новая версия по-прежнему корректно выставляет счета клиентам.

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

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

Что такое учебный проект по рефакторингу?

Проект по обучению рефакторингу — это структурированная работа над устаревшим кодом, цель которой — развитие навыков и улучшение кода. Учащиеся планируют небольшое, ограниченное изменение, защищают существующее поведение тестами, улучшают дизайн небольшими шагами и демонстрируют доказательства того, что ничего не сломалось. Код становится лучше, и, что более важно, инженеры практикуют навыки принятия решений, которые им понадобятся при работе с реальным техническим долгом.

Интересные факты

1. Опишите проблему с производительностью.

Начнём с задачи: спланировать и проверить ограниченное по масштабу улучшение устаревшего кода. Ключевое слово здесь — «ограниченное». Учащийся выбирает изменение, достаточно небольшое для завершения, и может указать, что входит в область действия, а что нет.

Полезно быть точным в выборе терминов. Мартин Фаулер описывает рефакторинг как контролируемый метод улучшения дизайна существующей кодовой базысостоит из небольших преобразований, сохраняющих поведение. Фраза «сохраняющие поведение» — это то, что отличает рефакторинг от переписывания кода, и именно это обучение должно сделать видимым. Сама метафора технического долга. Этот термин был придуман Уордом Каннингемом.А рассуждения Фаулера служат полезным напоминанием о том, что заемные средства можно брать обдуманно и осмотрительно, поэтому не каждый проблемный модуль является ошибкой, которую нужно исправлять.

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

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

2. Диагностика пробелов в знаниях и контексте.

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

1. Используется ли в современной практике реальная задача? Если на тренинге в слайдах рассматриваются шаблоны рефакторинга, но никто никогда не меняет непротестированный код, значит, никто не практиковал защитное поведение. Если же оценка представляет собой тест с несколькими вариантами ответов на тему «запахи кода», то она измеряет запоминание.
2. Какова когнитивная нагрузка? В пересмотренной таксономии Блума оценка безопасности изменений находится на уровнях анализа и оценки, а разработка плана и тестов — на уровне создания. Сопоставление действий с этими уровнями рассматривается в нашем руководстве. соответствие учебных мероприятий таксономии Блума.
3. Что-то ещё, помимо навыков, мешает? Проверьте штат сотрудников, инструменты и процедуры. Если сборка занимает час, никто не будет часто проводить тесты. Если работы по техническому обслуживанию никогда не планируются, инженеры будут проводить рефакторинг только втайне. Сообщайте о причинах, не связанных с обучением, тем, кто может их устранить.

3. Разработайте целенаправленную подготовку и практику.

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

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

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

Обратная связь. Связывайте отзывы с принятыми решениями, а не с общей оценкой. «Вы выделили логику скидок, но ваши тесты охватывали только оптимальный сценарий, поэтому вы не могли заметить изменение округления» — это более полезная оценка, чем «3 из 5».

Вводные данные от преподавателя в режиме реального времени или асинхронное обсуждение? Ввод данных в режиме реального времени наиболее эффективен, когда выбор неоднозначен, например, следует ли остановиться и добавить недостающий тест или продолжить. Асинхронного обзора достаточно, когда учащиеся сравнивают свой план и тесты с аннотированной версией эксперта. Многие команды используют оба подхода: сначала самостоятельная подготовка, а затем сессия с модератором для решения сложных задач.

4. Проработайте реалистичный пример.

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

Дело. Устаревшая функция вычисляет общую сумму заказа, включая скидку, налог и правила доставки. У нее нет тестов. Команда предлагает реструктурировать весь модуль выставления счетов, чтобы сделать его «более чистым».

Задача. Учащийся объясняет, что бы он сделал, приводит доказательства, которые бы он собрал, и указывает, какая дополнительная информация или поддержка ему необходима.

Первая попытка. «Я бы разделил модуль на три сервиса, перенёс бы туда логику, а затем проверил бы цифры на тестовом сервере». Учащийся выбрал масштабное изменение и отложенную ручную проверку. Невозможно определить, совпадают ли старые и новые версии по крайним случаям.

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

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

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

5. Оценить возможности и спланировать передачу.

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

Критерии оценки: 0 означает отсутствие или неподтвержденность, 1 — частичное выполнение с существенными упущениями, 2 — полное выполнение и обоснование в соответствии с согласованными критериями. Критические ошибки определяются отдельно, например, изменение поведения без проверки, которая могла бы это заметить, поэтому общая оценка не может скрыть ошибку. Данная рубрика является предложением, а не утвержденным стандартом готовности: адаптируйте ее совместно с руководителем инженерного отдела и проведите пилотное тестирование. Наше руководство по разработка интерактивных методов обучения с полезной обратной связью показывает, как писать отзывы, которые связаны с принятыми решениями.

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

Где интерактивная доставка помогает

Интерактивные форматы помогают, когда каждый участник должен подтвердить свои действия до того, как увидит результат в группе. На сессии в режиме реального времени модератор может показать короткий фрагмент устаревшего кода, попросить каждого инженера представить первое изменение, которое он бы внес, и как бы он доказал его безопасность, а затем показать результаты перед обсуждением. Тот же самый пример можно использовать и для самостоятельной подготовки. AhaSlides поддерживает интерактивное обучение и переключение между режимом реального времени и самостоятельным обучением. Это инструмент для презентаций и обучения, а не место для запуска или анализа кода, поэтому выполняйте рефакторинг в своей собственной среде. Проверьте любые конкретные функции создания, обратной связи или отчетности, которые вы планируете использовать, на соответствие вашему рабочему процессу. Для получения рекомендаций по выбору форматов см. нашу статью о Когда использовать адаптивное, интерактивное и обучение в режиме реального времени?.

Измерьте, что изменилось.

Заранее определите, что покажет способность инженеров выполнить задачу. Сравните качество анализа рисков и подтверждение сохранности поведения в неизвестном ранее случае с базовым уровнем. Определите, кто включен в исследование, знаменатель и сроки. Если результаты улучшатся, проверьте, что еще изменилось за тот же период, например, новые инструменты тестирования, более быстрая сборка или смена владельца, прежде чем учитывать обучение.

Ограничения, которые могут остаться

• Пора проводить техническое обслуживание. Если работы по взысканию задолженности так и не запланированы, квалифицированные инженеры все равно не смогут применить свои навыки.
• Инструменты для тестирования. Без пригодного для использования тестового стенда или возможности быстрой сборки трудно поддерживать поэтапный подход и частые проверки.
• Обзор дела. Один из примеров из прошлого демонстрирует несколько видов риска. Оценка не отражает в целом суждения инженера.
• Оценка того, когда не следует проводить рефакторинг. Некоторые фрагменты кода лучше оставить без изменений, заменить или вывести из эксплуатации, и это решение зависит не только от навыков.
• Перевод. Результаты выполнения ката отличаются от результатов выполнения серийного задания в условиях производственной нагрузки.

Сообщите об этих проблемах спонсорам на раннем этапе и спланируйте отдельные исправления. Обучение улучшает навыки планирования и проверки инженера. Оно не создает ни времени, ни инструментов.

Часто задаваемые вопросы

Что такое учебный проект по рефакторингу?

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

Является ли полная переработка сценария хорошим способом выявления технического долга?

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

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

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

Вам нужен пример кода для обучения?

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

Когда начать

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

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