Преработка на код или рефакторинг () е процес на изменение на съществуващата вътрешна структура на кода, без да се променя неговият режим на работа.What is Refactoring?, Martin Fowler, refactoring.com/ Прави се с цел подобряване на някои нефункционални елементи на софтуера. Предимствата включват подобрена четливост на кода, намаляване на сложността при експлоатацията на изходния програмен код, по-изразителна вътрешна структура и подобряване на възможността за разширяване.
Непрекъснатото подобряване в проектирането на кода се прави с цел да се постигне по-лесна работа с него. Това е в рязък контраст с това, което се случва обикновено: малко рефакторинг и по-голямо внимание спомагат за целесъобразното добавяне на нови функции. Ако се извършва рефакторинг непрекъснато, по-лесно е поддържането и разширяването на съществуващия код. Joshua Kerievsky, Refactoring to PatternsKerievsky, Joshua (2004). Refactoring to Patterns, Publisher: Addison-Wesley Professional, ISBN-10: 0321213351
Обикновено рефакторингът се извършва чрез прилагане на серия от стандартизирани основни микро-рефакторинги, всеки от които е обикновено малка промяна в изходния програмен код, което или запазва поведението на софтуера, или най-малко не променя неговото съответствие с функционалните му изисквания. Много среди за разработка на софтуери поддържат функционалност, позволяваща автоматичното извършване на тези основни преработки на кода.
Преглед Рефакторингът има за цел да направи програмен код, който е лесен за разбиране. Отличава се от оптимизацията на производителността. Също като нея не променя поведението на програмата, но ускоряват нейния ход. Оптимизацията затруднява разбирането на кода, което е противоположно на рефакторинга.
Причини за използването на рефакторинга Рефакторингът е нужно да се използва постоянно при разработването на кода. Основните стимули за използването му са: необходимостта да се добави нова функция, която не е указана в приетия първоначално код необходимостта да се оправи грешка, която в началото не се вижда преодоляване на трудности при разработката, които са обусловени от сложни логически програми.
Признаци за „лош“ код Рефакторингът в много случаи е въз основа на интуицията, обоснована от опита. Има се предвид някои видими проблеми в кода (): дублиране на кода () дълъг метод по-висок клас дълъг списък от параметри „завистливи“ функции – това е метод, който обикновено се обръща към данни от друг обект излишни временни променливи класове данни негрупирани данни
Чрез рефакторинга може да се открият слабости в дизайна, които може да забавят развитието на кода или повишават риска от грешки в бъдеще.Fowler, Martin (1999). Refactoring: Improving the design of existing code. Addison Wesley. Например, методът на ръка (ръчен метод) може да бъде много дълъг или може да е близо до дублиране с друг близък метод. Веднъж разпознати тези проблеми може да бъдат разрешени от рефакторинга на изходния програмен код или да бъдат преобразувани в нова форма, която води до същия резултат както и преди, но без да има вече заложени скрити слабости. За по-дълга рутинна проверка могат да бъдат подбрани една или повече по-малки подпрограми; при повторна проверка те могат да бъдат заменени или премахнати с една обща функция. Неизпълнението на рефакторинг може да доведе до натрупването на технически дълг ().
Има две основни ползи от извършването на рефакторинг: Поддръжка. По-лесно е да се коригират грешки в изходния програмен код, който е лесен за разчитане и намеренията на създателят му са лесни за разбиране.Martin, Robert (2009). Clean Code. Prentice Hall. Това може да бъде постигнато чрез намаляване на големи монолитни практики в набор от отделни, ясно-наименувани и кратки методи, както и чрез преместване на даден метод в по-подходящ клас или чрез отстраняване на подвеждащи коментари. Разтегливост. По-лесно е да се разширят възможностите в наличния код, ако се използват разпознаваеми структурни модели (), което осигурява известна гъвкавост, която преди не е съществувала. Преди прилагане на рефакторинг към коя и да е част на кода трябва да има обоснован, убедителен набор от автоматични блок тестове(). Тестовете се използват, за да се докаже, че поведението на кода е коректно преди използването на рефакторинг. Ако случайно се окаже, че теста е неуспешен, най-добре е първо да се коригира теста, тъй като в противен случай е трудно да се направи разграничение между грешките в резултат на рефакторинга и вече съществуващите такива. След като се направи рефакторинга, тестовете се провеждат отново, за да се провери дали рефакторинга не е „счупил“ теста. Разбира се, тестовете никога не могат да докажат, че няма грешки, но важното е, че този процес може да бъде икономически по-ефективен от гледна точка на разходите: единични тестове могат да уловят достатъчно грешки и да направят рефакторинга достатъчно безопасен.
След това в процес е един повтарящ се цикъл за извършване на малки трансформации, промени. Тестването на тези трансформации е с цел да се осигури коректност. Ако в някакъв момент теста се провали, последната малка промяна се отменя и се реализира по различен начин. Чрез много малки стъпки програмата се премества от мястото където е била в мястото където искате да бъде. За да могат тези често повтарящи се процеси да бъдат практични, тестовете трябва да работят много бързо или софтуерният инженер ще трябва да прекара голяма част от времето си в изчакване на завършването на тестовете. Привържениците на екстремното програмиране и други гъвкави методологии описват тази дейност като неразделна част от цикъла за разработване на софтуер.
Видове рефакторинг техники Тук са показани някои примери за микро-рефакторинги; някои от тях могат да се прилагат само за определени езици или видове езици. По-дълъг списък може да се намери в книгата на Мартин Фаулър както и сайта на автора.Refactoring techniques in Fowler's refactoring Website Много среди за разработка осигуряват автоматизирани методи за тези микро-рефакторинги. Например, един програмист може да кликне върху името на променливата и след това да избере „Encapsulate field“ refactoring от контекстното меню. Интегрираната среда за разработка (, IDE) e софтуерно приложение, което предоставя цялостна среда на програмистите за разработване на софтуер. IDE може да подскаже допълнителни детайли, които обикновено с подходящи подразбиращи се стойности и визуализация да покажат промените в кода. След потвърждение от страна на програмиста, ще се извършват необходимите промени в целия код.
Техники, които позволяват по-голяма абстракция ()
Encapsulate field (програмиране на полето) – наричано също и „скриване на информация“: Прави невъзможно за потребителите на даден обект да променят неговото вътрешно състояние по неочакван начин; в случай, ако има в кода открито поле, то трябва да стане недостъпно и да се обезпечи достъпа до него. Обобщаващ тип – създаване на повече обобщаващи типове, чрез които да се даде възможност за повече споделяне на кодове. Сменете типа на проверяващия код с Условия/Стратегия.Replace type-checking code with State/Strategy Сменете зависимостта от условия с полиморфизъм.Replace conditional with polymorphism
Техники за разделяне на кода на съставни части с цел по-голяма разбираемост
Компонентността на разделянето на кода в многократно използвани семантични единици, което се изразява в ясно и добре дефиниран, прост за използване интерфейс.
Extract Class – премества част от код от съществуващ клас в нов клас. Extract Method – за да включите част от по-голям метод в нов метод. Чрез разделянето на кода на по-малки парчета, той става по-лесно разбираем. Това се прилага също и при функции.
Техники за подобряване на името и местоположението на кода
Метод на преместване или преместване на поле – да се премести в по-подходящ клас или изходен код (). Преименуване на метод или преименуване на поле – даване на ново име, което по-добре разкрива неговата цел. Изтеглен нагоре – в OOП (обектно-ориентирано програмиране), преместване в суперклас (). Преместен надолу – в OOП (обектно-ориентирано програмиране), преместване в подклас ().
Хардуерен рефакторинг Въпреки че, терминът рефакторинг първоначално се е отнасял изключително за рефакторинг на софтуерен код, през последните години код се споменава и в хардуерно описващи езици (HDL), в които също се извършва рефакторинг. Терминът хардуерен рефакторинг се използва като термин за рефакторинг на код на езици за хардуерно описание. Хардуерния рефакторинг трябва да се разглежда като нещо отделно, тъй като повечето хардуерни инженери не считат HDLs за програмни езици.
Автоматизирания рефакторинг на аналогово описания хардуер (в VHDL-AMS) е предложен от Zeng and Huss.Kaiping Zeng, Sorin A. Huss, „Architecture refinements by code refactoring of behavioral VHDL-AMS models“. ISCAS 2006 В техния подход рефакторинг запазва симултативното поведение на хардуерния замисъл. Нефункционалните измервания, които подобряват рефакторирания код могат да бъдат обработени чрез стандартни инструменти Synthesis, докато при оригиналния код не може да се осъществи такава обработка. Рефакторинг на цифрови (дигитални) HDLs, макар и с ръчен рефакторинг, също е бил изследван от синопсис изследователя Mike Keating.M. Keating:"Complexity, Abstraction, and the Challenges of Designing Complex Systems", in DAC'08 tutorial, (1) , Bridging a Verification Gap: C++ to RTL for Practical Design" M. Keating, P. Bricaud: Reuse Methodology Manual for System-on-a-Chip Designs, Kluwer Academic Publishers, 1999.. Неговата цел е да се направят комплексните системи по-лесно разбираеми, което води до повишаване на производителността на създателите им.
През лятото на 2008 г., е имало интензивна дискусия за рефакторинг на VHDL (VHDL е език за структурно и поведенческо описание на цифрови системи). Английският акроним за VHDL е VHSIC Hardware Description Language, където VHSIC – Very High Scale Integrated Circuit. В превод на български означава Език за описание на хардуер на много големи интегрални схеми. В действителност, VHDL се използва за описание както на малки и прости цифрови системи, така и на изключително сложни такива. С негова помощ е възможно да бъде описан проект на няколко различни нива на абстракция – поведенческо (behavioral), регистрово (data flow, RTL), структурно (structural)). – news://comp.lang.vhdl newsgroup. Дискусията се върти около конкретен рефакторинг извършван от един инженер, както и за това дали да има или не автоматизирани инструменти за рефакторинг.
Към края на 2009 г., Sigasi предлага разработка, която поддържа VHDL рефакторинг.Sigasi launches its first production release for a VHDL development environment
AMIQ DVT, интегрирана среда за хардуерно проектиране и проверка, осигурява възможности за рефакторинг в E, SystemVerilog, Verilog и VHDL.
История В миналото refactoring не е допускан в процесите на развитие. Пример за това е CVS централизирана система за контрол на версиите, позволяваща на няколко разработчици да работят върху един и същ проект. CVS е свободен софтуер, създаден през 1984.