62 lines
4.9 KiB
Markdown
62 lines
4.9 KiB
Markdown
#рефакторинг #методы_рефакторинга
|
||
|
||
![[Pasted image 20241115072019.png]]
|
||
|
||
### **Проблема**
|
||
У вас есть сложное для понимания выражение.
|
||
```typescript
|
||
renderBanner(): void {
|
||
if ((platform.toUpperCase().indexOf("MAC") > -1) &&
|
||
(browser.toUpperCase().indexOf("IE") > -1) &&
|
||
wasInitialized() && resize > 0 )
|
||
{
|
||
// do something
|
||
}
|
||
}
|
||
```
|
||
|
||
### **Решение**
|
||
Поместите результат выражения или его части в отдельные переменные, поясняющие суть выражения.
|
||
```typescript
|
||
renderBanner(): void {
|
||
const isMacOs = platform.toUpperCase().indexOf("MAC") > -1;
|
||
const isIE = browser.toUpperCase().indexOf("IE") > -1;
|
||
const wasResized = resize > 0;
|
||
|
||
if (isMacOs && isIE && wasInitialized() && wasResized) {
|
||
// do something
|
||
}
|
||
}
|
||
```
|
||
|
||
### **Причины рефакторинга**
|
||
Выражения могут быть очень сложными и трудными для чтения. В таких случаях имеет смысл с помощью локальных переменных превратить выражение в нечто, лучше поддающееся пониманию и управлению. В частности, локальные переменные дают возможность именовать часть более сложной части логики, что позволяет лучше понять цель происходящего.
|
||
Такие переменные также удобны для отладки, поскольку обеспечивают простоту просмотра в отладчике или при отладочном выводе.
|
||
Главная мотивация этого рефакторинга — сделать более понятным сложное выражение, разбив его на промежуточные части. Это может быть:
|
||
- Условие оператора `if()` или части оператора `?:` в C-подобных языках
|
||
- Длинное арифметическое выражение без промежуточных результатов
|
||
- Длинное склеивание строк
|
||
|
||
### **Достоинства**
|
||
- Улучшает читабельность кода. Постарайтесь дать выделенным переменным хорошие названия, которые будут отражать точно суть выражения. Так вы сделаете код читабельным и сумеете избавиться от лишних комментариев. Например, `customerTaxValue`, `cityUnemploymentRate`, `clientSalutationString` и т. д.
|
||
|
||
### **Недостатки**
|
||
- Появляются дополнительные переменные. Но этот минус компенсируется простотой чтения кода.
|
||
- При рефакторинге выражений условных операторов помните о том, что программа обычно оптимизирует выполнение условных выражений и не выполняет дальнейшие проверки, если уже понятен финальный результат выражения. Например, если в выражении `if (a() || b()) ...` метод `a` вернет `true`, то программа не станет выполнять `b` — что бы он ни вернул, результирующее выражение всё равно будет истинным.
|
||
Однако, после извлечения частей этого выражения в переменные, оба метода будут вызываться постоянно, что может негативно сказаться на производительности, особенно если эти методы выполняют какую-то ресурсоёмкую работу.
|
||
|
||
### **Порядок рефакторинга**
|
||
1. Вставьте новую строку перед интересующим вас выражением и объявите там новую переменную. Присвойте этой переменной часть сложного выражения
|
||
2. Замените часть вынесенного выражения новой переменной
|
||
3. Повторите это для всех сложных частей выражения
|
||
|
||
|
||
### **Борется с запахом**
|
||
- [[Комментарии]]
|
||
|
||
### **Обратный рефакторинг**
|
||
- [[Встраивание переменной (Inline Variable)]]
|
||
|
||
### **Ссылки**
|
||
- https://refactoring.guru/ru/extract-variable
|
||
- [[Мартин Фаулер - Рефакторинг кода на JavaScript]] |