Абсолютно.
Рефакторинг должен быть выполнен на работающем и «проходящем» проекте. Когда все ваши тесты (на уровне устройства, системы и уровня приемки) пройдены, вы знаете, что ваш продукт соответствует требованиям. При рефакторинге вы можете продолжать подтверждать, что все тесты продолжают проходить. Если какой-либо тест начинает проваливаться, значит, вы сделали что-то не так и вам нужно это исправить. Если у вас есть неудачные тесты, вы должны исправить их перед рефакторингом, чтобы вы всегда могли убедиться, что ваш рефакторинг не меняет функциональность системы.
Это также идеальное время для рефакторинга, при условии, что у вас есть время и ресурсы для проведения рефакторинга и при этом все в срок и в рамках бюджета. Рефакторинг теперь облегчит понимание и обслуживание вашей системы, поэтому, по мере добавления вами новых функций, это станет проще. Вам нужно бороться с гниением кода и программной энтропией .
Как отмечает в комментариях Джоэл Этертон , вам необходимо управлять масштабами рефакторинга. Сосредоточьтесь на рефакторинге частей системы, к которым вы скоро добавите функции, на проведение рефакторингов, которые облегчат работу или добавят новые функции. Использование статического анализа, инструментов метрик и обзоров кода может помочь вам определить наиболее важные области. Вы не хотите пропускать сроки, потому что вы выполняли рефакторинг - вам все равно нужно продолжать увеличивать ценность для клиента.
Вы упоминаете, что клиент не видит ценности в рефакторинге. Как правило, клиент заботится не о качестве кода, а о продукте. Рефакторинг поможет вам поддерживать высокое качество продукта и продолжать поставлять продукт, который соответствует изменяющимся потребностям клиента. Попробуйте договориться о времени для рефакторинга в вашем графике (клиент хочет, чтобы X функций за Y дней, попробуйте, если вы не можете получить Y + Z дней или XN, чтобы вы могли потратить время на разработку, рефакторинг и реализацию), если вы может.