Рефакторинг можно определить как процесс изменения программной системы таким образом, чтобы он не изменял внешнее поведение кода, но улучшал его внутреннюю структуру. Это дисциплинированный способ очистки кода, сводящий к минимуму вероятность появления ошибок. Рефакторинг, безусловно, замедляет работу вашей программы, но делает ее более удобной для настройки производительности.
Ниже приведены некоторые из методов, позволяющих определить, нуждается ли ваш код в рефакторинге.
- Отношения диаграммы последовательности отличаются от диаграммы классов
Это очень простая уловка: в тот момент, когда вы видите, что класс на диаграмме последовательности обращается к напрямую независимому классу в соответствии с диаграммой классов, тогда вам, безусловно, нужно исследовать возможность рефакторинга. Например, давайте рассмотрим класс под названием customer, который имеет отношение к транспортному средству и который, в свою очередь, связан с производственной компанией. Если есть какой-либо доступ к классу компании из класса customer, то, безусловно, необходимо провести рефакторинг.
2. Единоличная ответственность
Если какой-либо из ваших классов или его атрибутов демонстрирует более одного поведения, это признак того, что существует возможность разбить объект и провести его рефакторинг.
3. Повторяющийся код.
Если блок кода повторяется и вы думаете, что он может измениться в будущем, пора разделить его, используя (метод извлечения). Это применение концепции DRY.
4. Переименование классов и свойств
Стоит ли оно того? Безусловно, хороший код должен четко сообщать о том, что он делает, а имена атрибутов являются ключом к очистке кода.
5. Метод должен использовать данные в собственном объекте.
В большинстве случаев метод должен быть на объекте, данные которого он использует. В противном случае существует вероятность нежелательной взаимозависимости.
6. Слишком много временных переменных.
Временные параметры часто являются проблемой, поскольку они вызывают передачу множества параметров, когда в этом нет необходимости. Вы можете легко потерять представление о том, для чего они нужны. Они особенно коварны в длинных методах. Вы можете использовать «заменить темп запросом».
7. Оператор переключения на основе атрибута другого объекта
Делать переключение на основе атрибута другого объекта - плохая идея. Если вам необходимо использовать переключатель, он должен относиться к вашим собственным данным, а не к чужим. Вам следует подумать о перемещении этих операторов switch в объект, данные которого он использует.
8. Замените условное выражение полиморфизмом.
Примените шаблон состояния / стратегии, если какое-либо из ваших условных операторов можно сделать более надежным. Лучшее распределение обязанностей - всегда признак хорошего дизайна программного обеспечения.
Когда не проводить рефакторинг
Переписать с нуля проще.
Существует множество ошибок, важно, чтобы текущий код работал правильно для рефакторинга.
Жесткие сроки. Это можно оставить на потом в виде технических долгов.
Альтернативой может быть разделение программного обеспечения на компоненты с сильной инкапсуляцией, что упростит рефакторинг по мере продвижения.
