10 grunner til at du trenger kodeoptimalisering
Mens vi skriver kode, tar vi kontinuerlig beslutninger og velger mellom løsninger som kan virke ekvivalente først. Senere viser det seg som regel Noen valg gir et mer effektivt program enn andre, så oppstår et oppdrag for beste kodingspraksis og optimaliseringsteknikker naturlig, og vi begynner å se hele utviklingsprosessen som et optimeringsproblem for å løse.
Selv om optimeringsproblemer ikke er den eneste utviklerne som regelmessig håndterer, for eksempel er det beslutningsproblemer og søkeproblemer, optimalisering er oppgaven som omfatter de ulike stadiene av webutvikling sannsynligvis den mest.
Kodeoptimalisering kan skje på ulike nivåer, avhengig av hvor nær optimaliseringen vi utfører, er å maskinkode. I webutvikling kan vi bare utføre høyere nivåoptimaliseringer, Fordi optimering av montering eller kjøretid ikke er et alternativ for oss, har vi fortsatt mange muligheter.
Vi kan optimalisere vår kode på arkitektonisk nivå med smarte designmønstre, på kildekodenivå ved å bruke beste kodingspraksis og ved hjelp av passende verktøy, og vi kan også forbedre ytelsen til teamet vårt introduserer kodestilguider i arbeidsflyten vår.
Uansett hvilken teknikk vi velger å følge med, er det en tommelfingerregel at enhver kodeoptimalisering må følge: vi må alltid utfør optimaliseringen på en måte som ikke endrer betydningen av koden.
Fordelene med kodeoptimalisering vokser i takt med veksten av prosjektet vårt, og som Selv i utgangspunktet små prosjekter kan bli store med tiden, Å få fast kodeoptimaliseringsferdigheter har nesten alltid målbare positive resultater.
1. Cleaner Code Base
Som et prosjekt forfaller, og flere og flere utviklere begynner å jobbe med det, duplikasjoner og overlapper vanligvis før eller senere vises, og plutselig innser vi at vi nesten ikke forstår hva som skjer.
Det er ikke et tilfeldighet at det å holde DRY (Do not Repeat Yourself) -prinsippet i tankene er en av hjørnesteinene til effektiv programvareutvikling. En godt strutured, nøye optimalisert kodebase der vi er i stand til Gjenbruk de samme elementene flere ganger er alltid slankere og tidier, og er derfor mye lettere å forstå og jobbe med.
2. Høyere konsistens
Konsistens er som husarbeid, når det er ordentlig tatt vare på at ingen merker det, men når det blir forsømt, ser hele stedet rotete ut, og vi befinner oss i kaos.
Å gjennomføre fullstendig konsistens er vanskelig, som Å sikre bakoverkompatibilitet kan til slutt komme i vei for forbedring, men betaler oppmerksomhet til bruker koherente kode retningslinjer, kompatible APIer og konsekvente standarder kan sikkert redusere smerten.
Å holde kode konsistens i tankene er spesielt viktig når vi trenger å håndtere arvskoden, eller i tilfeller av større prosjekter som involvere mange utviklere.
3. Faster Sites
Optimaliseringskoden ligner på å kjøpe en raskere bil. Som et resultat, vår kode kjører hurtigere, og vårt nettsted eller søknad bruker mindre minne enn før. Selv om optimaliseringsprosessen kan kreve ekstra tid og penger, Resultatet er a bedre opplevelse, ikke bare for utviklere, men også for sluttbrukere.
Hurtigere kode innebærer kortere sidebelastningstider også, som er en stor avtale i begge verdener av søkemotor optimalisering og konvertering markedsføring. Forskning sier det “nesten halvparten av nettbrukerne forventer at et nettsted skal lastes om 2 sekunder eller mindre, og de har en tendens til å forlate et nettsted som ikke lastes inn innen 3 sekunder”, så fart er tydeligvis ikke et område som vi trygt kan ignorere.
4. Bedre kode lesbarhet
Lesbarhet er et viktig aspekt av kodeunderholdbarhet. Ujevn kode med ad hoc-formatering er vanskelig å lese, derfor vanskelig å forstå, spesielt for utviklere som er nye på et prosjekt.
Vi kan beskytte oss fra smerten ved å håndtere uutslettelig kode hvis vi bruker visse kodeoptimaliseringsteknikker, for eksempel:
- bruker koherente navngivningskonvensjoner med meningsfulle navn, for eksempel BEM
- konsekvent formatering med logisk utnyttelse av innrykk, mellomrom og vertikal avstand
- unngå unødvendig støy, for eksempel selvforklarende, åpenbare kommentarer
Dette er grunnen til at store prosjekter, for eksempel WordPress, jQuery og Mootools, har klare kodestilguider hver utvikler involvert må følge.
5. Mer Effektiv Refactoring
Det forekommer ofte i webutvikling at vi arver kode fra noen andre, og raskt forstår at det er langt fra å være optimal, enten i form av struktur, ytelse eller vedlikeholdsevne. Det samme kan skje med våre egne tidligere prosjekter som vi skrev da vi hadde mye mindre erfaring med programmering.
I andre tilfeller Målene for en ellers stor prosjektendring over tid, og vi må prioritere andre ting i søknaden enn før.
Vi snakker om refactoring når vi endre (rydde opp) eksisterende kode for å optimalisere det uten å endre noen av funksjonene. Refactoring må utføres med stor forsiktighet, som om det er gjort på feil måte, kan vi enkelt ende opp med en kodebase som er enda mindre optimal enn originalen var.
Heldigvis har vi mange velprøvde teknikker på våre hender som kan gjøre refactoring en jevn prosess.
6. Mer rettferdig Debugging
Feilsøking tar opp en betydelig del av webutviklings arbeidsflyten, og det er vanligvis en kjedelig eller til og med skremmende oppgave. Det er vanskelig nok hvis vi må feilsøke vår egen kode, men det er mye verre når vi trenger å finne feilene i andres, spesielt hvis det er noe som aldri endrer spaghetti kode som bruker ingenting annet enn funksjoner.
Smart design og arkitektoniske mønstre, som for eksempel bruker objekter og forskjellige moduler, og klare retningslinjer for koding kan lette feilsøkingsprosessen, selv om det sannsynligvis ikke vil være vår mest elskede oppgave.
7. Forbedret arbeidsflyt
Mange webutviklingsprosjekter drives av distribuerte lag, for eksempel open source-fellesskap eller eksterne lag. En av de vanskeligste tingene i å håndtere en slik arbeidsflyt er å finne en måte som gjør kommunikasjonen effektiv nok til gjør det mulig for gruppemedlemmer å forstå hverandre enkelt, og Ikke å måtte hele tiden diskutere standardinnstillinger.
Avtalt av beste praksis og stilguider kan bygge bro over gapet mellom folk fra forskjellige bakgrunner, for ikke å nevne de vanlige kommunikasjonsmangelene mellom design og utviklingsteam i de fleste webprosjekter.
Kodeoptimalisering er også arbeidsflytoptimalisering, som om lagmedlemmer snakker et felles språk og deler de samme deklarerte målene, vil de også kunne jobbe sammen uten mye mindre stress.
8. enklere kodevedlikehold
Selv om du bygger noe fra bakken, pleier det å være mer moro enn å opprettholde eksisterende kode, noen ganger trenger vi fortsatt å utføre løpende kodevedlikehold. Arbeide med allerede eksisterende systemer kan også gi oss nye synspunkter på kodeoptimalisering, da det er en annen opplevelse enn tidlige optimaliseringer i et nytt prosjekt.
Ved vedlikehold av programvare er vi allerede på et stadium der vi kan få virkelige ytelses- og effektivitetsproblemer, og jobbe med virkelige brukere i stedet for hypotetiske brukstilfeller.
Kodevedlikehold får vanligvis lite respekt i utvikler sirkler, men det kan fortsatt være en givende oppgave hvis vi følger beste praksis, for eksempel ved bruk av pålitelig versjonskontroll, avhengighetsadministrasjon, oppstart og testing av plattformer, og riktig ta vare på dokumentasjon.
9. Raskere funksjonsutvikling
Konstant innovasjon er kjernen i å være relevant i vårt felt, som om vi ikke har vist noe nytt for brukerne om en stund, kan vi raskt bli etterlatt. Å utvide et prosjekt, og legge til nye funksjoner til det, er vanligvis mye raskere hvis vi jobber med en godt optimalisert, ren kodebase.
Bortsett fra de allerede diskuterte kodeoptimaliseringsmetodene, kan utviklingen også gi fart hvis vi holder tritt med moderne prosjektledelsesmetoder, for eksempel hvis vi bruker iterative livscykelmodeller i stedet for den tradisjonelle fossen modellen.
10. Mindre teknisk gjeld
Begrepet "teknisk gjeld" ble laget av Ward Cunningham, programmøren som også utviklet den første wiki. Det sammenlikner konsekvensene av våre dårlige programmeringsbeslutninger som akkumulerer over tid til økonomisk gjeld der folk betaler interesse for fremtiden for å raskt få penger i nåtiden.
Disse mindre enn optimale avgjørelsene manifesterer seg vanligvis i form av raske løsninger, kopiere og lime programmering, hard koding, lastekult programmering og andre kodende antipatterner og slurvete arbeidsvaner.
Det er i utgangspunktet umulig å helt unngå teknisk gjeld, som selv gode beslutninger kan være mindre ønsket konsekvenser i fremtiden, men hvis vi flittig optimaliserer koden vår, så vil vi sikkert være belastet med en mye mindre teknisk gjeld.
