Som udvikler, hvordan begynder du at arbejde på et nyt projekt...??

Først samler du nogle grundlæggende krav og derefter begynder du på baggrund af kravet at implementere funktionen én efter én. Efterhånden som du kommer videre med dit projekt og lærer mere om det, bliver du ved med at tilføje og ændre koden i din kodebase. Senere ændrer du også koden for at rette fejlen og kanttilfældene.

Men hvad sker der efter et par dage eller måneder...? Hvordan ser din kode ud...?? Er det kompliceret? Er det svært at forstå? Hvis ja, så var du bestemt ikke opmærksom på at forbedre din kode eller omstrukturere din kode. Du har måske skrevet noget duplikatkode uden at se på den eksisterende kode, eller du kan have skrevet nogle længere metoder/funktioner, store klasser, for mange parametre, ikke-intuitive variabelnavne, kodeplacering osv.

Forbedring eller opdatering af koden uden at ændre softwarens funktionalitet eller eksterne opførsel af applikationen er kendt som code refactoring. Det reducerer de tekniske omkostninger og gør koden mere effektiv og vedligeholdelig. Hvis du ikke er opmærksom på koderefaktoriseringsprocessen tidligere, betaler du for fejl i din kode senere. Så ignorer ikke at rydde op i koden.

I en softwareudviklingsproces har forskellige udviklere forskellige kodeskrivningsstile. De foretager ændringer, vedligeholder koden, udvider koden, og det meste af tiden forlader de koden uden kontinuerlig refaktorering. Ikke-refaktoreret kode har en tendens til kode rot: en masse af forvirring og rod i kode såsom duplikatkode, usunde afhængigheder mellem klasser eller pakker, dårlig tildeling af klasseansvar, for mange ansvarsområder pr. metode eller klasse osv. For at undgå alle disse problemer er kontinuerlig refaktorering vigtig.

Nu er spørgsmålet... hvad er teknikkerne til at refaktorisere koden?

Vi vil diskutere nogle populære og almindelige teknikker til at refaktorisere koden, men før det, lad os diskutere nogle hurtige tips...

Tips:

• Du skal udføre kode refactoring i små trin. Foretag små ændringer i dit program, hver af de små ændringer gør din kode lidt bedre og efterlader applikationen i en fungerende tilstand.
• Kør testen TDD og CI efter at have foretaget små ændringer i refactoring processen. Uden at køre disse test, skaber du en risiko for at introducere fejl.
• Opret ikke nye funktioner eller funktionalitet under refaktoreringsprocessen. Du bør refaktorisere koden, før du tilføjer opdateringer eller nye funktioner i din eksisterende kode.
• Refaktoreringsprocessen kan påvirke testresultaterne, så det er godt at få dit QA- og testteam involveret i refaktoreringsprocessen.
• Du skal acceptere, at du ikke vil være fuldt ud tilfreds med din kode. Din refactored kode vil være forældet i nær fremtid, og du bliver nødt til at refactor den igen.

De mest almindelige teknikker til koderefaktorisering

Der er mange tilgange og teknikker til at refaktorisere koden. Lad os diskutere nogle populære...

1. Rød-grøn Refactoring

Red-Green er den mest populære og udbredte kode refactoring-teknik i den agile softwareudviklingsproces. Denne teknik følger test-første tilgang til design og implementering, dette lægger grundlaget for alle former for refactoring. Udviklere tager initiativ til refaktoriseringen i den testdrevne udviklingscyklus, og den udføres i de tre distriktstrin.

• RØD: Det første trin starter med at skrive den fejlslagne røde test. Du stopper op og tjekker, hvad der skal udvikles.
• Grøn: I det andet trin skriver du den enkleste nok kode og får udviklingspasset grøn test.
• Refaktor: I det sidste og tredje trin fokuserer du på at forbedre og forbedre din kode og holde din test grøn.

Så dybest set har denne teknik to adskilte dele: Den første del involverer at skrive kode, der tilføjer en ny funktion til dit system, og den anden del handler om at refaktorere koden, der udfører denne funktion. Husk, at du ikke skal gøre begge dele på samme tid under arbejdsgangen.

2. Refaktorering ved abstraktion

Denne teknik bruges mest af udviklere, når der er behov for at udføre en stor mængde refactoring. Hovedsageligt bruger vi denne teknik til at reducere redundansen (duplikering) i vores kode. Dette involverer klassearv, hierarki, oprettelse af nye klasser og grænseflader, udtrækning, udskiftning af arv med delegationen og omvendt.

Pull-Up/Push-Down metoden er det bedste eksempel på denne tilgang.

• Pull-up metode: Det trækker kodedele til en superklasse og hjælper med at eliminere kodeduplikering.
• Push-down metode: Den tager kodedelen fra en superklasse og flytter den ned i underklasserne.

Træk op i konstruktørens krop, udtræk underklasse, udtræk superklasse, kollaps hierarki, formularskabelonmetode, udtræk grænseflade, erstat arv med delegationen, erstat delegation med arv, tryk ned-feltet, alt dette er de andre eksempler.

Grundlæggende bygger vi i denne teknik abstraktionslaget for de dele af systemet, der skal refaktoriseres, og modstykket, der i sidste ende skal erstatte det. To almindelige eksempler er givet nedenfor...

java lokal datotid

• Indkapslet Mark: Vi tvinger koden til at få adgang til feltet med getter- og setter-metoder.
• Generaliseringstype: Vi opretter mere generelle typer for at tillade kodedeling, erstatte typekontrolkode med staten, erstatte betinget med polymorfi osv.

3. Komponeringsmetode

Under udviklingsfasen af ​​en applikation skriver vi mange gange lange metoder i vores program. Disse lange metoder gør din kode ekstremt svær at forstå og svær at ændre. Kompositionsmetoden bruges mest i disse tilfælde.

I denne tilgang bruger vi strømlinemetoder til at reducere dobbeltarbejde i vores kode. Nogle eksempler er: udtræk metode, udtræk en variabel, inline Temp, erstat Temp med Query, inline metode, opdel midlertidig variabel, fjern tildelinger til parametre osv.

Udvinding: Vi deler koden op i mindre bidder for at finde og udtrække fragmentering. Derefter opretter vi separate metoder til disse bidder, og så erstattes det med et kald til denne nye metode. Ekstraktion involverer klasse, grænseflade og lokale variabler.

Inline: Denne tilgang fjerner antallet af unødvendige metoder i vores program. Vi finder alle kald til metoderne, og så erstatter vi dem alle med metodens indhold. Derefter sletter vi metoden fra vores program.

java null kontrol

4. Forenkling af metoder

Der er to teknikker involveret i denne tilgang ... lad os diskutere dem begge.

• Forenkling af refaktorering af betingede udtryk: Betinget erklæring i programmering bliver mere logisk og kompliceret over tid. Du skal forenkle logikken i din kode for at forstå hele programmet.
  Der er så mange måder at omfaktorere koden og forenkle logikken. Nogle af dem er: konsolidere betinget udtryk og duplikere betingede fragmenter, dekomponere betinget, erstat betinget med polymorfi, fjern kontrolflag, erstat indlejret betinget med guard-klausuler, osv.
• Forenkling af metode kalder refaktorering: I denne tilgang gør vi metodekald enklere og nemmere at forstå. Vi arbejder med samspillet mellem klasser, og vi forenkler grænsefladerne for dem.
  Eksempler er: tilføjelse, fjernelse og introduktion af nye parametre, erstatning af parameteren med det eksplicitte metode- og metodekald, parameteriseringsmetode, lav en separat forespørgsel fra modifikator, bevar hele objektet, fjern indstillingsmetode osv.

5. Flytning af funktioner mellem objekter

I denne teknik opretter vi nye klasser, og vi flytter funktionaliteten sikkert mellem gamle og nye klasser. Vi skjuler implementeringsdetaljerne fra offentlig adgang.

Nu er spørgsmålet ... hvornår man skal flytte funktionaliteten mellem klasser, eller hvordan man identificerer, at det er tid til at flytte funktionerne mellem klasser?

Når du opdager, at en klasse har så mange ansvarsområder, og der foregår for meget, eller når du opdager, at en klasse er unødvendig og ikke gør noget i en applikation, kan du flytte koden fra denne klasse til en anden klasse og slette den helt.

Eksempler er: flyt et felt, udtræk klasse, flyt metode, inline klasse, skjul delegeret, indfør en fremmed metode, fjern mellemmand, indfør lokal udvidelse osv.

6. Forberedende Refaktorering

Denne tilgang er bedst at bruge, når du bemærker behovet for refactoring, mens du tilføjer nogle nye funktioner i en applikation. Så dybest set er det en del af en softwareopdatering med en separat refactoring-proces. Du sparer dig selv for fremtidig teknisk gæld, hvis du bemærker, at koden skal opdateres i de tidligere faser af funktionsudviklingen.

Slutbrugeren kan ikke se sådanne bestræbelser fra ingeniørteamet øje til øje, men udviklerne, der arbejder på applikationen, vil finde værdien af ​​at omstrukturere koden, når de bygger applikationen. De kan spare deres tid, penge og andre ressourcer, hvis de bare bruger lidt tid på at opdatere koden tidligere.

Det er som om, jeg gerne vil 100 miles mod øst, men i stedet for bare at traske gennem skoven, vil jeg køre 20 miles nordpå til motorvejen, og så skal jeg gå 100 miles mod øst med tre gange den hastighed, jeg kunne have, hvis Jeg gik lige derned. Når folk presser dig til bare at gå direkte derned, er du nogle gange nødt til at sige: ’Vent, jeg skal tjekke kortet og finde den hurtigste rute.’ Den forberedende omstrukturering gør det for mig.

Jessica Kerr (Softwareudvikler)

7. Refaktorering af brugergrænsefladen

Du kan lave simple ændringer i brugergrænsefladen og refaktorisere koden. For eksempel: juster indtastningsfelt, anvend skrifttype, omformulering med aktiv stemme, angiv formatet, anvend almindelig knapstørrelse og øg farvekontrasten osv.

Afsluttende ord

Du skal betragte koderefaktoreringsprocessen som at rydde op i det velordnede hus. Unødvendigt rod i et hjem kan skabe et kaotisk og stressende miljø. Det samme gælder for skrevet kode. En ren og velorganiseret kode er altid let at ændre, let at forstå og nem at vedligeholde. Du vil ikke få problemer senere, hvis du er opmærksom på koderefaktoriseringsprocessen tidligere.

To af de mest indflydelsesrige softwareudviklere Martin Fowler og Kent Beck har brugt deres tid på at forklare koderefaktoreringsprocessen og teknikkerne til den. De har også skrevet en komplet bog om dette emne Refactoring: Forbedring af designet af eksisterende kode . Denne bog beskriver forskellige refactoring-teknikker med en klar forklaring på arbejdet med disse refactoring-processer. Vi anbefaler, at du læser denne bog, hvis du ønsker at gå i dybden med koderefaktoriseringsprocessen.