10 grunde til, at du har brug for kodeoptimering
Mens vi skriver kode, træffer vi løbende beslutninger og vælger mellem løsninger, som måske synes at være tilsvarende i starten. Senere viser det sig normalt nogle valg resulterer i et mere effektivt program end andre, så opstår der en opgave efter bedste kodningspraksis og optimeringsteknikker naturligt, og vi begynder at se hele udviklingsprocessen som et optimeringsproblem at løse.
Selv om optimeringsproblemer ikke er den eneste udvikler, der regelmæssigt beskæftiger sig med, for eksempel er der beslutningsproblemer og søgesproblemer, optimering er den opgave, der omfatter de forskellige stadier af webudvikling sandsynligvis den mest.
Kodeoptimering kan ske på forskellige niveauer, afhængigt af hvor tæt optimeringen vi udfører, er at maskine kode. I webudvikling kan vi kun udføre højere niveauoptimeringer, da optimering af montage- eller runtime-niveauer ikke er en mulighed for os, men vi har stadig mange muligheder.
Vi kan optimere vores kode på arkitektonisk plan med smarte designmønstre, på kildekodeniveau ved at udnytte bedste kodningspraksis og ved hjælp af passende værktøjer, og vi kan også forbedre vores teams performance ved introducerer kodestilguider i vores workflow.
Uanset hvilken teknik vi vælger at gå sammen med, er der en tommelfingerregel, at enhver kodeoptimeringsindsats skal følge: vi skal altid Udfør optimeringen på en måde, der ikke ændrer betydningen af koden.
Fordelene ved kodeoptimering vokser i takt med væksten i vores projekt, og som Selv i starten kan små projekter blive store med tiden, At erhverve fast kodeoptimeringsfærdigheder har næsten altid målbare positive resultater.
1. Cleaner Code Base
Som et projekt modnes, og flere og flere udviklere begynder at arbejde på det, duplikationer og overlap vises normalt før eller senere, og pludselig indser vi, at vi næppe forstår, hvad der foregår.
Det er ikke et tilfælde at holde princippet DRY (Do not Repeat Yourself) i tankerne et af hjørnestenene i effektiv softwareudvikling. En velstruktureret, omhyggeligt optimeret kodebase, som vi er i stand til genbruge de samme elementer flere gange er altid slankere og mere tidskrævende, og er derfor meget lettere at forstå og arbejde med.
2. Højere konsistens
Konsistens er som husarbejde, når det er ordentligt taget hånd om, at ingen bemærker det, men når det bliver forsømt ser hele stedet rodet ud, og vi finder os i kaos.
Udførelse af fuldstændig konsistens er svært, som At sikre bagudkompatibilitet kan i sidste ende komme i vejen for forbedring, men opmærksom på ved hjælp af kohærente kode retningslinjer, kompatible API'er og konsekvente standarder kan sikkert mindske smerten.
At holde kode konsistens i tankerne er især vigtigt når vi skal håndtere arvskoden, eller i tilfælde af større projekter, som involvere mange udviklere.
3. Hurtigere websteder
Optimering kode svarer til at købe en hurtigere bil. Som følge heraf er vores kode udfører hurtigere, og vores hjemmeside eller ansøgning bruger mindre hukommelse end før. Selvom optimeringsprocessen kan kræve yderligere tid og penge, resultatet er a bedre oplevelse, ikke kun for udviklere, men også for slutbrugere.
Hurtigere kode indebærer kortere sidebelastningstider så godt, hvilket er en big deal i begge verdener af søgemaskine optimering og konvertering markedsføring. Forskning siger det “næsten halvdelen af webbrugerne forventer, at et websted skal indlæses i 2 sekunder eller mindre, og de har tendens til at opgive et websted, der ikke indlæses inden for 3 sekunder”, så hastighed er helt klart ikke et område, som vi sikkert kan ignorere.
4. Bedre kode læsbarhed
Læsbarhed er et vigtigt aspekt af kodeunderholdbarhed. Sløret kode med ad hoc-formatering er svært at læse, derfor svært at forstå, især for udviklere, der er nye til et projekt.
Vi kan beskytte os mod smerten ved at beskæftige sig med indecipherable kode hvis vi anvender visse kodeoptimeringsteknikker, såsom:
- ved hjælp af sammenhængende navngivningskonventioner med meningsfulde navne, såsom BEM
- konsekvent formatering med logisk udnyttelse af indrykning, hvide rum og lodret afstand
- undgå unødvendig støj, som selvforklarende, indlysende kommentarer
Dette er grunden til, at store projekter, som f.eks. WordPress, jQuery og Mootools, har klare kodestilguider, hver involveret udvikler skal følge.
5. Mere effektiv refactoring
Det sker ofte i webudvikling, at vi arver kode fra en anden, og hurtigt forstår, at det er langt fra at være optimal, hvad enten det drejer sig om struktur, ydeevne eller vedligeholdelse. Det samme kan ske med vores egne tidligere projekter, som vi skrev, da vi havde meget mindre erfaring med programmering.
I andre tilfælde Målene for en ellers stor projektforandring over tid, og vi skal prioritere andre ting i ansøgningen end før.
Vi taler om refactoring når vi ændre (rydde op) eksisterende kode for at optimere det uden at ændre nogen af dens funktionaliteter. Refactoring skal udføres med stor omhu, som om det er gjort på den forkerte måde, kan vi nemt ende med en kodebase, der er endnu mindre optimal end originalen var.
Heldigvis har vi mange velprøvede teknikker på vores hænder, der kan gøre refactoring en glidende proces.
6. Mere retfærdig fejlfinding
Fejlfinding tager en væsentlig del af webudviklingsarbejdsprocessen, og det er normalt en kedelig eller endog skræmmende opgave. Det er svært nok, hvis vi skal debugge vores egen kode, men det er meget værre, når vi skal finde bugs i andres, især hvis det er noget som aldrig-spaghetti kode, der bruger andet end funktioner.
Smart design og arkitektoniske mønstre, såsom ved hjælp af objekter og forskellige moduler, og klare kodningsretningslinjer kan lette debugging processen, selvom det sandsynligvis stadig ikke vil være vores mest elskede opgave.
7. Forbedret Workflow
Mange webudviklingsprojekter ledes af distribuerede hold, som f.eks. Open source-fællesskaber eller eksterne teams. En af de sværeste ting i at styre en sådan workflow er at finde en måde, der gør kommunikationen effektiv nok til sætte teammedlemmer i stand til nemt at forstå hinanden, og ikke at skulle konstant diskutere standardindstillinger.
Aftalt om bedste praksis og stilguider kan broere kløften mellem mennesker fra forskellige baggrunde, for ikke at nævne de sædvanlige kommunikationsforstyrrelser mellem design- og udviklingshold i de fleste webprojekter.
Kodeoptimering er også workflow optimering, som om holdmedlemmer taler et fælles sprog og deler de samme erklærede mål, vil de også kunne arbejde sammen uden meget mindre besvær.
8. Nemmere kode vedligeholdelse
Selv om der opbygges noget fra bunden, er det mere sjovt end at opretholde eksisterende kode, nogle gange behøver vi stadig at udføre løbende kodevedligeholdelse. Arbejde med allerede eksisterende systemer kan også give os nye synspunkter om kodeoptimering, da det er en anden oplevelse end tidlige optimeringer i et nyt projekt.
Ved software vedligeholdelse er vi allerede på et stadium, hvor vi kan fange reelle præstations- og effektivitetsproblemer og arbejde sammen med rigtige brugere i stedet for hypotetiske brugssager.
Kodevedligeholdelse får normalt lidt respekt i udviklercirkler, men det kan stadig være en givende opgave, hvis vi følger bedste praksis, som f.eks. Brug af pålidelig versionskontrol, afhængighedsstyring, scanning og testplatforme, og korrekt tage sig af dokumentation.
9. Hurtigere funktionudvikling
Konstant innovation er kernen i at være relevant på vores område, som om vi ikke har vist noget nyt for vores brugere i et stykke tid, kan vi hurtigt blive efterladt. Udvidelse af et projekt, og at tilføje nye funktioner til det er normalt meget hurtigere, hvis vi arbejder med en veloptimeret, ren kodebase.
Bortset fra de allerede diskuterede kodeoptimeringsmetoder, kan udviklingen også få fart, hvis vi holder øje med moderne projektledelsesmetoder, for eksempel hvis vi bruger iterative livscyklusmodeller i stedet for den traditionelle vandfaldsmodel.
10. Mindre teknisk gæld
Udtrykket "teknisk gæld" blev udarbejdet af Ward Cunningham, programmøren, der også udviklede den første wiki. Det sammenligner konsekvenserne af vores dårlige programmeringsbeslutninger, der akkumulerer over tid til finansiel gæld, hvor folk betaler interesse for fremtiden for hurtigt at få penge i nutiden.
Disse mindre end-optimale beslutninger manifesterer sig som regel i form af hurtige rettelser, kopiering og indsættelse af programmering, hard kodning, fragtkult programmering og andre kodende antipatterner og sjusket arbejdsvaner.
Det er grundlæggende umuligt at undgå fuldstændig teknisk gæld, da selv gode beslutninger kan være mindre ønskede konsekvenser i fremtiden, men hvis vi flittigt optimerer vores kode, vil vi helt sikkert være belastet med en meget mindre teknisk gæld.
