Refactoring ( eng. refactoring ), eller koderedesign, koderevision, ækvivalent transformation af algoritmer - processen med at ændre programmets interne struktur uden at påvirke dets eksterne adfærd og rettet mod at gøre det lettere at forstå dets arbejde [1] [2 ] . Refaktorering er baseret på en række små ækvivalente (det vil sige adfærdsbevarende) transformationer. Da hver transformation er lille, er det lettere for programmøren at følge dens korrekthed, og på samme tid kan hele sekvensen føre til en betydelig omstrukturering af programmet og forbedre dets konsistens og klarhed.
Formålet med refactoring er at gøre programkoden lettere at forstå; uden dette kan refaktoreringen ikke anses for vellykket.
Refaktorering bør skelnes fra ydeevneoptimering . Ligesom refactoring ændrer optimering normalt heller ikke programmets adfærd, men fremskynder kun dets arbejde. Men optimering gør ofte kode sværere at forstå, hvilket er det modsatte af refactoring [3] .
På den anden side skal refactoring også skelnes fra reengineering , som udføres for at udvide softwarens funktionalitet. Som regel går større refactorings forud for reengineering.
Refactoring bør anvendes konstant ved udvikling af kode. De vigtigste incitamenter for implementeringen er følgende opgaver:
På mange måder, når man refaktorerer, er det bedre at stole på intuition baseret på erfaring. Der er dog nogle synlige kodelugte , der kræver refaktorering :
I programmering betyder udtrykket refactoring at ændre kildekoden for et program uden at ændre dets eksterne adfærd. I Extreme Programming og andre agile metoder er refactoring en integreret del af softwareudviklingscyklussen: udviklere veksler mellem at skabe nye tests og funktionalitet og derefter refaktorisere koden for at forbedre dens konsistens og gennemsigtighed. Automatiseret enhedstest sikrer, at refactoring ikke bryder eksisterende funktionalitet.
Refactoring er ikke oprindeligt beregnet til at rette fejl og tilføje ny funktionalitet, det ændrer overhovedet ikke softwarens adfærd [3] , og det hjælper med at undgå fejl og gøre det nemmere at tilføje funktionalitet. Det udføres for at forbedre forståeligheden af koden eller ændre dens struktur, for at fjerne "død kode" - alt dette for at gøre koden lettere at vedligeholde og udvikle i fremtiden. Især kan tilføjelse af ny adfærd til et program være vanskelig med en eksisterende struktur, i hvilket tilfælde udvikleren kan udføre den nødvendige refactoring før tilføjelse af den nye funktionalitet.
Dette kan være at flytte et felt fra en klasse til en anden, tage et stykke kode ud af en metode og gøre det til en selvstændig metode eller endda flytte kode gennem et klassehierarki. Hvert enkelt trin kan virke elementært, men den kumulative effekt af så små ændringer kan radikalt forbedre et projekt eller endda forhindre et dårligt designet program i at falde fra hinanden.
De mest almindeligt anvendte [4] refactoring metoder er:
Essensen af at ændre signaturen for en metode er at tilføje, ændre eller fjerne en metodeparameter. Efter at have ændret metodesignaturen er det nødvendigt at rette opkaldene til den i koden for alle klienter. Denne ændring kan påvirke programmets eksterne grænseflade, desuden er det ikke altid, at udvikleren, der ændrer grænsefladen, har adgang til alle klienter af denne grænseflade, så en form for registrering af grænsefladeændringer kan være påkrævet for efterfølgende overførsel af dem sammen med ny version af programmet.
Hvis en klasse har et offentligt felt, skal du gøre det privat og give adgangsmetoder. Efter "Field Encapsulation" anvendes ofte " Method Relocation " .
Metodeudtrækning består i at udtrække separate fragmenter fra en lang og/eller kræve kommentarer af kode og konvertere dem til separate metoder, med erstatning af passende opkald på brugsstederne. I dette tilfælde gælder reglen: Hvis et stykke kode kræver en kommentar om, hvad det gør, så skal det adskilles i en separat metode. Også en regel: en metode bør ikke optage mere end én skærm (25-50 linjer, afhængigt af redigeringsbetingelserne), ellers har nogle af dens fragmenter uafhængig værdi og er underlagt valg. Fra analysen af det valgte fragments forbindelser med den omgivende kontekst konkluderes der om listen over parametre for den nye metode og dens lokale variabler.
Metodeflytning gælder for en metode, der oftere refererer til en anden klasse end den, den ligger i.
En betinget sætning med flere grene erstattes af et kald til en polymorf metode af en eller anden basisklasse, der har underklasser for hver gren af den oprindelige sætning. Valget af filial er implicit, afhængigt af hvilken forekomst af underklassen opkaldet var adresseret til.
Grundlæggende principper:
Tekniske kriterier for refactoring værktøjer:
Praktiske kriterier for refactoring værktøjer: