Føler du at kodebasen du jobber med er dårlig utformet? Skulle ønske du kunne fokusere på å skrive god kode, i stedet for å traske gjennom gjørmekode hele dagen lang? Ville livet vært enklere hvis bare den gamle kodebasen hadde en klarere struktur?
Hvis du svarte ja på noen av disse spørsmålene, vær oppmerksom på at du ikke er alene. Snarere motsatt, faktisk. Du trenger bare å snakke med folk i mer enn ett minutt på møter eller konferanser for å innse at en betydelig mengde utviklere lider av eldre kode.
Det gjør meg trist når jeg ser kompetente og motiverte utviklere miste troen og ender opp med å lide av den tvilsomme kvaliteten på koden de jobber med. Noen resignerer og bruker til og med år på å lide av eldre kode på daglig basis!
Det trenger ikke være slik. En av måtene å komme seg ut av den spiralen på er å ikke la deg bli mobbet av dårlig kode.
Vis i stedet dårlig kode hvem som er sjefen.
Eldre kode er en bølle
Som ung utvikler kan det være et problem å begynne å jobbe i en kodebase som har vært der en stund utfordring. Enda mer når du nettopp ble uteksaminert fra CS-skolen hvor du for det meste har jobbet med biblioteker eller ad-hoc-prosjekter. Å bli kastet plutselig inn i en stor kodebase som har utviklet seg over år kan være mildt sagt desorienterende.
Det er som om du er den nye ungen på skolen, og de store mobberne har ikke planer om å gjøre livet ditt enklere.
Store funksjoner, store gjenstander, mystiske navn, inkonsekvente og dupliserte komponenter, alle disse mobberne motsetter seg bestemt din forståelse av koden. De vil gjøre alt som står i deres makt for å bremse deg i analysene dine, og selv når du gjør en løsning og tror du er ferdig, vil de kaste en uventet regresjon i ansiktet ditt.
Men barna blir større, mobberne ender opp med å gå ut av skolen, og noen barn vokser til og med inn i de nye mobberne som vil ta seg av den nye generasjonen.
Det er her metaforen brytes sammen. Selv om du kan vokse som utvikler, får ikke tiden eldre kode til å gå noe sted. Den venter på deg, dag ut og dag inn, og prøver å komme i veien for deg. Noen mennesker bruker år på å lide av det!
Hvis du er i det tilfellet, vil jeg at du tar handling ved å fikse koden. Men ikke noen handling. Jeg vil at du skal komme opp med en målrettet strategi , som tar sikte på å gjøre din gamle kode mindre kraftig i sin evne til å gjøre livet ditt surt.
Slå den der det gjør vondt
Det er så mange ting du kan fikse i en eldre kodebase, så mange steder som fortjener en liten makeover, eller til og med en total oppussing.
Men du må innse den harde sannheten:du vil ikke fikse, kunne fikse alt .
Kodebaser som tok mange år med aktivt arbeid som involverte flere til mange mennesker, er store . Å fikse hvert siste problem vil ta måneder eller år, og du har klientforespørsler å tilfredsstille på samme tid. Å dra på et korstog for å prøve å fikse alt som er galt i kodebasen er en utopi. På samme måte er det ofte en forferdelig idé å kaste alt i søpla og skrive det om fra bunnen av.
Uansett hvor mye tid bedriftens retningslinjer tillater for refaktorisering, har du begrensede ressurser. Så du må velge kampene dine veldig nøye.
Hvordan vurdere hvilken refactoring som er verdt teamets tid? Det kommer ned til en grunnleggende økonomisk beslutning:du vil maksimere verdien og minimere kostnadene. Men hva er verdien og kostnadene ved slike refactorings?
Kostnadene ved en refaktorisering
Kostnadene ved en refaktorisering inkluderer tiden for å faktisk endre koden, men ikke bare.
Å endre obskur kode krever at du forstår den først. Så hvis du ikke allerede er klar over det, må du ta med den analysetiden. Slike endringer kan også forårsake regresjoner, så du må ta hensyn til tiden du tror det vil ta å stabilisere refaktoriseringen.
En refaktorering som introduserer grenser og grensesnitt kan gi deg en mulighet til å skrive noen enhetstester rundt det, noe som også kan ta litt tid.
Dessuten, hvis du takler en buggy del av koden, er sjansen stor for at noen andre i teamet prøver å fikse en feil i den samme koden, og å integrere begge rettelsene dine må løse en sammenslåingskonflikt.
Verdien av en refaktorering
Her snakker vi om å redusere kodebasens kapasitet til å komme i veien for deg. Så det må være kode som du leser – eller feilsøker – ofte. Det er liten vits i å refaktorisere kode som du ikke samhandler med ofte. Selv om du ser hvordan du kan gjøre det bedre, og selv om du føler at det ikke ville være for vanskelig.
Dette tar opp et veldig viktig poeng:hvorfor streber vi etter god kode? For kunst, fordi den er vakker? For moral, fordi det er feil å skrive dårlig kode?
Nei. Vi skriver god kode fordi det hjelper virksomheten . God kode fører til færre bugs, raskere integrasjon av nye funksjoner, mindre omsetning i selskapet. Alt dette er forretningsmessige årsaker. Å refaktorisere et stykke kode som ikke utgjør et problem for virksomheten er ensbetydende med å refaktorisere kodebasen til et annet selskap mens vi er i gang.
Vel, faktisk er det en annen grunn til å forbedre kodekvaliteten:det gjør livene våre enklere, som utviklere. Jada, dette er også i næringslivets interesse, men vi kan se det som et mål i seg selv også. Uansett, refaktorisering av et stykke kode som ikke hindrer oss for mye er bortkastet innsats også i den forbindelse.
Spesielt, og jeg vet at det kan høres overraskende ut i begynnelsen, ikke gjør en refaktorisering bare fordi det er billig . Hvis det ikke gir nok verdi, vil du ha bortkastet tid. Du vil være mer takknemlig for å ha brukt en ettermiddag på å lage ett stort treff på en målrettet del av koden, i stedet for 100 små flikk over alt.
Den mest effektive tilnærmingen etter min mening er å være verdidrevet :velg de 2 eller 3 tingene i koden din som bremser deg mest eller er de mest buggy, og som har en rimelig kostnad å fikse. Omvendt, ikke vær kostnadsdrevet :Ikke velg de billigste løsningene du kan gjøre, og se hvilken som er mest nyttig.
La oss nå se hva slags treff som kan ha et rimelig verdi/kostnadsforhold.
Hvor gjør det vondt?
Før du gir noen forslag, husk at du er den som er i den beste posisjonen til å finne ut dine mest verdifulle refactorings. Hva irriterer deg mest i kodebasen din til daglig?
Du kan også spørre teamet ditt for å spørre deres mening om det spørsmålet, og sammen bestemme hva du skal gjøre noe med.
Her er noen forslag, og du er velkommen til å foreslå andre ideer basert på din erfaring:
Skjær opp en stor funksjon
Dette er en klassisk en. Store funksjoner drukner lesere av koden til detaljer på lavt nivå og hindrer dem i å få et stort bilde av hva funksjonen gjør.
Ved å identifisere ansvaret til denne funksjonen kan du dele den i flere underfunksjoner og sette eksplisitte navn på dem, eller sette ut deler av arbeidet til en annen funksjon eller et annet objekt.
Hvis du kommer over den funksjonen ofte, kan denne refaktoriseringen gi mye verdi.
Skjær opp en stor gjenstand
Noen objekter får ekstra ansvar en etter en over tid, og utvikler seg til massive giganter som sitter midt i kodebasen.
Å dele opp medlemmene gjør det mulig å manipulere lettere strukturer som tar mindre mental plass i leserens sinn.
Noen ganger fører det å skjære opp en stor funksjon til å skjære opp et stort objekt, hvis de ulike underfunksjonene opererer på ulike, men distinkte, deler av objektet.
Utsett bivirkninger
Store funksjoner som gir bivirkninger på store gjenstander er notorisk vanskelig å følge. Å gjøre det klart hvilke effekter en funksjon har på objekter hjelper med å følge med og bli mindre overrasket når du feilsøker kode.
En måte å gjøre dette på er å lage flere objekter og metoder const , og skille dataene som er endret fra dataene som er const i et grensesnitt.
Det er enda bedre å ikke ha noen bivirkninger, men som et første skritt på en stor funksjon er dette ikke alltid realistisk å sikte på.
Bruk navn som gir mening
Dårlige navn kan sende deg på feil spor, og få deg til å kaste bort mye tid.
Verdien av å endre noen navn kan være høy, og kostnadene varierer fra lav for et lokalt navn til høyere hvis kodebasen bruker navnet bredt og du ikke har passende verktøy.
Hva annet vil du inkludere som refactorings med høy verdi og rimelige kostnader?
Uansett, ikke la deg bli mobbet av arv eller på annen måte dårlig kode. Snakk med teamet ditt, identifiser de smertefulle punktene og hvordan du kan fikse dem til en rimelig pris. Start i det små, med et par dårlige funksjoner eller gjenstander.
Og når du har identifisert målene dine, treff dem og treff dem hardt.
Relaterte artikler:
- Bruk av dårlig kode for å lære hvordan du skriver god kode
- Riktig holdning til å håndtere eldre kode