10 skäl till att du behöver kodoptimering
Medan vi skriver kod gör vi ständigt beslut och väljer mellan lösningar som kan verka ekvivalenta först. Senare blir det vanligtvis det vissa val ger ett effektivare program än andra, så uppstår en strävan efter bästa kodningspraxis och optimeringstekniker naturligt, och vi börjar se hela utvecklingsprocessen som ett optimeringsproblem att lösa.
Även om optimeringsproblem inte är den enda utvecklaren som regelbundet hanterar, det finns till exempel beslutsproblem och sökproblem, optimering är den uppgift som omfattar de olika stadierna av webbutveckling, troligen den mest.
Kodoptimering kan ske på olika nivåer, beroende på hur nära optimeringen vi utför är att maskinskoda. I webbutveckling kan vi bara utföra högre nivåoptimeringar, eftersom optimering av monterings- eller runtime-nivå inte är ett alternativ för oss, men vi har fortfarande många möjligheter.
Vi kan optimera vår kod på arkitektonisk nivå med smarta designmönster, på källkodsnivån genom att använda bästa kodningspraxis och använda lämpliga verktyg, och vi kan också förbättra prestanda för vårt team av introducerar kodningsstilguider i vårt arbetsflöde.
Oavsett vilken teknik vi väljer att gå med, finns det en tumregel att varje kodoptimering strävar efter att följa: vi måste alltid utföra optimeringen på ett sätt som inte ändrar betydelsen av koden.
Fördelarna med kodoptimering växer i linje med tillväxten av vårt projekt, och som även initialt små projekt kan bli stora med tiden, förvärv av solida kodoptimeringsfärdigheter har nästan alltid mätbara positiva resultat.
1. Cleaner Code Base
Som ett projekt mogas, och fler och fler utvecklare börjar arbeta med det, dubbletter och överlappar brukar förr eller senare dyka upp och plötsligt inser vi att vi knappast förstår vad som händer.
Det är inte ett slump att det är en av hörnstenarna i effektiv programutveckling att hålla DRY (Do not Repeat Yourself) principen i åtanke. En välsträckt, noggrant optimerad kodbas där vi kan återanvända samma element flera gånger är alltid snyggare och tidigare, och är därför mycket lättare att förstå och arbeta med.
2. Högre konsistens
Konsistens är som hushållsarbete, när det är ordentligt omhändertaget av ingen märker det, men när det försummas ser hela stället suddigt ut och vi befinner oss i kaos.
Att fullborda fullständig konsistens är svår, som Att säkerställa bakåtkompatibilitet kan så småningom komma i vägen för förbättring, men uppmärksamma Använda sammanhängande kodriktlinjer, kompatibla API och konsekventa standarder kan säkert minska smärtan.
Att hålla kodens konsistens i åtanke är särskilt viktigt när vi behöver hantera arvskoden, eller i fall av större projekt som involvera många utvecklare.
3. Snabbare webbplatser
Optimeringskoden liknar att köpa en snabbare bil. Som ett resultat, vår kod exekverar snabbare, och vår webbplats eller ansökan förbrukar mindre minne än tidigare. Även om optimeringsprocessen kan kräva ytterligare tid och pengar, resultatet är a bättre erfarenhet, inte bara för utvecklare utan också för slutanvändare.
Snabbare kod medför kortare sidladdningstider också, vilket är en stor sak i båda världarna av sökmotoroptimering och konverteringsmarknadsföring. Forskning säger det “nästan hälften av webbanvändarna förväntar sig att en webbplats laddas i 2 sekunder eller mindre, och de tenderar att överge en webbplats som inte laddas inom 3 sekunder”, så hastighet är helt klart inte ett område som vi säkert kan ignorera.
4. Bättre kodläsbarhet
Läsbarhet är en viktig aspekt av kodunderhållbarhet. Slarvig kod med ad hoc-formatering är svår att läsa, därför svår att förstå, särskilt för utvecklare som är nya för ett projekt.
Vi kan skydda oss från smärtan på att hantera oskärbar kod om vi tillämpar vissa kodoptimeringstekniker, till exempel:
- använda sammanhängande namngivningskonventioner med meningsfulla namn, såsom BEM
- konsekvent formatering med logiskt utnyttjande av indragning, blankutrymme och vertikalt avstånd
- undvika onödigt buller, som självförklarande, uppenbara kommentarer
Detta är anledningen till att stora projekt, som WordPress, jQuery och Mootools, har tydliga kodningsstilguider som varje involverad utvecklare behöver följa.
5. Effektivare Refactoring
Det förekommer ofta i webbutveckling att vi ärar kod från någon annan och förstår snabbt att det är långt ifrån att vara optimal, huruvida i termer av struktur, prestanda eller underhåll. Samma sak kan hända med våra egna tidigare projekt som vi skrev när vi hade mycket mindre erfarenhet av programmering.
I andra fall Målen för ett annat stort projektförändring över tiden, och vi behöver prioritera andra saker i ansökan än tidigare.
Vi pratar om refactoring när vi ändra (städa upp) befintlig kod för att optimera det utan att ändra någon av dess funktioner. Refactoring måste utföras med stor omtanke, som om det är gjort på fel sätt kan vi enkelt sluta med en kodbas som är ännu mindre optimal än originalet var.
Lyckligtvis har vi många välprövade tekniker på våra händer som kan göra refactoring en smidig körningsprocess.
6. Mer rättvist debugging
Felsökning tar upp en betydande del av webbutvecklingsarbetet, och det är oftast en tråkig eller till och med skrämmande uppgift. Det är svårt nog om vi måste felsöka vår egen kod, men det är det mycket värre när vi behöver hitta buggarna i någon annans, speciellt om det är något som aldrig spenderar spagetti kod som använder ingenting annat än funktioner.
Smart design och arkitektoniska mönster, som använda objekt och olika moduler, och tydliga kodningsriktlinjer kan underlätta felsökningsprocessen, även om det troligtvis fortfarande inte kommer att bli vår mest älskade uppgift.
7. Förbättrat arbetsflöde
Många webbutvecklingsprojekt drivs av distribuerade grupper, till exempel öppna källor eller fjärrlag. En av de svåraste sakerna att hantera ett sådant arbetsflöde är att hitta ett sätt som gör kommunikationen effektiv nog möjliggöra för medlemmarna att enkelt förstå varandra, och inte behöva ständigt diskutera standardinställningar.
Avtal om bästa praxis och stilguider kan överbrygga klyftan mellan människor från olika bakgrunder, för att inte tala om de vanliga kommunikationshinderna mellan design och utvecklingsteam i de flesta webbprojekt.
Kodoptimering är också arbetsflödesoptimering, som om lagmedlemmar talar ett gemensamt språk och delar samma förklarade mål, kommer de också att kunna arbeta tillsammans utan mycket mindre besvär.
8. Underlättar kodunderhåll
Även om man bygger något från grunden tenderar det att vara roligare än att behålla befintlig kod, ibland behöver vi fortfarande utföra löpande kodunderhåll. Att arbeta med redan befintliga system kan också ge oss nya synpunkter på kodoptimering, eftersom det är en annan upplevelse än tidiga optimeringar i ett nytt projekt.
Vid underhåll av programvara befinner vi oss redan på ett stadium där vi kan få verkliga prestanda och effektivitetsproblem och arbeta med riktiga användare istället för hypotetiska användningsfall.
Kodunderhåll får oftast liten respekt i utvecklarcirklar, men det kan fortfarande vara en givande uppgift om vi följer bästa praxis, till exempel genom att använda tillförlitlig versionskontroll, beredskapshantering, staging och testplattformar, och korrekt ta hand om dokumentation.
9. Snabbare funktionutveckling
Konstant innovation är kärnan i att vara relevant inom vårt område, som om vi inte har visat något nytt för våra användare på ett tag kan vi snabbt bli kvar. Att förlänga ett projekt och lägga till nya funktioner är vanligtvis mycket snabbare om vi arbetar med en väl optimerad, ren kodbas.
Förutom de redan diskuterade metoderna för optimering av koden, kan utvecklingen också få fart om vi håller med moderna projekthanteringsmetoder, till exempel om vi använder iterativa livscykelmodeller istället för den traditionella vattenfallsmodellen.
10. Mindre teknisk skuld
Begreppet "teknisk skuld" gjordes av Ward Cunningham, programmeraren som också utvecklade den första wikien. Det jämför konsekvenserna av våra dåliga programmeringsbeslut som ackumuleras med tiden för finansiell skuld där människor betalar intresse för framtiden för att snabbt få pengar i nuet.
Dessa mindre än optimala beslut manifesterar sig vanligtvis i form av snabba korrigeringar, kopiering och klistra in programmering, hårdkodning, lastkultprogrammering och andra kodande antipatterner och slarviga arbetsvanor.
Det är i grunden omöjligt att helt undvika teknisk skuld, eftersom även bra beslut kan vara mindre önskade konsekvenser i framtiden, men om vi noggrant optimerar vår kod kommer vi säkert att vara belastas med en mycket mindre teknisk skuld.
