Ознаки того, що потрібен рефакторинг

Перерахуємо основні ознаки ("попереджувальні знаки" – Мартін Фаулер називав їх "smells"), що вказують на потребу в рефакторингу:

o Є дублювання коду

o Метод занадто довгий

o Цикл занадто довгий або занадто велика вкладеність циклів

o Клас має погану внутрішню зв'язність

o Інтерфейс класу не забезпечує достатній рівень абстракції

o Список параметрів занадто довгий

o Зміни, що вносяться в клас, мають сегментний характер

o Зміни вимагають паралельну модифікацію багатьох класів

o Різні ієрархії класів повинні модифікуватися паралельно

o Пов’язані між собою дані, що використовуються разом, не організовані в один клас

o Метод використовує більше членів іншого класу, ніж свого

o Базовий тип перевизначено

o Клас не має достатньої функціональної навантаженості

o В ланцюгу викликів методів є ланцюг параметрів, що передаються

o Проміжний об’єкт не робить нічого власного

o Клас занадто зв’язаний з іншим класом

o Метод має погане ім’я

o Поля є public

o Клас-нащадок використовує тільки невелику кількість з методів класу-предка

o Коментарі використовуються для пояснення складного коду

o Використовуються глобальні змінні

o Метод потребує код ініціалізації перед викликом або пост-код після виклику

o Програма вміщує код, який здається таким, що "може знадобитись колись"

Розглянемо деякі з них.

Дублювання коду

Воно майже завжди означає, що при початковому проектуванні коду не було правильно проведено декомпозицію. Дублювання коду заставляє програміста вносити паралельні зміни. Це суперечить широко відомому принципу DRY - Don’t Repeat Yourself.

Метод занадто довгий

В об’єктно-орієнтованому програмуванні методи величиною більші за екран рідко бувають потрібні і зазвичай означають спробу впхнути принципи структурного програмування в об’єктно-орієнтовану програму.

Одним зі шляхів покращення системи є збільшення її модульності – збільшення кількості добре визначених, добре іменованих методів, які добре роблять одну визначену річ. Якщо метод стає зрозумілішим при перенесенні частини його в окремий метод, потрібно створювати цей метод.

Інтерфейс класу не забезпечує достатній рівень абстракції

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Еволюція програми	\|	Зміни, що вносяться в клас, мають сегментний характер

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.003 сек.