Share
Kode lukter og deres refactorings kan være veldig skremmende og skremmende for nybegynnere. Så i denne serien har jeg forsøkt å gjøre dem enkle å forstå, både for litt erfarne Ruby-utviklere og forretter.
Denne siste artikkelen nevner noen flere lukter du bør passe på og oppsummere hva denne lille serien ønsket å oppnå. En siste whiff, hvis du liker ...
Den siste artikkelen i denne serien er noe som en bonusrunde. Jeg ønsket å introdusere deg til noen flere lukter som kan løses raskt og uten mye oppstyr. En for veien, så å si. Jeg tror med den kunnskapen du har samlet fra de forrige artiklene, vil de fleste ikke en gang trenge kodeeksempler for å pakke hodet rundt.
Når du åpner en bok om refactoring, vil du lett finne flere lukter enn vi har diskutert. Men med disse store under beltet ditt, vil du være godt forberedt på å håndtere noen av dem.
Svært anvendte kommentarer er sjelden en god ide, sannsynligvis aldri. Hvorfor ikke? Fordi det kan tyde på at designet ikke snakker for seg selv. Det betyr at koden din er sannsynligvis så komplisert å forstå at den trenger bokstavelige forklaringer.
Først av alt, hvem vil gå gjennom hoards of text i koden din - eller verre, gjennom kode som er vanskelig å forstå. Jackpot hvis begge er en vanlig forekomst. Det er bare dårlig form og ikke veldig hensynsfullt til folk som kommer etter deg - ingen forfølgelse, masochister, tortur din fremtidige selv alt du vil.
Du vil skrive kode som er uttrykkelig nok i seg selv. Lag klasser og metoder som snakker for seg selv. I det beste scenariet forteller de en historie som er lett å følge. Det er trolig en av grunnene konvensjoner over konfigurasjoner ble så innflytelsesrik. Å gjenoppfinne hjulet er absolutt noen ganger en god praksis for å skjerpe din forståelse og å utforske nytt territorium, men i raske utviklingsmiljøer søker kollegerne etter klarhet og rask navigasjon - ikke bare innenfor filene dine, men også innenfor det mentale kartet du lager i koden din.
Jeg ønsker ikke å drive bort i et helt nytt emne, men navngi spiller en stor rolle i alt dette. Og overdreven kommentar i koden din er i motsetning til god navngivning og konvensjoner. Ikke misforstå, det er greit å legge til kommentarer - bare vær på banen som "belyser" koden din i stedet for å distrahere fra den. Kommentarer bør absolutt ikke være instruksjoner for smart kode som det meste du kan dechifisere fordi du ønsket å vise seg. Hvis du holder metodene dine enkle - som du burde - og kaller alt med hensyn, så har du lite behov for å skrive hele romaner mellom koden din.
Hold deg unna følgende:
Det er også nyttig å bryte ut deler av metoder via ekstraktmetode og gi denne delen av en metode et navn som forteller oss om sitt ansvar - snarere enn å ha alle detaljene forvirrende på et høyt nivå forståelse av hva som skjer i metodens kropp.
def create_new_agent ... end ... # opprett ny agent, besøk root_path click_on 'Create Agent' fill_in 'Agentnavn' med: 'Jinx' fill_in 'Email' med: '[email protected]' fill_in 'Passord' med: 'secretphrase 'click_button' Send '...
Hva er enklere å lese? En brainer selvsagt! Bruk den gratis kjørelengde du får ved å navngi ting riktig via ekstraherte metoder. Det gjør koden så mye smartere og enklere å fordøye - pluss fordelene med refactoring på ett sted hvis det brukes, selvfølgelig. Jeg vedder på at dette vil bidra til å trimme ned dine kommentarer med et betydelig beløp.
Dette er en enkel. Ikke bruk tilbakeringinger som ikke er relatert til persistenslogikk! Dine objekter har en levetidssyklus-oppretting, lagring og sletting av objekter, så å si - og du vil ikke "forurense" den logikken med annen oppførsel som forretningslogikken i klassene dine.
Hold det enkelt, husk? Typiske eksempler på hva du skal unngå, er å sende e-post, behandle betalinger og ting. Hvorfor? Fordi feilsøking og refactoring din kode skal være så enkelt som mulig, og rotete tilbakeringinger har et rykte om å forstyrre disse planene. Tilbakeringinger gjør det litt for lett å gjørme vannene og skyte deg selv i foten flere ganger.
Et annet problematisk punkt om tilbakekallinger er at de kan skjule implementeringen av forretningslogikk i metoder som #lagre eller #skape. Så vær ikke lat og misbruk dem bare fordi det virker som om det er praktisk!
Den største bekymringen er selvfølgelig kobling av bekymringer. Hvorfor la opprettelsesmetoden til SpectreAgent, for eksempel, avtale med levering av a #mission_assignment eller noe? Som så ofte, bare fordi vi kan gjøre det-lett-betyr ikke at vi burde. Det er en garantert bite i rumpa som venter på å skje. Løsningen er faktisk ganske grei. Hvis en tilbakeringings oppførsel ikke har noe å gjøre med utholdenhet, må du bare opprette en annen metode for det, og du er ferdig.
Dårlige navnevalg har alvorlige konsekvenser. I virkeligheten slår du bort andres tid - eller enda bedre din egen, hvis du må gå tilbake til dette stykke kode i fremtiden. Koden du skriver er et sett med instruksjoner som leses av deg og andre mennesker, så en rent logisk, super prosaisk, altfor smart eller verre, en vanlig lat tilnærming til å navngi ting er en av de verste tingene du kan legge igjen. Målet er å gjøre koden enklere å forstå ved å gi bedre navn.
Klarhetskompetanse falsk intelligens eller unødvendig konsistens hvilken som helst dag i uken! Arbeid hardt med navngivningsmetoder, variabler og klasser som gjør det enkelt å følge en slags tråd.
Jeg vil ikke gå så langt som å si at du bør sikte på å prøve å fortelle en historie, men hvis du kan, gå for det! Maskiner er ikke de som trenger å "lese" koden din - det drives av dem selvsagt. Kanskje det er en grunn til at begrepet "Software Writer" har vokst på meg litt sist. Jeg sier ikke at engineering-aspektet bør bli redusert, men å skrive programvare er mer enn å skrive sjeldne instruksjoner for maskiner - minst programvare som er elegant og gnister glede å jobbe med.
Ikke freak ut hvis dette viser seg å være mye vanskeligere enn du trodde. Navngivning er notorisk vanskelig!
Mixins er en lukt? Vel, la oss si at de kan være stinkende. Flere arv gjennom Mixins kan være nyttig, men det er et par ting som gjør dem mindre nyttige enn du kanskje trodde da du startet med OOP:
Jeg foreslår at du leser litt på "Composition Over Arv". Hensikten med det er at du bør stole mer på gjenbruk av dine egne, separat sammensatte klasser enn på arv eller underklasse. Mixins er en arvform som kan brukes til god bruk, men også noe du bør være litt mistenksom på.
Se opp for gjentatte ganger å passere de samme flere argumenter i metodene dine. Det antyder ofte at de har et forhold som kan trekkes ut i en egen klasse - noe som igjen ofte kan forenkle fôring av disse metodene med data ved å redusere størrelsen på argumenter. Enten det er verdt å introdusere en ny avhengighet, er det du må veie, skjønt.
Denne lukten er en annen form for subtile duplisering som vi kan håndtere bedre. Et godt eksempel er å sende en lang liste over argumenter som utgjør en adresse og kredittkort info. Hvorfor ikke pakke alt dette i en eksisterende klasse, eller ta ut en ny klasse først og send i adresse- og kredittkortobjektene i stedet? En annen måte å tenke på er å ha et utvalgsobjekt i stedet for en start og en slutt. Hvis du har forekomstvariabler som faller for den lukten, er det å vurdere å ta ut en klasse. I andre tilfeller a parameterobjekt kan tilby den samme kvaliteten på abstraksjonen.
Du vet at du har oppnådd en liten seier hvis systemet er lettere å forstå, og du fant et nytt konseptlignende kredittkort - som du kunne innkapsles i en gjenstand.
Gratulerer! Du har nivellert dine OOP-ferdigheter betydelig! Boss nivå status nærmer seg. Nei, seriøst, god jobb hvis dette hele emnet var ganske nytt for deg!
Som en endelig anbefaling, vil jeg at du skal ta bort en ting. Husk at det ikke finnes noen oppskrift som alltid vil fungere. Du må veie hvert problem annerledes og blande ofte forskjellige teknikker til dine behov. Også for resten av karrieren din er dette sannsynligvis noe du aldri vil slutte å slite med. Jeg antar en god kamp, skjønt, en kreativ og utfordrende.
Dette er et lite gjetning, men jeg føler at hvis du forstod det meste av emnene vi dekket, vil du være godt på vei til å skrive kode andre utviklere liker å oppdage. Takk for din tid å lese denne lille serien, og lykke til å bli en lykkelig hacker!
Accentsconagua