Как мы решаем, когда нужно проводить рефакторинг, а когда — полную перепись
С этим моментом сталкивается каждый разработчик.
Кодовая база работает медленно. Добавление новых функций занимает слишком много времени. Новым сотрудникам трудно разобраться в системе. В какой-то момент кто-нибудь предлагает полностью всё переписать.
Команда обычно разделяется на две группы. Одна хочет начать с чистого листа. Другая опасается провала, как это уже бывало при прошлых попытках переписывания. У обеих сторон есть веские аргументы.
Переписывание кода — это не магическое решение. Часто это занимает больше времени, чем планировалось. В итоге вам приходится поддерживать две системы одновременно. Вы даже можете повторить те же ошибки в новой версии.
Переписывание имеет смысл в следующих конкретных случаях:
• Модель данных фундаментально не подходит для текущих бизнес-задач. • Технология устарела и больше не получает обновлений безопасности. • Бизнес-потребности настолько изменились, что исходная система безнадежно устарела. • Никто из текущей команды не понимает, как работает система.
Даже в этом случае не стоит проводить замену по принципу «всё и сразу» (big bang replacement). Используйте паттерн «душитель» (strangler fig pattern). Стройте новую систему по частям параллельно со старой.
В большинстве случаев вам на самом деле нужен рефакторинг.
Рефакторинг — правильный выбор, когда:
• Вы всё еще можете добавлять новые функции, пусть даже это происходит медленно. • Команда понимает текущий код. • Хаос ограничен конкретными модулями. • Бизнес не может позволить себе остановку выпуска новых функций.
Прежде чем сделать выбор, спросите себя, почему код стал плохим.
Если проблема в техническом долге, проведите рефакторинг самых проблемных участков. Если же причина в отсутствии код-ревью или плохой культуре разработки, переписывание не поможет. Вы просто создадите новый хаос, используя те же старые привычки.
Задайте себе эти вопросы, прежде чем принять решение:
• Можем ли мы исправить самые плохие части изолированно? • Не подходит ли модель данных под текущие бизнес-задачи? • Какие знания мы потеряем, если начнем всё с нуля? • Есть ли у бизнеса стабильность, чтобы пережить длительный переходный период?
Начать всё с чистого листа — приятное чувство. А вот закончить переписывание — это самая сложная часть. В большинстве случаев структурированный план рефакторинга является более безопасным и эффективным подходом.
Источник: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk