Як мені обробляти рефакторинг, який займає більше часу, ніж один спринт?

Я працюю з базою коду, яка становить понад 500 К рядків коду. Він дуже серйозно потребує рефакторингу. Були визначені зусилля рефакторингу, які займуть більше часу, ніж звичайний спринт двох тижнів. Вони не можуть бути розбиті на більш дрібні завдання, як я бачив, запропоновані в інших відповідях на цьому сайті. Продукт повинен працювати в кінці ітерації, і часткове рефакторинг залишить систему в непридатному стані, оскільки залежність між елементами жахлива. То який найкращий спосіб підійти до цієї перешкоди? Ще раз зазначу, розбити його на більш дрібні шматки - це не варіант, що вже було зроблено.

Оновлення: людям, здається, потрібне пояснення, чому це не може вписатися у 2-тижневий спринт. У спринті більше задіяно, ніж просто писати код. У нас є політика без коду без тестів. Ця політика не завжди існувала, і значна частина кодової бази їх не має. Також деякі наші інтеграційні тести все ще є ручними тестами. Справа не в тому, що саме рефакторинг настільки великий. Це пов'язано з тим, що невеликі зміни впливають на багато частин системи, і нам потрібно забезпечити правильність роботи цих частин.

Ми не можемо відкласти або продовжити спринт, оскільки у нас є щомісячні виправлення. Таким чином, ця зміна, що поширюється на спринт, не може зупинити додавання іншої роботи до виправлення.

Рефакторинг проти перепроектування: Тільки тому, що наш процес розробки недостатньо ефективний, щоб обробити цей рефакторинг протягом двох тижневого циклу, це не гарантує перейменування його на новий дизайн. Я хотів би вірити, що в майбутньому ми могли б виконати абсолютно те саме завдання протягом двох тижневого циклу, коли наш процес покращиться. Розглянутий тут код не повинен був змінюватися протягом дуже тривалого часу і є досить стабільним. Тепер, оскільки напрямок компанії стає більш пристосованим до змін, ми хочемо, щоб ця частина кодової бази була такою ж адаптивною, як і решта. Що вимагає його рефакторингу. Виходячи з відповідей тут, стає очевидним, що не вистачає лісів, необхідних для того, щоб це рефакторинг працював у часові рамки нормальних спринтів.

Відповідь:

Я збираюся зробити підхід до філії та об'єднання, який Корбін Марч запропонував вперше, щоб ми могли дізнатися більше про ці проблемні області та як визначити відсутні тести. Думаю, рухаючись вперед, ми повинні скористатися підходом, який запропонував Буб, щоб визначити сфери, на яких відсутні тести, і реалізувати їх спочатку, потім зробити рефакторинг. Це дозволить нам продовжувати нормальний цикл спринтів, що триває два тижні, як і багато хто з них, зазначаючи, завжди має стосуватися рефакторингу.

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

Моя пропозиція:

1. Створіть відділення
2. Щодня об’єднуйтесь із стовбура у свою філію та вирішуйте конфлікти.
3. Працюйте, поки не буде зроблено. Ваша філія може бути поза базовою розробкою для декількох спринтів.
4. Злиття назад до тулуба.

Нічого не обійти тим фактом, що воно, мабуть, стане некрасивим. Я тобі не заздрю. На моєму досвіді, коли ви різко змінюєте проект, легше об'єднати поточний розвиток у нову парадигму проти того, щоб якось об'єднати нову парадигму в тепер змінений магістраль після того, як все закінчиться. Все-таки це зашкодить.

Не кожне завдання можна виконати у (штучному) 2-тижневому спринті, тому потрібен здоровий глузд. Якщо він більше не може бути розбитий, і це треба зробити, просто займіться і зробіть це. Процес не є більш важливим, ніж кінцевий результат, і його слід розглядати як орієнтир, а не закон, який не підлягає порушенню.

Просто зробіть спринт на 3, 4 або 5 тижнів. Кого хвилює? Ви, очевидно, переконані, що нічого не можна зробити за коротший термін, тому припиніть боротися з цим.

Просто не кажіть своїм колегам з Королівського товариства сліпих спритних прихильності.

Я рекомендую почати з книги « Ефективно працюючи зі спадщинним кодексом» Майкла Пера. Він охоплює різноманітні методи зменшення обсягу змін стилю рефакторингу.

У нашому магазині, коли у нас є великі завдання по рефакторингу чи переписуванню, які неможливо виконати у вікні випуску, ми залишаємо функціонал таким, який є в системі. Але ми почнемо з нових, відновлених функцій лего-блоку, як дозволяє час. Врешті-решт, ми потрапляємо до стану, коли у нас зроблено достатньо блоків лего, що спринт надає достатній час для підключення блоків лего до програми та включення їх для користувачів.

Більш коротко ми розбиваємо або переробляємо великі функції, використовуючи нові імена. Потім, наприкінці, ми використовуємо нашу перейменовану, реконструйовану роботу замість неприємного старого коду.

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

+1 на відповідь Корбіна Марта, саме так я і думав. Здається, що ваша база коду трохи негарна, і для її очищення знадобиться більше одного циклу спринтів.
Так, як сказав Корбін,

1. розділити його на "проект рефакторингу"
2. перевірити зміну вашої гілки
3. просувайте у вашому тестовому середовищі тестування якості
4. поступово зливайте його назад в багажник, поки не буде проведено рефакторинг.

Я впевнений, що у вас не виникне жодних проблем з продажем цього вашому диспетчеру розробників, якщо прем'єр-міністру важко це побачити, то поясніть їм, що Рим не будували за день і прибирали все сміття, викинуте в Рим вулиці теж не заробляться за день. Реконструкція потребуватиме певного часу, але, зрештою, це варто того з точки зору простішого обслуговування, швидшого випуску вдосконалення, зменшення кількості виробничих квитків та більш досконалої угоди про домовленість.

Хоча перепроектування, яке ви насправді хочете зробити, - це велике завдання, чи можна було б переробляти менші шматки, щоб зламати / зв'язати окремі залежності? Ви знаєте - коли сумніваєтеся, додайте непрямості. Кожна з цих декупажів має бути меншим завданням, ніж мамонт, якого ви не можете виконати.

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

У проекті, над яким я зараз працюю, ми використовуємо 4-тижневі спринти. І іноді ми не можемо закінчити історію користувача і просто перезапустимо її під час наступного спринту.

Однак IMHO має бути можливим розбити рефакторинг на більш дрібні історії, що вписуються у 4-тижневий спринт. Якщо ви не можете привести код у відповідний стан протягом 4 тижнів, у мене виникає відчуття, що ви переписуєте свою заявку, а не переробляєте її.

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

Коли настане час почати рефакторинг, ви просто призупините нормальні спринти. У вас немає вибору. Використовуйте розумне управління версіями - гілка, рефактор, тест, об'єднання. Завжди є момент, коли рефакторинг деяких великих проектів має перевагу над можливостями. Якщо можливо, я б також намагався розділити питання щодо кращої гнучкості.

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

Дозвольте мені дві невеликі замітки щодо інших відповідей тут:

• Розгалуження допоможе вам створити для себе ігровий майданчик, але ніколи не об’єднуйте свої зміни в багажник в один великий набір змін. Ви потрапите в серйозні проблеми з рештою команди.
• Це потрібно робити поступово, і це можна зробити. Не може бути ніяких виправдань. Читайте « Ефективна робота з обкладинкою Legacy Code» . Прочитайте ще раз.
• Думаючи, що ти можеш це зробити, великий крок - це помилка. Хоча це здається більшою роботою, керувати цим поступово набагато простіше в управлінні.

Якщо ви, здавалося б, "не забронювали" два тижні або більше, не залишиться непоміченим. Вам потрібно забезпечити підтримку управління проектами, а ще важливіше - команду. Якщо команда не буде прихильна до цього рефакторингу (а це означає, зробіть це зараз, а не в далекому майбутньому), ви потрапите в біду.

Не робіть це поодинці, використовуйте парне програмування. Це не означає, що вам потрібно постійно сидіти перед однією клавіатурою, але ви можете впоратися з невеликими та вузькими завданнями (наприклад, писати тести, що фіксують поведінку цього класу) окремо.

Зробіть Scratch Refactoring і ставитесь до цього як до такого. (Своєрідне рефакторинг прототипу "викидання", біт "викидання" є важливим!) Чесно кажучи, навряд чи ви знаєте всі наслідки, які матиме ваш рефакторинг. Реконструкція подряпин допоможе вам у певних аспектах:

• Ви відкриєте для себе фрагменти системи, про яку ви ніколи не знали, що існує.
• У вас буде набагато кращий погляд на те, як модулі взаємозв'язуються
• Ви відкриєте для себе новий спосіб згрупування вашої системи в модулі, що, можливо, сильно відрізняється від вашого сучасного розуміння. Обговоріть уявлення з партнером. Спробуйте переганяти новий погляд. Напишіть короткий аркуш архітектури (або намалюйте схему), де сказано, де зараз є речі та де вони повинні логічно належати.

Коли ви зробите рефакторинг подряпин, я сподіваюся, ви виявите, що ви не можете просто піти і все змінити. Вам буде погано, це просто великий безлад, і ви не можете просто переключити перемикач і змусити його працювати. Це те, що зі мною трапилося, може бути інакше у вашій ситуації.

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

Останнє, що нам допомогло - це використання великої дошки. Занадто багато речей тримати в голові. Надзвичайно важливо вести нотатки. Напишіть собі записку про дефіфінг в кінці дня, фіксуючи те, що ви зробили сьогодні, і хочете зробити завтра. Це допомагає розслабляти великі часи, і вам потрібен розслаблений час, якщо ви хочете не відставати від завдання. Удачі!

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

У нас є два типи робіт:

1. Людина-години працює
2. Геній працює

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

Одна пропозиція, яка може допомогти: Якщо у вас є неперевірений код таким, що у вас не вистачає часу на переробку та повторне повторне тестування протягом двох тижневого спринту, подумайте спершу, щоб внести якісь інші не пов'язані між собою невеликі зміни в код, щоб ви могли зосередитись на написання тестів на перший спринт або два. Можливо, ви можете виявити декілька неперевірених клієнтів коду, який ви хочете змінити; виберіть одного клієнта та внесіть деякі інші корисні зміни в бізнес, які змусять вас писати тести для цього клієнта. Як тільки ви ознайомитеся з кодом, від того, як працювати з ним, і у вас буде більше тестів, і ви, можливо, виконали кілька незначних змін, що сприяють, ви будете в набагато кращому стані здійснити рефакторинг і (тепер простіше) ) тестування обох в одній ітерації.

Інший підхід полягає в тому, щоб зробити копію коду-порушника, перефактурувати його, а потім перемістити клієнтів по черзі на новий код. Цю роботу можна розбити за допомогою ітерацій.

І не здавайся. Не приймай просто, що великий рефакторинг не може бути розбитий на менші кроки. Найпростіший / найшвидший / найкращий підхід може зайняти більше часу, ніж ітерація. Але це не означає, що немає можливості зробити шматки ітерації розміром.