Å være en utvikler, hvordan begynner du å jobbe med et nytt prosjekt...??

Først samler du noen grunnleggende krav, og basert på kravet begynner du å implementere funksjonen en etter en. Etter hvert som du går videre med prosjektet ditt og lærer mer om det, fortsetter du å legge til og endre koden i kodebasen din. Senere endrer du også koden for å fikse feilen og kantsakene.

Men hva skjer etter et par dager eller måneder...? Hvordan ser koden din ut...?? Er det komplisert? Er det vanskelig å forstå? Hvis ja, tok du definitivt ikke hensyn til å forbedre koden din eller omstrukturere koden din. Du kan ha skrevet duplikatkode uten å se på den eksisterende koden, eller du kan ha skrevet noen lengre metoder/funksjoner, store klasser, for mange parametere, ikke-intuitive variabelnavn, kodeplassering, etc.

Å forbedre eller oppdatere koden uten å endre programvarens funksjonalitet eller ekstern oppførsel av applikasjonen er kjent som koderefaktorering. Det reduserer de tekniske kostnadene og gjør koden mer effektiv og vedlikeholdbar. Hvis du ikke tar hensyn til koderefaktoriseringsprosessen tidligere, vil du betale for feil i koden din senere. Så ikke overse å rydde opp i koden.

I en programvareutviklingsprosess har forskjellige utviklere forskjellige kodeskrivingsstiler. De gjør endringer, vedlikeholder koden, utvider koden, og mesteparten av tiden forlater de koden uten kontinuerlig refaktorisering. Ikke-refaktorert kode har en tendens til kode råte: mye av forvirring og rot i kode som duplikatkode, usunne avhengigheter mellom klasser eller pakker, dårlig tildeling av klasseansvar, for mange ansvarsområder per metode eller klasse osv. For å unngå alle disse problemene er kontinuerlig refaktorering viktig.

Nå er spørsmålet… hva er teknikkene for å refaktorisere koden?

Vi vil diskutere noen populære og vanlige teknikker for å refaktorisere koden, men før det, la oss diskutere noen raske tips ...

Tips:

• Du må utføre koderefaktorering i små trinn. Gjør små endringer i programmet, hver av de små endringene gjør koden litt bedre og lar applikasjonen fungere.
• Kjør testen TDD og CI etter å ha gjort små endringer i refaktoreringsprosessen. Uten å kjøre disse testene, skaper du en risiko for å introdusere feil.
• Ikke lag noen nye funksjoner eller funksjonalitet under refaktoriseringsprosessen. Du bør refaktorisere koden før du legger til oppdateringer eller nye funksjoner i den eksisterende koden.
• Refaktoreringsprosessen kan påvirke testresultatene, så det er godt å få QA- og testteamet ditt involvert i refaktoreringsprosessen.
• Du må godta at du ikke vil være helt fornøyd med koden din. Den refaktorerte koden din vil være utdatert i nær fremtid, og du må refaktorisere den på nytt.

De vanligste koderefaktoreringsteknikkene

Det er mange tilnærminger og teknikker for å refaktorisere koden. La oss diskutere noen populære...

1. Rød-grønn Refactoring

Red-Green er den mest populære og mest brukte koderefaktoreringsteknikken i den smidige programvareutviklingsprosessen. Denne teknikken følger test-første tilnærmingen til design og implementering, dette legger grunnlaget for alle former for refactoring. Utviklere tar initiativ til refaktoriseringen til den testdrevne utviklingssyklusen, og den utføres i de tre distriktstrinnene.

• RØD: Det første trinnet starter med å skrive den mislykkede røde testen. Du stopper opp og sjekker hva som skal utvikles.
• Grønn: I det andre trinnet skriver du den enkleste nok koden og får utviklingspasset grønn testing.
• Refaktor: I det siste og tredje trinnet fokuserer du på å forbedre og forbedre koden din og holde testen grønn.

Så i utgangspunktet har denne teknikken to forskjellige deler: Den første delen innebærer å skrive kode som legger til en ny funksjon til systemet ditt, og den andre delen handler om å refaktorisere koden som gjør denne funksjonen. Husk at du ikke skal gjøre begge deler samtidig under arbeidsflyten.

2. Refaktorering ved abstraksjon

Denne teknikken brukes mest av utviklere når det er behov for å gjøre en stor mengde refactoring. Hovedsakelig bruker vi denne teknikken for å redusere redundansen (duplisering) i koden vår. Dette innebærer klassearv, hierarki, opprettelse av nye klasser og grensesnitt, utvinning, erstatning av arv med delegasjonen og omvendt.

Pull-Up/Push-Down metoden er det beste eksemplet på denne tilnærmingen.

• Pull-up metode: Den trekker kodedeler inn i en superklasse og hjelper til med å eliminere kodeduplisering.
• Push-down metode: Den tar kodedelen fra en superklasse og flytter den ned i underklassene.

Trekk opp konstruktørkroppen, trekk ut underklasse, trekk ut superklasse, skjul hierarki, skjemamalmetode, trekk ut grensesnitt, erstatt arv med delegering, erstatt delegering med arv, trykk ned-feltet alt dette er de andre eksemplene.

I utgangspunktet bygger vi i denne teknikken abstraksjonslaget for de delene av systemet som må refaktoreres og motstykket som til slutt skal erstatte det. To vanlige eksempler er gitt nedenfor...

hadoop opplæring

• Innkapslet felt: Vi tvinger koden for å få tilgang til feltet med getter- og settermetoder.
• Generaliseringstype: Vi lager mer generelle typer for å tillate kodedeling, erstatte typekontrollkode med staten, erstatte betinget med polymorfisme, etc.

3. Komponeringsmetode

I utviklingsfasen av en applikasjon skriver vi mange ganger lange metoder i programmet vårt. Disse lange metodene gjør koden din ekstremt vanskelig å forstå og vanskelig å endre. Komponeringsmetoden brukes mest i disse tilfellene.

I denne tilnærmingen bruker vi strømlinjeformede metoder for å redusere duplisering i koden vår. Noen eksempler er: trekke ut metode, trekke ut en variabel, innebygd Temp, erstatte Temp med Query, innebygd metode, dele opp midlertidig variabel, fjerne tilordninger til parametere, etc.

Utdrag: Vi deler koden i mindre biter for å finne og trekke ut fragmentering. Etter det lager vi separate metoder for disse bitene, og deretter erstattes det med et kall til denne nye metoden. Ekstraksjon involverer klasse, grensesnitt og lokale variabler.

På linje: Denne tilnærmingen fjerner antall unødvendige metoder i programmet vårt. Vi finner alle oppfordringer til metodene, og så erstatter vi alle med innholdet i metoden. Etter det sletter vi metoden fra programmet vårt.

css-justeringsbilder

4. Forenkling av metoder

Det er to teknikker involvert i denne tilnærmingen ... la oss diskutere dem begge.

• Forenkle refaktorering av betingede uttrykk: Betinget erklæring i programmering blir mer logisk og komplisert over tid. Du må forenkle logikken i koden din for å forstå hele programmet.
  Det er så mange måter å refaktorere koden og forenkle logikken. Noen av dem er: konsolidere betinget uttrykk og duplisere betingede fragmenter, dekomponere betinget, erstatt betinget med polymorfisme, fjern kontrollflagg, erstatt nestet betinget med guard-klausuler, etc.
• Forenkling av metode kaller refaktorering: I denne tilnærmingen gjør vi metodeanrop enklere og lettere å forstå. Vi jobber med samspillet mellom klasser, og vi forenkler grensesnittene for dem.
  Eksempler er: legge til, fjerne og introdusere nye parametere, erstatte parameteren med det eksplisitte metode- og metodekallet, parameterisere metode, lage en separat spørring fra modifikator, bevare hele objektet, fjerne innstillingsmetode, etc.

5. Flytte funksjoner mellom objekter

I denne teknikken lager vi nye klasser, og vi flytter funksjonaliteten trygt mellom gamle og nye klasser. Vi skjuler implementeringsdetaljene for offentlig tilgang.

Nå er spørsmålet ... når du skal flytte funksjonaliteten mellom klasser eller hvordan du identifiserer at det er på tide å flytte funksjonene mellom klasser?

Når du finner ut at en klasse har så mange ansvarsområder og for mye skjer, eller når du finner ut at en klasse er unødvendig og ikke gjør noe i en applikasjon, kan du flytte koden fra denne klassen til en annen klasse og slette den helt.

Eksempler er: flytte et felt, trekke ut klasse, flytte metode, innebygd klasse, skjule delegat, introdusere en fremmed metode, fjerne mellommann, introdusere lokal utvidelse, etc.

6. Forberedende refaktorering

Denne tilnærmingen er best å bruke når du merker behovet for refaktorisering mens du legger til noen nye funksjoner i en applikasjon. Så i utgangspunktet er det en del av en programvareoppdatering med en egen refactoring-prosess. Du sparer deg for fremtidig teknisk gjeld hvis du merker at koden må oppdateres i de tidligere fasene av funksjonsutviklingen.

Sluttbrukeren kan ikke se slik innsats fra ingeniørteamet øye til øye, men utviklerne som jobber med applikasjonen vil finne verdien av å refaktorisere koden når de bygger applikasjonen. De kan spare tid, penger og andre ressurser hvis de bare bruker litt tid på å oppdatere koden tidligere.

Det er som om jeg ønsker å gå 100 miles østover, men i stedet for å bare traske gjennom skogen, skal jeg kjøre 20 miles nordover til motorveien, og så skal jeg gå 100 miles østover med tre ganger hastigheten jeg kunne ha hvis Jeg gikk rett dit. Når folk presser deg til å bare gå rett dit, må du noen ganger si: ‘Vent, jeg må sjekke kartet og finne den raskeste ruten.’ Den forberedende refaktoreringen gjør det for meg.

Jessica Kerr (Programvareutvikler)

7. Refaktorering av brukergrensesnitt

Du kan gjøre enkle endringer i brukergrensesnittet og refaktorisere koden. For eksempel: juster inntastingsfelt, bruk skrift, ord om i aktiv stemme, angi formatet, bruk vanlig knappstørrelse og øk fargekontrasten, etc.

Siste ord

Du må vurdere koderefaktoreringsprosessen som å rydde opp i det ryddige huset. Unødvendig rot i et hjem kan skape et kaotisk og stressende miljø. Det samme gjelder skrevet kode. En ren og velorganisert kode er alltid lett å endre, lett å forstå og lett å vedlikeholde. Du vil ikke møte problemer senere hvis du tar hensyn til koderefaktoriseringsprosessen tidligere.

To av de mest innflytelsesrike programvareutviklerne Martin Fowler og Kent Beck har viet tiden sin til å forklare koderefaktoreringsprosessen og teknikkene for den. De har også skrevet en komplett bok om dette emnet Refaktorering: Forbedring av utformingen av eksisterende kode . Denne boken beskriver ulike refactoring-teknikker med en klar forklaring på arbeidet med disse refactoring-prosessene. Vi anbefaler deg å lese denne boken hvis du ønsker å gå i dybden med koderefaktoriseringsprosessen.