Kode refactoring - Code refactoring

"Refactor" omdirigerer hit. For bruk av "refactor" på Wikipedia, se Wikipedia: Refactoring talk sider .
Denne artikkelen handler om en atferdsbevarende endring. Det er ikke å forveksle med Rewrite (programmering) .

I programmering og software design , refaktorering er prosessen med å omstrukturere eksisterende datakode -changing den facto -uten å endre sin ytre atferd. Refactoring er ment å forbedre utformingen, strukturen og / eller implementeringen av programvaren (dens ikke-funksjonelle attributter), samtidig som funksjonaliteten bevares . Potensielle fordeler med refactoring kan inkludere forbedret kodelesbarhet og redusert kompleksitet ; disse kan forbedre kildekoden ' s vedlikeholdog lage en enklere, renere eller mer uttrykksfull intern arkitektur eller objektmodell for å forbedre utvidelsen . Et annet potensielt mål for refactoring er forbedret ytelse; programvareingeniører står overfor en kontinuerlig utfordring med å skrive programmer som fungerer raskere eller bruker mindre minne.

Vanligvis bruker refactoring en serie standardiserte grunnleggende mikrorefaktorer , som hver er (vanligvis) en liten endring i et dataprograms kildekode som enten bevarer programvarens oppførsel, eller i det minste ikke endrer dens samsvar med funksjonelle krav. Mange utviklingsmiljøer gir automatisk støtte for å utføre de mekaniske aspektene ved disse grunnleggende refaktorene. Hvis det gjøres bra, kan kodereformering hjelpe programvareutviklere med å oppdage og fikse skjulte eller sovende feil eller sårbarheter i systemet ved å forenkle den underliggende logikken og eliminere unødvendige nivåer av kompleksitet. Hvis det gjøres dårlig, kan det mislykkes kravet om at ekstern funksjonalitet ikke endres, introdusere nye feil eller begge deler.

Ved kontinuerlig å forbedre utformingen av koden, gjør vi det lettere og lettere å jobbe med. Dette er i skarp kontrast til det som vanligvis skjer: liten refactoring og mye oppmerksomhet til hensiktsmessig å legge til nye funksjoner. Hvis du kommer inn i den hygieniske vanen med å refactore kontinuerlig, vil du oppdage at det er lettere å utvide og vedlikeholde koden.

-  Joshua Kerievsky, Refactoring to Patterns

Motivasjon

Refactoring motiveres vanligvis av å legge merke til en kodelukt . For eksempel kan metoden for hånden være veldig lang, eller den kan være nesten duplikat av en annen nærliggende metode. Når de er anerkjent, kan slike problemer løses ved å omformulere kildekoden, eller transformere den til en ny form som oppfører seg likt som før, men som ikke lenger "lukter".

For en lang rutine kan en eller flere mindre underrutiner ekstraheres; eller for dupliserte rutiner, kan dupliseringen fjernes og erstattes med en delt funksjon. Unnlatelse av refactoring kan føre til akkumulering av teknisk gjeld ; på den annen side er refactoring et av de viktigste måtene å tilbakebetale teknisk gjeld.

fordeler

Det er to generelle fordeler for refactoring.

  1. Vedlikehold. Det er lettere å fikse feil fordi kildekoden er lett å lese og forfatterens hensikt er lett å forstå. Dette kan oppnås ved å redusere store monolitiske rutiner til et sett med individuelt konsise, velkalte, engangsmetoder. Det kan oppnås ved å flytte en metode til en mer passende klasse, eller ved å fjerne misvisende kommentarer.
  2. Utvidbarhet. Det er lettere å utvide funksjonene til applikasjonen hvis den bruker gjenkjennelige designmønstre , og det gir litt fleksibilitet der ingen tidligere kan ha eksistert.

Performance engineering kan fjerne ineffektivitet i programmer, kjent som software bloat, som skyldes tradisjonelle programvareutviklingsstrategier som tar sikte på å minimere programmets utviklingstid i stedet for tiden det tar å kjøre. Performance engineering kan også skreddersy programvare for maskinvaren den kjører på, for eksempel for å dra nytte av parallelle prosessorer og vektorenheter.

Utfordringer

Refactoring krever ekstrahering av programvaresystemstruktur, datamodeller og avhengighet mellom applikasjoner for å få tilbake kunnskap om et eksisterende programvaresystem. Omsetningen til team innebærer manglende eller unøyaktig kunnskap om den nåværende tilstanden til et system og om designbeslutninger tatt av avgangsutviklere. Ytterligere kodereformeringsaktiviteter kan kreve ytterligere innsats for å gjenvinne denne kunnskapen. Refactoring-aktiviteter genererer arkitektoniske modifikasjoner som forverrer den strukturelle arkitekturen til et programvaresystem. Slik forverring påvirker arkitektoniske egenskaper som vedlikehold og forståelighet som kan føre til en fullstendig omutvikling av programvaresystemer.

Koderefaktoraktiviteter er sikret med programvareintelligens når du bruker verktøy og teknikker som gir data om algoritmer og sekvenser for kodeutførelse. Å gi et forståelig format for den indre tilstanden til programvaresystemstruktur, datamodeller og avhengigheter mellom komponenter er et kritisk element for å danne en forståelse på høyt nivå og deretter raffinerte visninger av hva som må endres, og hvordan.

Testing

Automatiske enhetstester bør settes opp før refactoring for å sikre at rutiner fremdeles oppfører seg som forventet. Enhetstester kan gi stabilitet til selv store refaktorer når de utføres med ett enkelt atomforpliktelse . En felles strategi for å tillate trygge og atomare refaktorer som spenner over flere prosjekter, er å lagre alle prosjekter i et enkelt depot , kjent som monorepo .

Med enhetstesting på plass, er refactoring da en iterativ syklus for å lage en liten programtransformasjon , teste den for å sikre korrekthet og gjøre en annen liten transformasjon. Hvis en test mislykkes på et tidspunkt, blir den siste lille endringen angret og gjentatt på en annen måte. Gjennom mange små trinn beveger programmet seg fra der det var til der du vil at det skal være. For at denne veldig iterative prosessen skal være praktisk, må testene kjøre veldig raskt, ellers må programmereren bruke en stor del av tiden sin på å vente på at testene er ferdige. Tilhengere av ekstrem programmering og annen smidig programvareutvikling beskriver denne aktiviteten som en integrert del av programvareutviklingssyklusen .

Teknikker

Her er noen eksempler på mikrorefaktorer; noen av disse kan bare gjelde visse språk eller språktyper. En lengre liste finner du i Martin Fowlers refactoring-bok og nettside. Mange utviklingsmiljøer gir automatisk støtte for disse mikrorefaktorene. For eksempel kan en programmerer klikke på navnet på en variabel og deretter velge "Encapsulate field" refactoring fra en hurtigmeny . IDE vil da be om ytterligere detaljer, vanligvis med fornuftige standardinnstillinger og en forhåndsvisning av kodeendringene. Etter bekreftelse fra programmereren vil den utføre de nødvendige endringene gjennom hele koden.

  • Teknikker som gir mer forståelse
    • Programavhengighetsgraf - eksplisitt representasjon av data og kontrollavhengigheter
    • Systemavhengighetsgraf - representasjon av prosedyreanrop mellom PDG
    • Programvareintelligens - reverser utviklerens opprinnelige tilstand for å forstå eksisterende avhengigheter innen applikasjonen
  • Teknikker som tillater mer abstraksjon
    • Innkapsling felt - tving kode for å få tilgang til feltet med getter- og settermetoder
    • Generaliser type - opprett mer generelle typer for å tillate mer kodedeling
    • Erstatt typekontrollkode med tilstand / strategi
    • Erstatt betinget med polymorfisme
  • Teknikker for å bryte koden fra hverandre i mer logiske brikker
    • Komponentisering bryter koden ned i gjenbrukbare semantiske enheter som presenterer klare, veldefinerte, brukervennlige grensesnitt.
    • Ekstraktklasse flytter en del av koden fra en eksisterende klasse til en ny klasse.
    • Pakke ut metode for å gjøre en del av en større metode om til en ny metode. Ved å bryte ned kode i mindre biter er det lettere å forstå. Dette gjelder også funksjoner .
  • Teknikker for å forbedre navn og plassering av kode
    • Flytt metode eller flytt felt - flytt til en mer passende klasse eller kildefil
    • Gi nytt navn til metode eller endre navn på felt - endre navnet til et nytt som bedre avslører formålet
    • Trekk opp - i objektorientert programmering (OOP), flytt til en superklasse
    • Trykk ned - i OOP, flytt til en underklasse
  • Automatisk klonoppdagelse

Maskinvare refactoring

Mens begrepet refactoring opprinnelig refererte til refactoring av programvarekode, har man i løpet av de siste årene også blitt omformet kode skrevet på maskinvarebeskrivelsesspråk (HDL). Uttrykket maskinvarerefakturering brukes som forkortelsesuttrykk for omlegging av kode i maskinvarebeskrivelsesspråk. Siden HDL-er ikke anses å være programmeringsspråk av de fleste maskinvareingeniører, er maskinvarerefakturering å betrakte som et eget felt fra tradisjonell kodefakturering.

Automatisert refactoring av analoge maskinvarebeskrivelser (i VHDL-AMS ) har blitt foreslått av Zeng og Huss. I sin tilnærming bevarer refactoring den simulerte oppførselen til en maskinvaredesign. Den ikke-funksjonelle målingen som forbedres, er at refaktorert kode kan behandles av standard synteseverktøy, mens den opprinnelige koden ikke kan. Refactoring av digitale HDL-er, om enn manuell refactoring, har også blitt undersøkt av Synopsys- stipendiat Mike Keating. Målet hans er å gjøre komplekse systemer lettere å forstå, noe som øker designernes produktivitet.

Historie

Den første kjente bruken av begrepet "refactoring" i den publiserte litteraturen var i en artikkel fra september 1990 av William Opdyke og Ralph Johnson . Griswolds doktorgrad avhandling, Opdyke's Ph.D. avhandling, utgitt i 1992, brukte også dette begrepet. Selv om refactoring-kode har blitt gjort uformelt i flere tiår, har William Griswolds doktorgrad fra 1991. Avhandling er et av de første store akademiske verkene om refactoring av funksjonelle og prosessuelle programmer, etterfulgt av William Opdykes 1992-avhandling om refactoring av objektorienterte programmer, selv om all teori og maskineri lenge har vært tilgjengelig som programtransformasjonssystemer . Alle disse ressursene gir en katalog med vanlige metoder for refactoring; en refactoring-metode har en beskrivelse av hvordan du bruker metoden og indikatorer for når du skal (eller ikke bør) bruke metoden.

Martin Fowlers bok Refactoring: Improving the Design of Existing Code er den kanoniske referansen.

Uttrykkene "factoring" og "factoring out" har blitt brukt på denne måten i Forth- samfunnet siden i det minste tidlig på 1980-tallet. Kapittel seks i Leo Brodies bok Thinking Forth (1984) er viet til emnet.

I ekstrem programmering har Extract Method refactoring-teknikken i hovedsak den samme betydningen som factoring i Forth; å bryte ned et "ord" (eller funksjon ) i mindre, lettere vedlikeholdte funksjoner.

Refactorings kan også rekonstrueres posthoc for å produsere kortfattede beskrivelser av komplekse programvareendringer registrert i programvarelager som CVS eller SVN.

Automatisert kodereformering

Mange programvare redaktører og IDEer har automatisk refactoring støtte. Det er mulig å omorganisere applikasjonskode så vel som testkode. Her er en liste over noen av disse redaktørene, eller såkalte refactoring-nettlesere .

Se også

Referanser

Videre lesning

Eksterne linker