Jeg kan godt lide refaktorering. Nej ikke sådan her. Jeg elsker refaktorering. Nej, ikke engang det. jeg for pokker Jeg elsker refaktorering.
Jeg kan ikke fordrage dårlig kode og dårlig arkitektur. Jeg kryber, når jeg skriver en ny feature, og den næste time er et fuldstændig rod. Jeg kan bare ikke se på de desværre navngivne variable. Nogle gange, inden jeg går i seng, lukker jeg øjnene og forestiller mig, hvad der kunne forbedres i et projekt. Nogle gange vågner jeg klokken tre om morgenen og går til min bærbare computer for at ordne noget. Jeg ønsker, at koden ikke bare skal være kode på ethvert udviklingstrin, men et kunstværk, der er behageligt at se på og behageligt at arbejde med.

Hvis du deler mine følelser bare lidt, så har vi noget at tale om. Faktum er, at med tiden begyndte noget inde i mig at fortælle mig, at det ikke var den bedste idé at omstrukturere alt, overalt og hele tiden. Misforstå mig ikke, koden skulle være god (og det ville være bedre, hvis den var perfekt), men i den barske virkelighed er det ikke altid klogt konstant at forbedre koden. Jeg er kommet med flere regler for mig selv om rettidigheden af ​​refactoring. Hvis jeg begynder at klø efter at forbedre noget, så ser jeg tilbage på disse regler og begynder at tænke: "Er det nu virkelig det øjeblik, hvor vi skal omstrukturere?" Lad os tænke over, i hvilke tilfælde refaktorering er passende, og i hvilke tilfælde er det ikke så meget.

Ansvarsfraskrivelse. Mest sandsynligt, efter at have læst indlægget, vil mange straks sige: "Ja, dette er allerede blevet diskuteret 600 gange!" eller "Det er så indlysende, hvorfor skrive om det?" Du har måske ret, men her er sagen: kaos foregår stadig i verden omkring os. Det lader til, at alt er klart for alle, men i virkeligheden viser det sig, at det ikke er så klart. Derfor tror jeg, at det ikke vil være for skadeligt at se på dette emne igen. Men hvis du specifikt ikke har nogen problemer med refactoring, så kan du bare springe dette indlæg over, du har det allerede godt.

Refaktorer for tidligt

Kan du huske, hvornår du sidst havde en fast arbejdserklæring, der ikke ændrede sig i flere måneder? Jeg er ikke særlig god til at huske dette. Vi lever i den virkelige verden, kravene ændrer sig hele tiden. Desuden er det ikke nødvendigvis eksterne krav - det kan være dine egne krav til projektet. Lad mig forklare ideen med et eksempel: Lad os sige, at du påtog dig et mellemstort problem i en eller to dage. De første par klasser er allerede skrevet, men der er ikke noget at sætte i gang endnu – processen med at skrive den barske arkitektoniske del er i gang. Og så bemærker du, at en af ​​delene af projektet ikke er skrevet på en særlig universel måde: "Men hvis du om seks måneder skal lave X, så vil alle lide." Det giver mening, at du ikke ønsker at indsende crap-kode til depotet og få andre udviklere til at tænke på dig som et dårligt navn. Og du begynder at refaktorere endnu ikke klar funktion. Nogle gange er dette berettiget, men på sådan en sti burde der være et "FARE"-skilt. Så du ordner én ting, så en anden, så en tredje. Der er gået en uge, funktionen starter stadig ikke, og du siger: "På en eller anden måde blev alt gjort forkert. Men nu jeg Jeg forstod præcis hvordan gør man det. Nu vil jeg hurtigt omskrive alt fra bunden." Hovedproblemet er, at der endnu ikke er modtaget feedback på funktionen, og du er allerede begyndt at arbejde på at forbedre kodebasen. Denne tilgang fører sjældent til succes. Jeg ved ikke med dig, men det sker ofte for mig, at efter at have implementeret en funktion, begynder jeg at forstå, at alt burde fungere lidt anderledes. Og det er ikke, fordi jeg er så dum og ikke kunne tænke det ordentligt igennem på forhånd. Du skal bare "røre" noget funktionalitet for at forstå, hvordan alt skal være i udgivelsen. Nogle gange har du brug for en lille prototype (selv med dårlig kode og fejl) for at diskutere en funktion med kolleger. Nogle gange har du brug for at vise noget til kunden, så han kan sige: "Nej, det var ikke det, jeg ville, alt skulle være omvendt." Nogle gange kan brugerne ikke lide innovationer; de vil have alt, som det var. Problemet med nye funktioner er, at det er svært at forudsige deres skæbne. Det sker ofte, at alle udviklinger smides i skraldespanden, for efter at have diskuteret den første version besluttede holdet at gøre alting anderledes. Generel konklusion: Du bør ikke refaktorere kode for tidligt, især hvis du ikke er sikker på, at denne kode vil forblive 100 % i projektet.

Refaktorering uden mål

Mest sandsynligt har du en udviklingsplan for den nærmeste fremtid. Det er sandsynligt, at du har deadlines (selvom du selv har sat dem). Udgivelser skal ske til tiden; udviklingen bør ikke forsinkes. Du skal kontrollere dig selv, du skal gøre de ting, der er en del af dine umiddelbare mål. Lad os sige, at du har et stykke kode, der ligner komplet... Det ser dårligt ud. Men lad os fortsætte vores antagelse, du arbejder ikke med ham nu. Dette dårlige stykke kode er stabilt, gør sit job med succes og har intet at gøre med din nuværende opgave. Nå, rør ham ikke! Ja, du kan blive ekstremt ked af, at det i den anden ende af projektet alt er meget dårligt. Men læg mærke til, at det lige nu ikke generer dig på nogen måde. Du har aktuelle opgaver, håndtere dem. Selvfølgelig er der opgaver til at forbedre kodebasen, men ikke ofte - ofte er det vigtigere at tilføje ny funktionalitet eller rette fejl. Koncentrer dig om opgaverne, og giv ikke op på dem, fordi der er noget galt et sted.

Refaktorering af hensyn til refactoring

Ok, du er kommet til den konklusion, at du helt sikkert skal refaktorere en del af projektet. Okay, lad os refaktorere. Det ser ud til, at de planlagte forbedringer er gennemført, men så opstår tanken: ”Hvad kan jeg ellers forbedre? Ja, den ting derovre." Og efter den ting, vil denne ting dukke op, og så en anden, og så en anden osv. Du skal forstå, at der er dårlig kode, der er god kode, der er ideel kode. Det sidste vil du aldrig have i et stort projekt. Det betyder ikke, at du ikke skal stræbe efter det, men du skal forstå, at det er uopnåeligt. Normalt er målet at skrive god kode, ikke perfekt kode. Lad os sige, at du efter refactoring har en fuldstændig læsbar kode, der fungerer på en mere eller mindre indlysende måde, hvor der ikke er krykker, og som ikke er så svær at bruge. Stil dig selv spørgsmålet: "Måske er det på tide at stoppe?" Ja, koden kan forbedres. Desuden kan det i et stort nok projekt forbedres i det uendelige. Men lige nu klarer den sine funktioner, den er praktisk at bruge, og den forårsager praktisk talt ikke noget ubehag. Det er meget vigtigt at bestemme selv acceptabelt kvaliteten af ​​koden, hvorefter du stopper med at forbedre den (indtil acceptabilitetsegenskaben går tabt). Husk, at der stadig er så mange forskellige fede ting, du kan tilføje. Der er ingen grund til at refaktorere for at refaktorere sig selv, for den perfekte kodes skyld. Skal refaktorisere, når du har overbevisendeårsager til dette: koden er svær at læse, koden er svær at vedligeholde, koden er svær at udvikle, koden er svær at bruge osv. Hvis der ikke opstår "vanskeligheder", så overbevisende Du har ingen grund til at spilde tid på refaktorisering.

Refaktorering dagen før frigivelse

Det sker, at udgivelsen er i overmorgen/i morgen/i dag/skulle have været i går (understreg evt.). Dette er et vigtigt øjeblik i projektets liv. Det er nødvendigt at være særlig opmærksom på test, reparation af kritiske fejl og endelige forbedringer. Tro mig, det er en rigtig dårlig idé at omarbejde kodebasen (og endnu værre, omarbejde den godt) i det øjeblik, hvor du skal sende projektet til produktion. Erfaren praksis tyder på, at du skal frigive den, og derefter roligt forbedre koden med god samvittighed. Nogle vil spørge: "Hvorfor?" Hvis dette spørgsmål er opstået, så har du sandsynligvis ikke behøvet at lave kompleks refactoring endnu. Jeg vil give dig et hint: Når du omskriver koden, bliver den ikke nødvendigvis bedre - nogle gange kan den gå i stykker. Hvilken kompliceret refaktorering er der - nogle gange fikser du én metode med fem linjer, undlader at holde styr på en eller anden afhængighed, og i den anden ende af projektet kryber der en fejl, som dine yndlingsbrugere straks vil støde på. Det ser ud til, at du ikke gør noget forkert, og så pludselig angriber udyret "Det var ikke indlysende" dig og drukner dig i en dam med en falsk indledende vurdering. Selvom det måske bare er, at jeg er så dårlig en programmør - jeg kan godt lide at bryde ting. Det er meget muligt, at du altid refaktorerer alt helt korrekt og med fuld kontrol over hele projektet. I dette tilfælde kan jeg lykønske dig, men jeg vil stadig ikke afvise rådet om at forbyde pre-release refactoring. Tro mig, refactoring vil ikke forsvinde inden for et par dage, og hele holdet vil sove lidt mere roligt.

Refaktorering af meget gammel kode

Spørgsmålet er svært, meget svært. Situation: Der er et stort antal forfærdelige linjer kode, som du har arvet fra gamle udviklere (måske var disse gamle udviklere dig for flere år siden, endda før du lærte at skrive alt korrekt og på én gang). Koden skal vedligeholdes. Hist og her opstår der krykker og duplikationer, entropien vokser. Hver dag vil jeg mere og mere smide alt ud og omskrive det fra bunden. I sådan et øjeblik er det nødvendigt Meget godt tænke over risiciene. Ja, det er sandsynligt, at sådanne aktiviteter vil være nyttige i fremtiden. Men i hvilket perspektiv præcist og hvor nyttigt? Mest sandsynligt vil du i processen med en stor refaktorering eller omskrivning af individuelle dele erstatte den gamle arbejdskode med ny, perfekt skrevet kode, men med fejl. Og slet ikke fordi du er en dårlig programmør og skriver dårligt. Du kender måske bare ikke denne kode tilstrækkeligt. Du ved måske ikke, hvorfor forfatteren skrev alt på denne måde, men der kan være årsager. Nogle gange skal man skrive meget mærkelig og skæv kode. Jeg kan komme med en masse eksempler: undertrykkelse af vanskelige processoroptimeringer, justering for fejl i et tredjepartsbibliotek, undertrykkelse af nogle flertrådede jambs osv. Jeg siger ikke, at alle disse problemer ikke kan løses normalt. Det er bare, at nogle gange, når du omskriver tilsyneladende absurd kode til normal kode, opstår der fejl. Ja, det var muligt at gøre alt normalt, men du kan simpelthen ikke indse storheden af ​​en hytte lavet af krykker i stedet for pinde, hvis du ikke finder ud af forfatteren af ​​koden, hvorfor han skrev det på denne måde (og sådan en mulighed leveres ikke altid). Vær forsigtig, når du omskriver gammel kode, som du ikke helt forstår (og især hvis du tror, ​​der ikke er noget at forstå).

Hvornår skal du refaktorere?

Jeg beklager, hvis denne artikel giver dig indtryk af, at refaktorering ikke er andet end problemer. Jeg insisterer stadig på, at koden skal være læsbar og smuk, den skal være nem at bruge, og den skal være nem at udvikle. En positiv tilgang er bedre end en negativ, så behandl refactoring ikke som en kilde til problemer, men som en meget god ven, der vil hjælpe dig i svære tider. Desuden kan denne ven sørge for, at der er færre vanskelige øjeblikke i din lyse fremtid. Afslutningsvis vil jeg gerne fremhæve et par punkter, når refactoring virkelig er passende.

• Ingenting at lave. Der er stille tider med nedetid, hvor alle vigtige opgaver er lukket, og nye endnu ikke er blevet tildelt. Nå, det er ikke, at der absolut intet er at lave, men der er en vis mængde fritid. Brug det på at forbedre din kode. Giv enheder klare navne, slip for duplikering, omskriv et dårligt stykke arkitektur. Selvom der ikke er tilføjet nogen ny funktionalitet, bidrager du til roen for de udviklere, som vil fortsætte projektet. Tro mig, det er vigtigt.
• Hverdagslidelser. Og det sker, at der er en del af projektet, der får dig til at sukke tungt hver dag. Og fra nabobordene kan du høre dine kollegers tunge suk. Selvfølgelig, selvom udgivelsen ikke er i morgen, er der stadig vigtige opgaver nok. Der går dog uge efter uge, og at se på dette stykke af projektet bliver mere og mere trist. Sig til dig selv: "Hold op med at finde ud af det her!" Hvis forretningsplanen er skrevet af din chef, så forklar ham, at denne kode simpelthen skal omskrives. Hvis du arbejder for en kunde, så overbevis ham om, at en uge brugt på refactoring vil spare en masse udviklingstid i fremtiden. Hvis du arbejder for brugere, så beslut dig for, at det ville være bedre for disse brugere at vente en uge mere på udgivelsen denne gang, men så nyde stabil software og regelmæssige opdateringer. Ja, det er ikke altid nemt at komme til enighed med alle og med dig selv, men prøv.
• Problemet med sen refaktorering. Reglen om refaktorering for tidligt bør ikke gøres absolut. Nogle mennesker tænker sådan: "Nu forbedrer jeg noget, men det vil ikke være nyttigt - det vil være en skam." Du skal forstå, at der godt kan være vigtige dele i programmets kerne, som ville være bedre skrevet godt. Husk, at jo senere du refaktorerer, jo højere omkostninger, fordi du vil bruge mere tid og kræfter på at omskrive. De kritiske grundelementer (dem, der bruges gennem hele projektet) skal til enhver tid være i den bedst mulige form. Det vil bare være fantastisk, hvis specialet fungerer i dit team "Refactoring er ikke sent. Han kommer strengt, når han finder det passende.”.
• Møde med et monster. Du begynder at skære ny funktionalitet, der skal bruge en gammel del af projektet, der ligner et rigtigt monster: du bliver bange, lige når du ser på den eksterne grænseflade. Hvis tiden tillader det, skal du først rette den grundlæggende del af koden, så du derefter kan fokusere på den nye funktionalitet og ikke bliver distraheret af at hamre krykker i for at genbruge koden.
• Smart perfektionisme. Har du bemærket et dårligt stykke kode? Vil du rette det? Vil du virkelig rette det? Tja, hvis du virkelig virkelig vil, så kan du. Men læg mærke til ordet "rimelig". Balancer tiden brugt på refaktorisering mod fordelen ved at forbedre koden. Gå ikke glip af deadlines, og bliv hængende i endeløse forbedringer. Men hvis du refaktoriserer rettidigt og moderat, vil projektet kun blive bedre.

I stedet for en konklusion

Alt ovenstående er en ren subjektiv generalisering af erfaring med at arbejde på en række projekter. Jeg har selvfølgelig ikke dækket alle livssituationer. Hvert team har sine egne kodekrav, sin egen forretningsplan og sine egne regler. Jeg er sikker på, at mange mennesker har fem historier fra serien "Men jeg havde en sag, hvor alle disse tips ikke virkede." Det er helt normalt, som det skal være. Der er ingen universel sølvkugle til at bestemme mængden af ​​indsats for at forbedre koden ("Vi refaktorerer hver dag i 47 minutter og 23 sekunder, og alt vil være i orden"). Du skal, ud fra din egen erfaring i dit specifikke projekt, i dit specifikke team, forsøge at finde en mellemvej mellem at skrive ny kode og forbedre den gamle. Jeg advokerer kun for en rationel holdning til alt uden fanatisme ("Hvorfor forbedre koden, ny funktionalitet vil ikke dukke op af dette" / "Vi har et presserende behov for at gøre al koden perfekt, så vi senere kan arbejde med den normalt"). Vær smart med at allokere din tid til at arbejde på eksisterende kode, og du vil klare dig.

Eventuelle yderligere tanker om, hvornår du bør eller ikke bør refaktorisere er velkomne. En af de mest værdifulde ting på dette felt er erfaringen fra rigtige udviklere på rigtige projekter.

Refaktorering Kodning er processen med at ændre kildekoden for et program uden at påvirke dets adfærd og sigte på at gøre det lettere at forstå og/eller forenkle dets yderligere support. Refaktorering af ethvert program involverer typisk at lave små ændringer i dets kode, som hver især ikke ændrer opførselen af ​​selve programmet, men på en eller anden måde forenkler og/eller forbedrer koden. Samtidig er det meget vigtigt, at refaktoreringen udføres i små dele, pga når en programmør ændrer en lille del af koden, er det meget lettere for ham at overvåge ændringernes rigtighed og ikke lave fejl. Hvis du refaktoriserer store sektioner af kode på én gang, er der en meget stor sandsynlighed for at lave fejl, som et resultat af, at programmet kan stoppe helt med at fungere. Sandt nok, det faktum, at redigeringerne skal være små, betyder ikke, at refactoring kun er at erstatte variabelnavne eller flytte små sektioner af kode fra et sted i programmet til et andet - refactoring giver dig mulighed for fuldstændigt at omarbejde hele programmet, inklusive logikken i dets adfærd, det vigtigste er - lav ændringer i små dele, og så vil alt være godt.

Refaktorering af mål

Du vil sikkert spørge mig, hvorfor jeg alligevel skriver dette? Og til det faktum, at hvis du omhyggeligt ser på kildekoden, for eksempel kildetekster til hver lektion, har du sikkert bemærket, at jeg ofte ændrer noget i koden, nogle gange i små måder, og nogle gange ganske mærkbart. Det er fordi Jeg bruger selv refactoring og jeg ønsker, at det også skal blive en vane for dig.

Som jeg allerede har sagt - hovedformålet med refactoring Dette er for at gøre koden mere enkel og overskuelig. Hvis koden efter omarbejdning ikke bliver bedre og klarere, så refaktorerede du enten ikke, eller også mislykkedes det. Du må dog ikke forveksle begrebet refactoring med optimering. Som et resultat af optimering bliver koden hurtigere, men ikke nødvendigvis enklere og tydeligere, refactoring tjener netop til at forenkle og forbedre kodelæsbarheden.

Hvilken kode skal refaktoriseres

Du kan og er ofte nødt til at omfaktorere enhver kode - oftest skal du bare stole på dit instinkt, hvis en eller anden kode ikke virker særlig vellykket for dig, eller det ser ud for dig, at du allerede om en uge vil glemme, hvad denne eller den sektion kode gør det - højst sandsynligt skal denne kode omstruktureres. Jeg vil forsøge at formulere de grundlæggende regler, baseret på hvilke du kan forstå, at din kode kræver omarbejdelse:

Hvis dit program har kodeduplikering, er refaktorering næsten helt sikkert påkrævet. Dubletkode i et program er hovedkilden til fejl. Hvis en handling i dit program udføres flere forskellige steder, men med den samme kode, skal du blot sætte denne kode ind i en separat funktion og kalde den. Ellers er der stor sandsynlighed for, at du en dag redigerer kildekoden et sted, men glemmer at rette den tilsvarende kode et andet, så vil der opstå fejl.

Dit program har meget lange metoder/funktioner. Som regel kan en person ikke fuldt ud opfatte og evaluere kodens rigtighed, hvis denne kode tager mere end 2-3 dusin linjer. Sådanne metoder og funktioner bør opdeles i flere mindre, og der bør laves en fælles funktion, som sekventielt vil kalde disse metoder. Forsøg aldrig at reducere længden af ​​din kode ved at skrive flere udsagn på én linje!!! Dette er en af ​​de værste muligheder for at organisere et program, og jeg giver dig en 100% garanti for, at en sådan kode i sidste ende vil føre til fejl!

Lang liste over funktion/metode/konstruktørparametre. Et stort antal parametre gør det normalt ikke kun svært at forstå, hvad en metode eller funktion gør, men gør det også svært at forstå den kode, der bruger disse funktioner. Hvis du virkelig har brug for en funktion til at tage en masse parametre, skal du blot sætte disse parametre i en separat struktur (eller klasse), give denne struktur et rimeligt og forståeligt navn, og sende funktionen et link (eller en pointer) til et objekt af denne struktur eller klasse.

Store klasser kræver også refaktorering. Hvis du har en eller flere store (mere end et par dusin linjer kode) klasser i dit program, bør du straks opdele dem i mindre og inkludere objekter af disse klasser i en fælles klasse. Årsagen til dette er den samme som i det foregående afsnit.

For mange midlertidige variable er også et tegn på dårlig kode, der skal refaktoriseres. Som regel findes mange midlertidige variable i alt for "oppustede" funktioner - når du refaktorerer sådanne funktioner, vil antallet af midlertidige variabler i hver af dem højst sandsynligt blive mindre, og koden bliver meget klarere og mere bekvem

Der er en masse "rodet" lagret data, der er logisk forbundet og kan kombineres til en struktur eller klasse. Logisk relaterede data bør altid gemmes i strukturer/klasser, selvom det kun er 2-3 variabler - det vil ikke gøre nogen dårligere, men koden bliver meget mere tydelig.

Hvis objekter fra en klasse tilgår (henviser til) data fra et andet objekt for meget/hyppigt, bør du genoverveje objekternes funktionalitet. Måske har du truffet den forkerte arkitektoniske beslutning, og du skal ændre den så hurtigt som muligt, før denne fejl spreder sig gennem hele koden.

Prøv ikke at gemme for mange globale variabler. Hvis du virkelig har brug for præcis så mange og ikke mindre globale objekter - prøv i det mindste at gruppere dem i strukturer/klasser, eller i det mindste bare lægge dem i et separat navneområde - så er der en chance for, at du ved en fejl kommer til at bruge en eller anden variabel. blive væsentligt lavere.

Kode refactoring

Målet med arbejdet: lær at omorganisere programkode baseret på refactoring-mønstre.

Fremskridt i arbejdet

1. Studer teoretisk information.
2. Udfør kodeanalyse af softwaren, der udvikles, og enhedstest for at identificere dårligt organiseret kode.
3. Ved hjælp af refactoring-skabeloner, reorganiser programkoden for den software, der udvikles, og enhedstest.
4. Bekræft, at alle enhedstests kører korrekt.
5. Udfyld en beskrivelse af de udførte refactoring-operationer (was-was-refactoring-mønsteret).
6. Juster om nødvendigt designdokumentationen (klassediagrammer, sekvensdiagrammer).
7. Træk konklusioner baseret på resultaterne af arbejdet.

Krav til arbejdets indhold

1. Jobtitel.
2. Målet med arbejdet.
3. Kort formulering af den enkelte opgave.
4. Tabel over ændringer i softwaredesign.
5. Justerede klasse- og sekvensdiagrammer evt.
6. Konklusioner.

Teoretisk information

Tegn på dårligt organiseret kode

Dette er ikke et sæt klare regler, men en beskrivelse af steder, man skal være opmærksom på ved refactoring.

Dublet kode

Hvis du ser de samme kodestrukturer flere steder, så kan du være sikker på, at dette program bliver bedre, hvis du kan forene dem.

I de enkleste tilfælde vil udtræksmetoden hjælpe dig. Når du arbejder med arv, skal du bruge Pull Up Field. Hvis koden ligner, men ikke nøjagtigt, skal du bruge udtræksmetoden og derefter formularskabelonmetoden. Hvis metoderne gør det samme på forskellige måder, skal du vælge en af ​​dem og bruge erstatningsalgoritmen. Hvis du har dubletkode i ikke-relaterede klasser, skal du overveje funktionen Udtræk klasse.

Lang metode

Blandt objektprogrammer lever programmer med korte metoder længst. Jo længere proceduren er, jo sværere er den at forstå. Hvis du har et godt navn til metoden, så behøver du ikke se på dens krop.

Vi følger en heuristik: når vi har lyst til at skrive en kommentar, skriver vi en metode i stedet for. I 99% af tilfældene skal du kun bruge udtræksmetoden for at forkorte metoden. Lokale variabler og parametre kan komme i vejen for dig, så du har muligvis brug for Erstat Temp med Forespørgsel, Introducer Parameter Object og Bevar hele objektet.

Udover kommentarer er sløjfer og forhold også gode tegn. Brug Decompose Conditional til betingelser, og for sløjfer, placer løkkelegemet i en separat metode.

Stor klasse

Når en klasse laver for mange ting, har den normalt for mange felter.

Du kan bruge Extract Class eller Extract Subclass til at udtrække nogle variabler. Når du bestemmer, hvad du skal tage ud, skal du kigge efter fællestræk i variabelnavne, samt om klassen bruger dem alle på samme tid.

Derudover er et klasseværelse med for meget kode også en grobund for dobbeltarbejde og kaos. Brug her også Extract Class eller Extract Subclass.

Hvis din store klasse er en GUI-klasse, så prøv at adskille adfærden fra dataene. Du har muligvis brug for duplikerede observerede data.

Lang liste af muligheder

Dette er et levn fra proceduremæssig programmering. I objektverdenen er der altid en genstand, som du kan stille et spørgsmål til og få alle de svar, du har brug for.

Brug Erstat parameter med metode, bevar hele objektet og introducer parameterobjekt.

Divergent forandring

Divergent forandring er, når en klasse er genstand for forskellige ændringer.

Vi strukturerer vores software for at gøre det nemmere at ændre. Hvis vi vil ændre noget, leder vi efter det eneste sted, hvor vi kan foretage forandringen. Hvis vi ikke kan gøre dette, lugter vi dårligt. Du kan se på klassen og tænke: "Jeg ændrer disse tre metoder, hver gang jeg forbinder en ny database, og disse fire - når jeg tilføjer et finansielt instrument." For at rydde op i dette skal du finde alt, der ændrer sig i dette særlige tilfælde, og bruge Extract Class.

Haglgeværoperation

Det er ligesom divergerende forandringer, men omvendt. Hver gang du skal lave en ændring som denne, laver du en masse små ændringer i forskellige klasser. Dette fører ofte til fejl.

Brug Move Method og Move Field til at placere alle ændringer i én klasse. Hvis ingen klasse ligner en god kandidat, skal du oprette en ny klasse.

Brug Inline Class om nødvendigt. Divergent ændring er, når en klasse er påvirket af forskellige ændringer, hvorimod haglgeværkirurgi er, når en ændring påvirker flere klasser.

Misundelse efter funktion

Formålet med at have objekter i et program er at kombinere data og de metoder, der bruger dem. En typisk dårlig lugt er, når en metode virker mere interesseret i data fra et andet objekt end dets eget.

Bare brug Flyt-metoden til at flytte den til, hvor den skal være. Hvis kun en del af metoden lider af misundelse, så brug først udtræksmetoden.

I det tilfælde, hvor en metode bruger data fra flere objekter, skal du placere den på det objekt, den er mest interesseret i. Brug udtræksmetoden til at isolere afhængigheder.

Brugen af ​​nogle komplekse mønstre, såsom strategi og besøgende, overtræder disse regler. Den generelle anbefaling er altid at finde en balance mellem kompleksitet og den nødvendige fleksibilitet.

Datagrupper

Hvis du kan se, at dataelementer altid rejser sammen, skal du kombinere dem til ét objekt. Brug Udtræk klasse til felter, Bevar hele objektet og Introducer parameterobjekt til metodeparametre.

En god testmetode er: Hvis du fjerner et af dataelementerne, vil de andre så stadig give mening? Hvis ja, så skal en genstand være født her.

Besættelse af primitiver

Begyndende objektprogrammører undgår normalt at bruge små objekter til små opgaver såsom valutaer, intervaller, specielle strenge til telefonnumre og lignende. Du kan komme ud af hulerne ind i den civiliserede verden af ​​objekter ved at bruge Erstat dataværdi med objekt, erstat array med objekt, hvis det er en typekode, så brug Erstat typekode med klasse, Erstat typekode med underklasser og Erstat typekode med strategi .

Switch (Case) Statement

God objektkode bruger meget sjældent Switch-sætninger. Ofte vil du se den samme Switch forskellige steder. Hvis du skal tilføje et andet valg, skal du søge efter alle Switch-udsagn.

I de fleste af disse tilfælde er kuren polymorfi. Hvis Switch skifter efter typekode, skal du bruge Erstat typekode med underklasser eller Erstat typekode med strategi. Du skal muligvis bruge en udtræksmetode og en flyttemetode for at isolere switchen og placere den i den ønskede klasse. Når du har konfigureret din arvestruktur, skal du bruge Erstat betinget med polymorfi.

Parallelle arvehierarkier

Parallelle hierarkier er et særligt tilfælde af haglgeværkirurgi. Hver gang du tilføjer et barn fra en klasse, er du tvunget til at tilføje et barn fra en anden klasse. Lad først forekomster af et hierarki henvise til tilsvarende forekomster af et andet. Brug derefter Move Method og Move Field og det andet hierarki forsvinder lidt efter lidt.

Dovne klasse

Hver klasse, du opretter, koster dig penge at forstå og vedligeholde. En klasse, der ikke gør nok for at betale for sig selv, skal ødelægges. Ofte er dette en klasse, der tidligere var rentabel, men som blev skåret under refactoring. Hvis det er et barn af en anden klasse, skal du bruge Collapse Hierarki. Næsten ubrugelige klasser bør gennemgå Inline Class.

Spekulativ generalisering

Dette er tilfældet, hvor nogen siger, "Åh, se, vi får brug for denne funktion en dag," og derfor ønsker at indsætte alle mulige kroge og specielle sager for at håndtere ting, der ikke er nødvendige. Resultatet er sværere at bruge og vedligeholde.

Hvis du har abstrakte klasser, der ikke gør noget, skal du bruge Collapse Hierarchy. Unødvendig delegering kan fjernes ved hjælp af Inline Class. Metoder med ubrugte parametre skal være underlagt Fjern parameter.

Midlertidigt felt

Nogle gange vil du se kode, der kun bruger instansvariabler i visse tilfælde. Dette gør det meget svært at forstå.

Brug Extract Class til at skabe et hjem for fattige forældreløse børn. Placer al koden relateret til disse felter der. Du kan også slippe af med den betingede kode ved at bruge Introduce Null Object til at oprette et alternativt objekt, når disse felter ikke giver mening.

Besked tråd

Hvis du ser kode, hvor en klient beder om et objekt fra et andet objekt, så har objektet det næste objekt osv. Dette kan være en lang række af getThis-metoder eller en sekvens af midlertidige variable. Under alle omstændigheder antager vi med sådanne opkald eksplicit viden om strukturen af ​​objekterne i kæden. Enhver ændring i relationerne vil resultere i en ændring af denne kode. Her skal du bruge Hide Delegate. Se, hvorfor opkaldsresultatet bruges. Brug udtræksmetoden og derefter flyttemetoden for at flytte den længere op i kæden. Nogle er imod enhver kæde af metoder. Vi står for mådehold.

Mægler

En af hovedegenskaberne ved objekter er indkapsling. Du spørger direktøren, om han er ledig til et møde. Han uddelegerer beskeden til sin planlægger og svarer. Du behøver ikke at vide, om han bruger en planlægger, en elektronisk dims eller en sekretær.

Dette kan dog gå for vidt. Du ser på en klasses grænseflade og ser, at halvdelen af ​​dens metoder blot uddelegerer opkald til andre klasser. Tid til at bruge Fjern Middle Man og tal direkte til de objekter, der ved, hvad der foregår. Hvis kun nogle metoder uddelegerer, så kør Inline-metoden på dem. Hvis du tilføjer adfærd ud over delegering, skal du bruge Erstat delegation med arv.

Ubegrundet intimitet

Nogle gange kommer undervisningen for tæt og bruger for meget tid i hinandens private dele.

Brug Move Method og Move Field til at adskille dele og reducere nærheden. Se om du kan organisere en Change Todirectional Association til Unidirectional. Hvis klasser virkelig har en fælles interesse, skal du bruge Extract Class til at placere de fælles dele ét sted.

Arv fører ofte til unødig intimitet. Efterkommere ved altid mere om deres forfædre, end deres forfædre ønsker. Brug Erstat arv med delegation, når det er tid til at forlade hjemmet.

Ufuldstændig biblioteksklasse

Ofte er vi ikke helt tilfredse med en biblioteksklasse, men vi kan ikke anvende noget som Move Method på den. Hvis du har brug for at tilføje et par metoder, skal du bruge Introducer Foreign Method. Hvis du skal tilføje en masse, skal du have Introducer Local Extension.

Data klasse

Der er klasser, der kun indeholder felter og metoder til at få adgang til dem. Disse er bare dumme beholdere til data, og højst sandsynligt manipulerer andre klasser dem i for mange detaljer. Anvend først Encapsulate Field og Encapsulate Collection, mens ingen kigger. Se, hvor klassedataene bruges. Prøv at bruge Move-metoden til at flytte denne kode ind i selve dataklassen. Dataklasser er som børn. De er nødvendige i de indledende faser. Men for at opføre sig som en voksen genstand, må de tage ansvar.

Afvist arv

Underklasser arver metoder og data fra deres forfædre. Men nogle gange udnytter de ikke det, de får.

Det traditionelle svar er, at hierarki er dårligt. Du skal oprette en ny afledt klasse og anvende Push Down Method og Push Down Field. Men du kan gætte ud fra vores sarkastiske brug af ordet traditionel, at vi ikke altid vil anbefale det. Vi bruger arv til genbrug. Den er ledsaget af en dårlig lugt, men den er normalt ikke særlig stærk. Hvis en afvist arv er et problem, så brug traditionelle råd.

Mozilla FireFox, for at tydeliggøre versionen af ​​dette softwareprodukt, skal du udvide afsnittet "Hjælp" i menuen og klikke på det nederste punkt ("Om Mozilla Firefox"). Et separat lodret vindue åbnes, hvor en indikation af den nøjagtige version af tre tal adskilt af en prik er placeret under den store Firefox-inskription.

I Opera-menuen skal du også åbne sektionen "Hjælp" og klikke på det nederste punkt ("Om programmet"). Men her, i modsætning til alle andre browsere, dukker et separat vindue ikke op - et almindeligt vindue åbnes, hvoraf det meste er optaget af lister over forskellige typer lagring oprettet af browseren i din. I begyndelsen af ​​denne liste er der en separat sektion, som kaldes "Version Information". Operaversionsnumre er to tal adskilt af en prik.

I Internet Explorer vil du ved at åbne den samme menusektion kaldet "Hjælp" og klikke på det sidste punkt på listen, "Om", se et vindue med en streng påmindelse om overholdelse af copyright. Ud over denne tekst er der ikke mindre alvorlig kode, der angiver browserversionen. I den er så mange som fire tal adskilt af en prik, hvoraf det ene allerede har overskredet det firecifrede mærke.

I Google Chrome er der ud over den lige så alvorlige kode for den anvendte version (fire tal adskilt af prikker) også en indikation af den seneste modifikation, der er tilgængelig for installation. For at se et separat vindue med alle disse oplysninger, skal du åbne menuen ved at klikke på skruenøgleikonet øverst til højre i vinduet browser, og vælg "Om Google Chrome".

I Apple Safari-browseren, for en sikkerheds skyld, er der to måder at åbne et vindue med versionsoplysninger på. En af dem ligner metoden til Chrome-browseren - du skal klikke på ikonet, der er placeret på samme sted (her tegnes et tandhjul på det) og vælge "Om Safari". Den anden minder meget om Mozilla og IE - du skal åbne sektionen "Hjælp" i menuen og klikke på det nederste element ("Om Safari"). Apple kom med den længste versionsbetegnelse: Ud over tre tal adskilt af en prik er der også et supplement af tre tal i parentes.