Как мне справиться с рефакторингом, который занимает больше времени, чем один спринт?

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

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

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

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

Ответ:

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

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

Мое предложение:

1. Создать ветку
2. Ежедневно сливайтесь из магистрали в свою ветку и разрешайте конфликты.
3. Работайте, пока не закончите. Ваша ветка может находиться за пределами основного развития в течение нескольких спринтов.
4. Сливаемся обратно в багажник.

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

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

Просто сделайте спринт на 3, 4 или 5 недель. Какая разница? Вы, очевидно, убеждены, что ничто не может быть сделано в более короткие сроки, поэтому прекратите бороться с этим.

Только не говорите своим товарищам в Королевском обществе слепой гибкой приверженности.

Я рекомендую начать с книги Майкла Фезерса « Эффективная работа с устаревшим кодом ». Он охватывает различные методы, чтобы уменьшить объем изменений в стиле рефакторинга.

В нашем магазине, когда у нас есть большие задачи по рефакторингу или переписыванию, которые не могут быть выполнены в окне выпуска, мы оставляем функциональность как есть в системе. Но мы начинаем с новых, переработанных функций lego-block, если позволяет время. В конце концов, мы достигаем состояния, когда у нас достаточно лего-блоков, и спринт предоставляет достаточно времени, чтобы подключить лего-блоки к приложению и включить его для пользователей.

Более кратко, мы разбиваем или переделываем большие функции, используя новые имена. Затем, в конце, мы используем нашу переименованную, переработанную работу вместо старого кода.

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

+1 к ответу Корбина Марча, это именно то, о чем я думал. Похоже, ваша кодовая база немного уродлива, и для ее очистки потребуется не один цикл спринта.
Итак, как сказал Корбин,

1. разделить его на «проект рефакторинга»
2. проверить изменения в вашей ветке
3. продвинуть в свою тестовую среду для тестирования качества
4. постепенно объединяйте его обратно в магистраль, пока не будет выполнен рефакторинг.

Я уверен, что у вас не возникнет проблем с продажей этого вашему менеджеру разработки, если вашим премьер-министру будет трудно это увидеть, а затем объясните им, что Рим не был построен за один день, и уберите весь мусор, брошенный в Рим. Улицы не будет сделано за день тоже. Рефакторинг займет некоторое время, но в конечном итоге это будет стоить того с точки зрения более простого обслуживания, более быстрых выпусков улучшений, меньшего количества производственных билетов и более выполненного SLA.

Несмотря на то, что реорганизация, которую вы действительно хотите сделать, является большой задачей, можно ли будет реорганизовать более мелкие фрагменты, чтобы сломать / отделить отдельные зависимости? Вы знаете - когда сомневаетесь, добавьте косвенность. Каждая из этих развязок должна быть меньше, чем гигантская, которую вы не можете выполнить.

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

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

Тем не менее, ИМХО должно быть возможно разделить рефакторинг на более мелкие истории, которые вписываются в 4-недельный спринт. Если вы не можете привести код в согласованное состояние в течение 4 недель, у меня возникает ощущение, что вы переписываете свое приложение, а не реорганизуете его.

Я рекомендую, чтобы, когда некоторые задачи занимали больше 2-недельного цикла спринта, эта задача была запланирована на другое время. Ваша команда определила необходимость рефакторинга, и это важно. Иногда нет другого выбора ... и, да, это отстой.

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

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

Позвольте мне две небольшие заметки относительно других ответов здесь:

• Ветвление поможет вам создать игровую площадку для себя, но никогда не объединяйте свои изменения в магистрали в один большой набор изменений. У вас будут серьезные проблемы с остальной частью команды.
• Вы должны делать это постепенно, и это может быть сделано. Никаких оправданий. Прочитайте Работая эффективно с обложкой Legacy Code . Прочитайте это снова.
• Думать, что вы можете сделать это одним большим шагом - заблуждение. Хотя это кажется более трудоемким, делать это постепенно проще в управлении.

Выход на первый план «зарезервирован» на две недели и более не останется незамеченным. Вы должны обеспечить поддержку со стороны руководства проектом и, что еще важнее, команды. Если команда не привержена этому рефакторингу (а это значит, сделайте это сейчас, а не в отдаленном будущем), у вас возникнут проблемы.

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

Сделайте Scratch Refactoring и относитесь к нему как к такому. (Этакий рефакторинг прототипа «выбрасывается», бит «выбрасывать» важен!) Честно говоря, вряд ли вы знаете все последствия, которые будет иметь ваш рефакторинг. Рефакторинг царапин поможет вам в определенных отношениях:

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

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

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

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

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

У нас под рукой два вида работ:

1. Человеко-часовые работы
2. Гениальные произведения

Рефакторинг обычно состоит из первого типа работы, так как разработчикам уже известны многие методы, такие как DRY , SRP , OCP , DI и т. Д. Таким образом, когда на рефакторинг проекта уходит два месяца, это просто занимает два месяца , то есть никак не обойтись. Таким образом, мое предложение состояло бы в том, чтобы не проводить рефакторинг исходного проекта, и позволить ему работать в его текущей ситуации. Прекратить получать новые запросы и требования от заинтересованных сторон и владельца продукта . Затем дайте команде поработать над проектом, пока он не будет переработан и готов к работе.

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

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

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