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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда начать

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

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