Рефакторинга е вид реорганизация. Технически той изхожда от математиката, когато се поставя изразът еквивалентност - факторите са по-чисти начини за изразяване на същото твърдение. Кодът на рефакторинга означава еквивалентност, първоначалните и крайните продукти трябва да бъдат функционално идентични. На практика той прави кода по-ясен и чист, прост и елегантен. Пример за това е диапазонът от преименуване на променливата към влизането на метода в клас на трета страна, за който разработчикът няма права.

Анализ и рефакторинг за създаване на чист код

Това просто означава подобряване на дизайна на съществуващ код, без да се променя неговото наблюдавано поведение. Първоначално замислена в общността Smalltalk, тя вече се превърна в основна технология за развитие. Въпреки че инструментите за рефакторинг позволяват да се приложи много лесно. Важно е за разработчика да разбере какво прави и защо ще помогне, например в ситуация, в която е необходимо да се позволи повторната употреба на повтарящ се блок код.


Всеки рефакторинг е прост процес, който прави една логична промяна в структурата на кода. Ако промените голям брой код едновременно, е възможно да са въведени грешки. Но кога и къде са направени грешките, е трудно да се каже. Ако промените се извършват на малки стъпки с проверките, извършени след всяка стъпка, грешката вероятно възниква в тестовия пробег веднага след въвеждането на кода в системата. извършванеКодексът за рефакториране, би било възможно да се провери тази стъпка и след като стъпката бъде отменена, тя може да бъде разделена на още по-малки стъпки за идентифициране на грешки. Това е предимството на изчерпателни модулни тестове в системата, защитени от екстремно програмиране. Те дават на разработчиците и мениджърите увереност, че рефакторинга не е нарушил системата, кодът ще се държи по същия начин както преди.


Действието на подобряването на кода се извършва приблизително на следните етапи:

Действие



Въпроси, които трябва да се зададат, действия


Идентифициране на проблема



Има ли проблем? Какъв е проблемът?



Характеристики на проблемите



Защо трябва да променя нещо? Какви са ползите? Има ли някакви рискове?



Разработване на решения



Какво трябва да бъде „целевото състояние“ на кода? Какъв тип преобразуване на кода превръща кода в желаното състояние?



Код за промяна



Стъпки, които ще преработят кода.

Обикновено се извършва на малки стъпки. След всяка такава стъпка разработчикът обикновено остава в работеща система, която не функционира програмно. Практиците алтернативно отстраняват грешки и допълват кода между тези стъпки. По този начин, рефакторингът не изключва възможността за промяна на функционалността, а просто казва, че това е друга дейност, свързана с пренареждане на кода.

Процес на непрекъснато управление на качеството

В идеалния случай рефакторинга ще бъде част от непрекъснат процес на подобряване на качеството. С други думи, ще бъде лесно да се преплете с другитеежедневни действия на всеки разработчик на софтуер.
Създаването на чист код с анализ и рефакторинг е полезно, когато възникне грешка и проблемът трябва да бъде фиксиран или кодът трябва да бъде разширен. Процесът на едновременно обслужване или добавяне на нови функции също позволява на ръководителите и разработчиците да бъдат по-склонни да разрешат проблема, тъй като това няма да изисква допълнителен етап на тестване. Ако разработчикът, отговорен за разбирането на кода, е трудно, той ще зададе въпроси и ще започне да документира неясна част, която ще бъде добра отправна точка за прилагането на нови методи. Често времето на операцията по клиринг не ви позволява да направите добро решение веднага. Възможно е функцията да е добавена набързо и да не е отстранена грешка. В тези случаи съответният код трябва да бъде маркиран с бележка FIXME, така че да може да бъде преработена, когато времето е позволено. Такива обстоятелства изискват рефакторинг за подобряване на съществуващия код не за отделни елементи, а за целия проект. Когато дойде време за решаване на натрупаните проблеми, сканирайте FIXME и TODO. В основата на кода ще има всички проблеми за преглед. Тогава те могат да бъдат реорганизирани в съответния приоритет. Рефакторингът е добро нещо, защото сложните изрази обикновено се изграждат от по-прости и по-тромави компоненти. Тя осигурява по-прости компоненти или ги намалява до по-ефективни сложни изрази, в зависимост от това как ще действа програмистът. Например ефективността на рефакторирането на съществуващ кодброй членове и оператори: (x - 1) * (x + 1) = x 2 - 1. Четири термина спрямо три. Трима оператори срещу двама. Изразът от лявата страна обаче е по-лесен за разбиране, тъй като използва по-прости операции. В допълнение, тя предоставя повече информация за структурата на функцията f (x) = x 2 - 1, тъй като корените +/- 1, които биха били трудни за определяне, просто "гледат" от дясната страна.

Области на действие

Софтуерът за рефакторинг за подобряване на съществуващия код е малък в мрежата, но голяма част от него е добре проектиран. С течение на времето размерът на собствения софтуер и неговата сложност нарастват, а грешките се увеличават и следователно надеждността на кода намалява. Разработчиците на софтуер, особено когато не са оригинални автори, все по-трудно се поддържат и разширяват кода. Кодовата база, която във всяка софтуерна компания трябва да бъде ценен актив, в даден момент може да се претовари. Тези негативни процеси могат да причинят преждевременно стареене на софтуера, както е обяснено в работата на Мартин Фаулър "Рефакторинг: Подобряване на съществуващия код". Стратегически важно е вниманието на софтуерните ръководители и разработчици. От практическа гледна точка прилагането на методите за развитие ще забави този процес. Рефакторирането може да елиминира това стареене с подходящо приложение, за предпочитане с добри софтуерни инструменти, които подпомагат идентифицирането, анализирането и описването на проблемите и в крайна сметка позволяването им да бъдат фиксирани.

Често копирайте компонентасе използва от разработчика като по-приемлив метод, тъй като е по-малко объркващ за него. Поне Фаулър вярва в рефакторинга, за да подобри съществуващия код. Текущият изходен код може да се променя с течение на времето от оригиналния дизайн и може да не бъде веднага разбран от разработчика. Той обаче пренебрегва факта, че изходният код има много скрити значения. Коригирането на грешки, открити в изходния код, не може да бъде документирано, но те са много ценни. Рефакторингът запазва тази скрита стойност, като гарантира, че поведението на системата няма да се промени.

Процесът на преименуване на метода

Този пример се отнася за променлива, клас или друг java елемент, който има подвеждащо име и трябва да знае как да преработи този код. Това изисква всички връзки и евентуално актуализации на файлове. Процесът може да включва преименуване на метод в подкласове. От друга страна, преименуването на пакета ще включва и преместване на файлове и директории и актуализиране на системата за управление на версиите. Коригиращи методи:

Преместване на класа. Класът е в грешен пакет, така че трябва да бъде преместен в друг пакет, където е най-подходящ.

Извадка. Дългият метод трябва да бъде разделен на етапи, за да се подобри четивността и удобството на обслужване. Разделът с код с една логическа задача се заменя с повикване към нов метод.

Извличане на суперкласа. Съществуващият клас осигурява функционалността, която трябва да бъде променена по някакъв начин. Като родител на текущия клас се въвежда и абстрактна класатогава общото поведение е "затегнато" към този нов баща.

Замяна на условна стойност с полиморфизъм. Методите на класа могат да проверят определена стойност (ако операторът е превключвател), за да определи правилното действие за изпълнение.

Предимства на метода

Извършването на няколко операции по рефакторинг преди или по време на отстраняване на грешки на кода има някои предимства. Често е по-лесно да се определи местоположението на грешката. По този начин се запазва времето, прекарано в работата с кода и подобряването на неговото качество. Добре структурираният код също е по-малко податлив на грешки, когато става въпрос за неговото разширяване. Експертите казват, че прилагането на метода добавя ползите от всяка програма, която има поне един от следните недостатъци:

Програми, които е трудно да се четат и трудно се променят.

Приложения с двойна логика.

Програми, изискващи допълнително поведение, изискващи промени в кода.

Програми със сложна условна логика, които са трудни за модифициране.

Обобщавайки, може да се твърди, че реалните ползи обикновено идват в дългосрочен план, например, когато рефакторираме подобренията на съществуващия pdf код. Те се състоят в значително по-малко време, което разработчиците харчат за отстраняване на грешки и поддръжка, за да подобрят надеждността на кода. Освен това дублирането на кода се намалява и се стимулира повторното използване на кода. Общите разходи за поддръжка и развитие трябва да намалят, а скоростта на екипа да отговори на променящите се нужди - да се увеличи.

Липса на корекция ЗА

Ако има толкова много неоспорими предимства пред добре структурирания, ясен код и ако рефакторингът на софтуерния код е резултат от хаотичен, лошо структуриран, склонен към код, добре обмислен код, тогава има логичен въпрос, защо не всички разработчици на софтуер правят това ? На практика, разработчиците са по-склонни да извършват подобрения, защото някои рефакторинг просто уморени. Особено когато няма видима външна полза за това. Може да бъде обвиняван и за управление на проекти. Когато ръководството поддържа само външни видими свойства на кода, като функционалност и производителност, но не обръща внимание на вътрешното качество на кода. Освен това съществува сериозен риск от пробив на код чрез операции по рефакторинг. Ако например промените в имената на файловете, проследяването на промените също може да бъде проблем. Дори ако софтуерният разработчик се опита да реорганизира лошо структуриран код. Мениджърът може да има напълно различна гледна точка по отношение на работата на СО и може да се противопостави на всеки опит за промяна на работния код. Тези проблеми не могат просто да бъдат пренебрегнати, те трябва да бъдат надлежно взети под внимание както от разработчиците, така и от ръководството.

Автоматизация на процеса

Когато се извършва рефакторинг, наблюдаваното външно поведение трябва да бъде гарантирано да остане непроменено. Ако се изпълни ръчно, често е необходимо да се възстанови системата и да се проведат тестове. Следователно ръчният метод е наистина практичен само с уважениеследните условия:

Системата, от която реорганизираният код е част, може бързо да бъде възстановена.

Има автоматични "регресионни" тестове, които могат да се провеждат често.

Тази ситуация не е много често срещана и означава, че програмите за рефакторинг са ограничени. Тя става все по-широко разпространена, особено когато все повече хора използват XP (Extreme Programming) методи. Друга пречка за метода е, че много от тези рефакторинг са досадни. По-важното е убеждението, че са направени правилните промени. Следователно, когато се извършва подобрение, се препоръчва използването на автоматизирани инструменти. Скоростта на тяхната работа има още едно предимство, което се проявява в средата за развитие на екипа. Разработчикът извършва рефакторинг операции много по-рядко, ако използваният изходен код също е собственост на други разработчици. Интеграцията с разработчиците, избрали IDE, също носи много ползи. Първо, наличието на налични инструменти означава, че разработчиците могат лесно да реорганизират. Не е необходимо те да преминават между режими на развитие и рефакторинг и вместо това да го разглеждат като част от нормалния цикъл на развитие. Второ, IDE функциите, като например интегрирането на контрол на версиите, могат да намалят усилията на един метод, като например преместване на клас или преименуване на пакет.

Анализ на кода на Visual Studio 2017

Преждевременната оптимизация може да бъде коренът на всяко зло, но инструментите за прилагане осигуряват яснота, чистота и сигурност на кода. Тестването на програмата преди изпращането е важна част от процеса на разработване. Той е тук, който влиза в силаинструменти и методи за анализ на код и профилиране - те ви позволяват да оцените код за грешки, затруднения и ефективно използване на процесите и ресурсите на паметта. Съвременните инструменти за профилиране на кодове могат да насочват директно към точните линии на кода, които изискват рефакторинг, или към библиотеки и други зависимости, които са слаби места в архитектурата на приложенията. Преди Visual Studio 2012, повечето от тези видове анализ на кодове и тестване изискват инструменти на трети страни и ръчно сглобяване, тестване, анализ и повтаряне на задачи за разработчика. Днес Visual Studio има доста силни инструменти за анализ. В допълнение, има отлични инструменти, които ще помогнат на разработчика да се впусне в приложението за тестване на производителността и оптимизацията, шаблоните на проекти, които имат ефективни зависимости и вградени тестови среди, както и стабилни инструменти за интегриране на автоматизиран анализ и тестване в работен процес.

Инструменти за ефективност

Първоначално обединеният набор от вградени инструменти за рефакториране за подобряване на съществуващия код на проекта беше групиран от концентратора за ефективност и диагностика в Visual Studio 2013, който бе допълнително подобрен и разширен в прозореца за настройка на производителността и диагностиката и лентата с инструменти „Сканирани инструменти“ в Visual Studio 2015. С Visual Studio 2017 тези инструменти са толкова интегрирани в средата за разработка, че вече нямат причудливо име, но продължават да се развиват. Програмата е оборудвана с голяма документация и указания отДокументи на Microsoft, започвайки с раздела "Първи стъпки с инструменти за изпълнение" и "Ръководство за ориентиране на производителността на Visual Studio Starter". Потребителите ще намерят информация за събирането на данни и профилирането по време на прилагането на метода, не само за традиционните приложения .NET Framework, но също така и за продуктите и уебсайтовете на ASP.NET javascript, високопроизводителни изчисления (HPC) и тестване на натоварването. Друг инструмент, който се ползва от разработчиците е RefV код за PerfView за анализ на производителността. Морисън е старши архитект в Microsoft и е написал PerfView за вътрешен анализ на производителността и персонализиране от екипи, които създават .NET Framework и Visual Studio. Сега това е инструмент с отворен код, който все още се развива активно.

Допълнителни механизми за профилиране и отстраняване на грешки

В допълнение към инструментите, налични от Microsoft, инструментите на трети страни се използват за посрещане на нуждите за фина настройка: О. Налице е 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 е по-сложна и гъвкава структура на кодови модули и анализатори, които се фокусират върху анализ на сигурността на вградения код, когато се въвеждат. Потенциалните проблеми със сигурността са маркирани в кода на връзката за допълнителна информация с едно кликване до защитен алтернативен код.

Срокове

Използването на автоматизирани инструменти за рефакториране прави по-вероятно предприемачът да извърши своевременно необходимите стъпки, като намали вероятността от грешки. Но не по-малко важен е изборът на условия за провеждането му. Планираният рефакторинг подобрява ефективността на кода, като елиминира дублирането. Ключът тук е да го оправим възможно най-скоро, преди да стане проблем. В този случай се използва непрекъснат рефакторинг, който е много важен за непрекъснатата доставка на кода. В най-добрия случай разработчиците често преминават между всички видове рефакториране, споменати по-горе. В този случай името на типа няма значение, ноВажно е да го изпълним. Например, ако прочетете код, разработчикът разбира, че класовете или методите могат да се правят по-добре, трябва да направите това незабавно без забавяне, като използвате обичайните методи за извличане на основни грешки или методи за преименуване за по-добро четене. Тази платформа Мартин Фаулър за работни потоци помага на потребителите да познават, планират и извършват подобрения. Ето защо всеки програмист се нуждае не само да знае какъв е кодът, но и кога да го изпълни правилно.