Рефакторинг: коду, терміни проведення, застосування
Опубликованно 07.12.2018 00:21
Рефакторинг - це свого роду реорганізація. Технічно він виходить з математики, коли ставиться вираження в еквівалентність - чинники є більш чистими способами вираження одного і того ж твердження. Рефакторинг коду передбачає еквівалентність, початковий і кінцевий продукти повинні бути функціонально ідентичними. Практично він робить код більш чітким і чистим, простим і елегантним. Прикладом може служити діапазон від перейменування змінної до введення методу в сторонній клас, для якого в розробника немає прав. Аналіз і рефакторинг для створення чистого коду
Просто він означає поліпшення дизайну існуючого коду без зміни його спостережуваного поведінки. Спочатку задумана в співтоваристві Smalltalk, тепер вона стала основною технологією розвитку. Хоча інструменти рефакторінгу дозволяють дуже легко його застосовувати. Важливо щоб розробник розумів, для чого він це робить, і чому йому це допоможе, наприклад, в ситуації, коли потрібно дозволити повторне використання повторюваного блоку коду.
Кожен рефакторинг являє собою простий процес, який робить одне логічне зміна структури коду. При зміні великої кількості коду за один раз, можливо, що були введені помилки. Але коли і де помилки були створені, сказати складно. Якщо зміни виконуються невеликими кроками з перевірками, які виконуються після кожного кроку, помилка, ймовірно, виникає в тестовому прогоні відразу ж після введення коду в систему. Виконуючи рефакторинг коду, можна було б перевірити цей крок, а після скасування кроку, його можна було б розділити на ще більш дрібні кроки, щоб виявити збої.
Це перевага всеосяжних модульних тестів в системі, захищено методами екстремального програмування. Вони дають розробникам і керуючим впевненість у тому, що рефакторинг не порушив систему, код буде вести себе так само, як і раніше.
Операція поліпшення коду відбувається приблизно в наступних стадіях:
Дія
Питання, які потрібно задати, дії
Виявлення проблеми
Є проблема? В чому проблема?
Характеристика проблем
Чому потрібно щось міняти? Які переваги? Чи існують якісь ризики?
Вироблення
рішення
Яким має бути «цільове стан» коду? Яке перетворення коду перетворює код в бажаний стан?
Зміна коду
Кроки, які будуть виконувати рефакторинг коду.
Він зазвичай виконується невеликими кроками. Після кожного такого кроку розробник зазвичай залишається в робочій системі, яка функціонально не змінюється. Практикуючі чергують виправлення помилок і доповнюють код між цими кроками. Таким чином, рефакторинг не виключає можливості зміни функціональності, він просто говорить, що це інша діяльність, пов'язана з переупорядочиванием коду. Безперервний процес управління якістю
В ідеалі рефакторинг буде частиною безперервного процесу поліпшення якості. Іншими словами, він буде легко переплітатися з іншими повсякденними діями кожного розробника програмного забезпечення.
Створення чистого коду з аналізом і рефакторінгом корисні, коли з'являється помилка, а проблема повинна бути виправлена або код необхідно розширити. Процес одночасно з обслуговуванням або додаванням нових функцій також дозволяє керівникам і розробникам з більшою ймовірністю вирішити проблеми, оскільки для цього не буде потрібно додаткова фаза тестування.
Якщо відповідальній розробнику важко зрозуміти код, він задасть питання й почне документувати незрозумілу частину, що стане хорошою відправною точкою для застосування нових методів. Часто розклад операції очищення не дозволяє відразу ж ухвалити хороше рішення. Можливо, що функція була додана в поспіху і не виправлена помилка. У цих випадках відповідний код повинен бути відзначений приміткою FIXME, щоб його можна було переробити, коли дозволить час. Такі обставини вимагають рефакторінгу поліпшення існуючого коду не для окремих елементів, а для цілого проекту.
Коли прийшов час вирішити накопичені проблеми, сканують FIXME і TODO. Над базою коду з'являться всі проблеми для огляду. Потім вони можуть бути реорганізовані у відповідний пріоритет. Рефакторинг - гарна річ, тому що складні вирази, як правило, побудовані з більш простих, більш громіздких компонентів. Він надає більш прості компоненти, або зводить їх до більш ефективного складного вираження, у залежності від того, яким чином програміст збирається діяти.
Для прикладу ефективності рефакторінгу існуючого коду підраховуємо члени і оператори: (x - 1) * (x + 1) = x 2 - 1. Чотири терміна проти трьох. Три оператора проти двох. Проте вираз лівої сторони простіше зрозуміти, тому що воно використовує більш прості операції. Крім того, він надає більше інформації про структуру функції f (x) = x 2 - 1, так як коріння +/- 1, що було б важко визначити, просто «дивлячись» з правого боку. Зони дії
Програмне забезпечення для рефакторінгу поліпшення існуючого коду є в мережі в невеликій кількості, але більша частина його добре розроблена. З часом розмір власного програмного забезпечення і його складність зростають, при цьому помилки збільшуються, і, отже, надійність коду зменшується. Розробникам програмного забезпечення, особливо коли вони не є оригінальними авторами, все важче підтримувати і розширювати код. Кодова база, яка в будь-софтверної компанії повинна бути цінним активом, в якийсь момент може стати перевантаженою. Ці негативні процеси можуть викликати передчасне старіння програмного забезпечення, про що добре пояснюється в праці Мартіна Фаулера "Рефакторинг. Поліпшення існуючого коду".
Стратегічно важливим фактором є увага керівників і розробників програмного забезпечення. З практичної сторони застосування методів розробки сповільнить це старіння. Рефакторинг може скасувати це старіння при правильному застосуванні, бажано з гарними програмними інструментами, які допомагають у виявленні, аналізі та описі проблем, і в кінцевому підсумку дозволяють їх фіксувати.
Переписування компонента часто використовується розробником як більш прийнятний метод, оскільки є для нього менш заплутаним. Принаймні, так вважає Фаулер при рефакторинге поліпшення існуючого коду. Поточний вихідний код може змінюватися з часом з оригінального дизайну і може бути не відразу зрозумілий розробнику.
Однак він ігнорує той факт, що вихідний код має багато прихованого значення. Виправлення помилок, що містяться у вихідному коді, не можуть документуватися, однак вони дуже цінні. Рефакторинг зберігає це приховане значення, гарантуючи, що поведінка системи не зміниться. Процес перейменування методу
Цей приклад застосовується для змінної, класу чи іншого елемента java, у якого є ім'я, яке вводить в оману, і потрібно знати, як зробити рефакторинг такого коду. Для цього потрібні всі посилання і, можливо, оновлення файлів. Процес може включати перейменування методу в підкласах. З іншого боку, перейменування пакета також буде включати в себе переміщення файлів і каталогів та оновлення системи управління версіями.
Методи виправлення: Переміщення класу. Клас знаходиться в неправильному пакеті, тому його слід перенести в інший пакет, де він краще підходить. Витяг. Довгий метод необхідно розбити на етапи, щоб підвищити читаність і зручність обслуговування. Розділ коду з однієї логічної завданням замінюється викликом на новий метод. Екстракція суперкласу. Існуючий клас надає функціональні можливості, які необхідно якимось чином змінити. Абстрактний клас вводиться, як батько поточного класу, а потім загальна поведінка «підтягується» до цього нового батькові. Заміна умовного значення з поліморфізмом. Методи в класі можуть перевіряти деяке значення (якщо оператор switch), щоб визначити правильне дію для виконання. Переваги методу
Виконання декількох операцій рефакторінгу до або під час налагодження коду має певні переваги. Часто стає легше визначити місцеположення помилки. Таким чином, зберігається час роботи над кодом і поліпшується його якість. Добре структурований код також менш схильний до помилок, коли справа доходить до його розширення. Фахівці стверджують, що застосування методу додає переваги будь-якої програми, що має хоча б один з наступних недоліків: Програми, які важко читати і важко змінити. Програми з подвійною логікою. Програми, що вимагають додаткового поведінки, що вимагає зміни коду. Програми зі складною умовної логікою, які важко модифікувати.
Підводячи підсумок, можна стверджувати, що реальні вигоди зазвичай приходять в довгостроковій перспективі, наприклад, при рефакторинге поліпшення існуючого коду pdf. Вони полягають у значно скороченому часу, який розробники витрачають на роботу з налагодження й обслуговування, для підвищення надійності коду. Крім того, дублювання коду скорочується, а повторне використання коду стимулюється. Загальна вартість технічного обслуговування та розробки повинна знизитися, а швидкість команди з реагування на мінливі потреби - збільшитися. Недоліки виправлення ЗА
Якщо існує так багато незаперечних переваг від добре структурованого, зрозумілого коду, і якщо рефакторинг коду програмного забезпечення веде від хаотичного, погано структурованого, схильного до помилок коду до добре продуманому, тоді виникає закономірне питання, чому це роблять не всі розробники програмного забезпечення? На практиці розробники частіше неохоче виконують поліпшення, тому що деякі рефакторинги просто втомлюють. Особливо коли немає ніякої видимої зовнішньої вигоди для цього.
Також може бути винувато управління проектом. Коли керівництво тільки підтримує зовні видимі властивості коду, такі як функціональність і продуктивність, але не звертає уваги на внутрішнє якість коду.
Крім того, існує серйозна небезпека порушення коду за допомогою операцій рефакторінгу. І якщо, наприклад, імена файлів змінюються, простежуваність змін також може стати проблемою.
Навіть якщо розробник програмного забезпечення прагне реорганізувати якийсь погано структурований код. Менеджер може мати зовсім іншу перспективу виконання ЗА і може виступати проти будь-якої спроби змінити робочий код.
Ці проблеми не можна просто ігнорувати, їх необхідно відповідним чином враховувати, як розробникам, так і керівництву. Автоматизація процесу
При проведенні рефакторінгу зовнішнє спостерігається поведінка має гарантовано залишатися незмінним. Якщо він виконується вручну, необхідно часто перебудовувати систему і запускати тести. Тому ручний метод дійсно практичний тільки при дотриманні наступних умов: Система, з якої реорганізований код є частиною, може бути швидко відновлена. Існують автоматичні «регресійні» тести, які можна часто запускати.
Ця ситуація не дуже поширена і означає, що програми рефакторінгу обмежені. Вона стає все більш поширеною, особливо коли все більше людей використовують методи розробки XP (Extreme Programming).
Ще однією перешкодою методу є те, що багато з цих рефакторингов утомливі. Ще важливіше впевненість у тому, що були внесені правильні зміни.
Тому при виконанні поліпшення рекомендується скористатися автоматичними інструментами. Швидкість їх роботи має ще одну перевагу, яка проявляється в середовищі командної розробки. Розробник набагато рідше виконує операції рефакторінгу, якщо задіяний вихідний код також належить іншим розробникам.
Інтеграція з розробниками, які обрали IDE, також приносить багато переваг. По-перше, наявність інструментів під рукою означає, що розробники можуть легко реорганізувати. Їм не потрібно перемикатися між режимами розробки і рефакторинга і замість цього бачити це як частину свого нормального циклу розробки. По-друге, функції IDE, такі як інтеграція керування версіями, які можуть зменшити зусилля методу, такі як переміщення класу або перейменування пакета. Аналізу коду Visual Studio 2017
Передчасна оптимізація може бути коренем усього зла, але застосування інструментів забезпечать ясність, чистоту і безпеку коду. Тестування програми перед відправкою є важливою частиною процесу розробки. Саме тут вступають в силу інструменти і методи аналізу коду та профілювання - вони дозволяють оцінювати код для помилок, вузьких місць і ефективного використання ресурсів обробки і пам'яті.
Сучасні інструменти профілювання коду можуть вказувати прямо на точні рядки коду, які потребують рефакторинге, або на бібліотеки та інші залежності, які є слабкими точками в архітектурі додатки.
До Visual Studio 2012 більшість цих видів аналізу та тестування коду вимагали сторонніх інструментів і ручних завдань зборки, тестування, аналізу, повтору для розробника. Сьогодні Visual Studio має досить міцні інструменти для аналізу. Крім того, є відмінні інструменти, які допоможуть розробнику заглибитися в додаток для тестування продуктивності та оптимізації, шаблонів проектів, які мають ефективні залежності і вбудовані тестові середовища, а також надійні інструменти для інтеграції автоматизованого аналізу і тестування в робочих процесах складання та випуску. Інструменти для налагодження продуктивності
Комплексний набір вбудованих інструментів для рефакторінгу поліпшення проекту існуючого коду був спочатку згрупований концентратор продуктивності і діагностики в Visual Studio 2013, який був додатково вдосконалено та розширено у вікні Налагодження продуктивності та діагностики» і «Відскановані інструменти» в «Візуал Студіо» 2015.
З Visual Studio 2017 ці інструменти настільки інтегровані в середовище розробки, що у них більше немає химерного імені, тим не менш вони продовжують розвиватися. Програма оснащена чудовою документацією і керівництвом з документами Microsoft, починаючи з розділу «Початок роботи з інструментами продуктивності» і «Керівництво для початківців по профілізації продуктивності в Visual Studio.
Користувач знайде інформацію про збір даних та профілізації під час виконання методу не тільки для традиційних додатків .NET Framework, а також для продуктів JavaScript ASP.NET і веб-сайтів, високопродуктивних обчислень (HPC) і тестування навантаження.
Іншим інструментом, яким із задоволенням користуються розробники, виступає рефакторинг коду c PerfView для аналізу продуктивності. Моррісон є старшим архітектором в Microsoft і написав PerfView для внутрішнього аналізу продуктивності та налаштування командами, що створюють .NET Framework і Visual Studio. Тепер це інструмент з відкритим вихідним кодом, який як і раніше знаходиться в активній розробці. Додаткові механізми для профілювання та налагодження
Крім інструментів, доступних від Microsoft, використовуються сторонні інструменти, призначені для задоволення потреб в тонкій настройці: Jains dotTrace Profiler допомагає відстежувати час виконання, збір сміття, розподіл робочого навантаження, продуктивність введення-виведення. Є 10-денна пробна версія, доступна для виконання пробних кроків. Redgate ANTS Performance Profiler - ще один популярний інструмент для проектів на базі .NET Framework забезпечує такий же аналіз синхронізації коду, як і інші інструменти, але також поглиблюється продуктивність запитів до бази даних з підтримкою розширеного профілювання доступу до даних з підтримкою Oracle, MySQL, PostgreSQL. DevExpress CodeRush - ще один інструмент аналізу і рефакторинга для баз даних C #, Visual Basic і XAML. Інструменти аналізу CodeRush не тільки працюють з основними рішеннями, але також мають вбудовану інтегральну тестову інтеграцію, підтримуючу рамки NUnit, xUnit, MSpec і MSTest, а також тестові приклади CoreCLR в середовищі DNX. Microsoft Code Analysis 2017 дає вбудований доступ до більш ніж 100 найбільш популярним правилами FxCop в якості живих аналізаторів. Аналізатори дивляться код C # або Visual Basic по мірі вводу та надають поради щодо продуктивності, безпеки та кращим практикам, а також доступ до словника швидкого виправлення коду. Microsoft DevSkim - це більш комплексна і гнучка структура модулів та аналізаторів коду, орієнтованих на вбудований аналіз безпеки коду при введенні. Потенційні проблеми безпеки виділяються в коді посиланнями на додаткову інформацію одним кліком до безпечного альтернативного коду. Терміни проведення
Використання автоматичних інструментів рефакторінгу робить більш імовірним, що розробник виконає необхідні етапи своєчасно, що зменшують вірогідність появи помилок. Але не менш важливим є вибір строків його проведення.
Планований рефакторинг покращує роботу коду, усуваючи дублювання. Ключовим моментом тут є виправлення його якомога швидше, перш ніж він стане проблемою. В цьому випадку застосовують безперервний рефакторинг, який дуже важливий для безперервної доставки коду.
У кращому випадку розробники часто переключаються між усіма видами рефакторінгу, згаданими вище. При цьому назва типу не має значення, але важливо час його виконання.
Наприклад, якщо при читанні коду, розробник розуміє, що класи або методи можна зробити краще, потрібно зробити це відразу, не відкладаючи, застосувавши звичайні методи вилучення великих збоїв або перейменування методів для кращого читання. Ця платформа Мартіна Фаулера про Workflows допомагає користувачам краще знати, планувати і виконувати поліпшення.
Ось чому кожному програмісту потрібно не тільки знати що таке рефакторинг коду, але і коли правильно його виконувати. Автор: Іван Фролов 9 Листопада, 2018
Категория: Компьютеры
