Стоит ли проводить рефакторинг существующего кода, который не нарушен в проекте, ориентированном на новые функции?

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

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

Абсолютно.

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

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

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

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

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

0-Есть ли жалобы клиентов на этот код?

1-это необходимо для функциональности приложения

2-Вреден ли текущий код?

3-Стоит ли стоимость изменений?

4-Можете ли вы позволить себе стоимость?

5-Это лучшее использование ваших навыков в организации

6-Ваши изменения потребуют от вашего пользователя переустановки нового изменения. Не могли бы вы объяснить это клиенту?

7-Не могли бы вы допустить риск плохого исправления?

8-Влияет ли изменение на другой код за пределами вашего проекта?

9-Это развивающийся продукт или стабильный продукт? Если он развивается, можете ли вы включить изменения в следующий выпуск?

Рефакторинг скоро, рефакторинг часто.

Если вы можете себе это позволить (время, деньги и т. Д.), Вы должны это сделать.

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

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

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

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

Дублирование кода в долгосрочной перспективе обойдется вам (как лично вам, так и компании), поскольку изменения вносятся в одно место, а не в другое.

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

Если рефакторинг просто «хорош», то есть он не находится в коде, непосредственно затронутом новой функциональностью, то я бы оставил его в покое. Вы вносите изменения ради изменений.

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