#рефакторинг #запахи_кода 

![[Pasted image 20241112230403.png]]

> Воз­никает, когда говорят о том, что в будущем, наверное, потребуется возможность делать то или иное, и хотят обеспечить набор механизмов для работы с вещами, которые пока что не нужны. Получающуюся в результате программу труднее по­нимать и сопровождать. Если бы все эти механизмы использовались, их наличие было бы оправданным, а без этого они только мешают, так что лучше от них из­бавиться.

### **Признаки**
- Класс, метод, поле или параметр не используются    

### **Причины появления**
Иногда код создаётся «про запас», чтобы поддерживать какой-то возможный будущий функционал, который в итоге так и не реализуется. В результате этот код становится труднее понимать и сопровождать.

### **Рефакторинги**
- [[Свертывание иерархии (Collapse Hierarchy)]]    
- [[Встраивание функции (Inline Function)]]    
- [[Встраивание класса (Inline Class)]]    
- [[Удаление неработающего кода (Remove Dead Code)]]    

![[Pasted image 20241112230411.png]]

### **Результат**
- Уменьшение размера кода    
- Упрощение поддержки    

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

### **Ссылки**

- [https://refactoring.guru/ru/smells/speculative-generality](https://refactoring.guru/ru/smells/speculative-generality)
- [[Мартин Фаулер - Рефакторинг кода на JavaScript]]