10 syytä, miksi tarvitset koodin optimoinnin
Kun kirjoitamme koodia, teemme jatkuvasti päätöksiä ja valitsemme ratkaisuja, jotka saattavat tuntua vastaavilta. Myöhemmin se yleensä osoittautuu jotkut valinnat johtavat tehokkaampaan ohjelmaan kuin toiset, niin, että parhaiden koodauskäytäntöjen ja optimointitekniikoiden etsintä syntyy luonnollisesti, ja alamme nähdä koko kehitysprosessi ratkaistavaksi optimointiongelmaksi.
Vaikka optimointiongelmat eivät ole ainoat, kehittäjät käsittelevät säännöllisesti esimerkiksi päätöksentekoon liittyviä ongelmia ja etsintäongelmia, optimointi on tehtävä, joka käsittää web-kehityksen eri vaiheet todennäköisesti eniten.
Koodin optimointi voi tapahtua eri tasoilla, riippuen siitä, kuinka lähellä suoritettava optimointi on konekoodia. Web-kehityksessä voimme tehdä vain korkeamman tason optimointeja, kuten kokoonpano- tai runtime-tason optimoinnit eivät ole meille vaihtoehto, mutta meillä on vielä monia mahdollisuuksia.
Voimme optimoida koodimme arkkitehtuurilla älykäs muotoilu, lähdekoodin tasolla käyttämällä parhaita koodaustapoja ja käyttämällä sopivia työkaluja, ja voimme myös parantaa tiimimme suorituskykyä koodaustyylioppaiden käyttöönotto työnkulkuun.
Riippumatta siitä, mihin tekniikkaan haluamme mennä, on nyrkkisääntö, että jokaisen koodin optimointipyrkimyksen on noudatettava: meidän täytyy aina olla suorita optimointi tavalla, joka ei muuta koodin merkitystä.
Koodin optimoinnin edut kasvavat projektimme kasvun mukaisesti ja niin jopa alun perin pienet hankkeet voivat tulla suuriksi ajan myötä, kiinteän koodin optimointitaitojen hankkimisella on lähes aina mitattavissa olevia positiivisia tuloksia.
1. Puhtaan koodin pohja
Koska projekti kypsyy, ja yhä useammat kehittäjät alkavat työskennellä sen parissa, päällekkäisyyksiä ja päällekkäisyyksiä esiintyy yleensä aikaisemmin tai myöhemmin, ja yhtäkkiä ymmärrämme, että tuskin ymmärrämme, mitä tapahtuu.
Ei ole sattumaa, että DRY (Don't Repeat Yours) -periaatteen pitäminen mielessä on yksi tehokkaan ohjelmistokehityksen kulmakivistä. Hyvin rakennettu, huolellisesti optimoitu koodipohja, johon voimme käyttää samoja elementtejä useita kertoja on aina tyylikäs ja tidier, ja siksi on paljon helpompi ymmärtää ja työskennellä.
2. Korkeampi johdonmukaisuus
Johdonmukaisuus on kuin kotityöt, kun se on kunnolla hoidettu, eikä kukaan huomaa sitä, mutta kun se on laiminlyöty, koko paikka näyttää sotkuiselta, ja löydämme kaaoksen.
Täydellisen johdonmukaisuuden saavuttaminen on vaikeaa taaksepäin yhteensopivuuden varmistaminen voi lopulta saada parannusta, mutta kiinnitetään huomiota käyttämällä johdonmukaisia koodia koskevia ohjeita, yhteensopivia sovellusliittymiä ja yhdenmukaisia standardeja voi varmasti vähentää kipua.
Koodin yhtenäisyyden pitäminen mielessä on erityisen tärkeää kun meidän on käsiteltävä vanhaa koodia, tai suurempien hankkeiden tapauksessa mukana monet kehittäjät.
3. Nopeammat sivustot
Koodin optimointi on samanlainen kuin nopeamman auton ostaminen. Tämän seurauksena meidän koodi suorittaa nopeammin, ja sivustomme tai sovelluksemme kuluttaa vähemmän muistia kuin ennen. Vaikka optimointiprosessi saattaa vaatia lisää aikaa ja rahaa, tulos on a parempi kokemus, ei vain kehittäjille vaan myös loppukäyttäjille.
Nopeampi koodi edellyttää lyhyemmät latausajat samoin, mikä on iso juttu sekä hakukoneoptimoinnin että muuntomarkkinoinnin maailmoissa. Tutkimus sanoo “lähes puolet web-käyttäjistä odottaa, että sivusto latautuu 2 sekunnissa tai vähemmän, ja he luopuvat sivustosta, jota ei ladata 3 sekunnin kuluessa”, Niinpä nopeus ei selvästikään ole alue, jota emme voi turvallisesti jättää huomiotta.
4. Parempi koodin luettavuus
Luettavuus on tärkeä osa koodin ylläpidettävyyttä. Epäsäännöllinen koodi, jossa on ad hoc -muotoilu, on vaikea lukea, joten sitä on vaikea ymmärtää, etenkin sellaisille kehittäjille, jotka ovat uusia projektiin.
Voimme suojella itseämme kipu käsitellä epäselvää koodia jos käytämme tiettyjä koodin optimointitekniikoita, kuten:
- käyttämällä johdonmukaisia nimityskäytäntöjä, joilla on merkityksellisiä nimiä, kuten BEM
- johdonmukainen muotoilu, jossa käytetään loogista hyödyntämistä, välilyöntiä ja pystysuora väliä
- tarpeettoman melun välttäminen, kuten itsestään selviävät ja ilmeiset huomautukset
Tästä syystä suurissa projekteissa, kuten WordPressissa, jQueryssä ja Mootoolsissa, on selkeät koodaustyypin oppaat. Jokaisen mukana olevan kehittäjän on noudatettava.
5. Tehokkaampi refaktorointi
Web-kehityksessä tapahtuu usein, että perimme koodin jollekulta toiselta, ja ymmärrämme nopeasti, että se on kaukana optimaalisesta, riippumatta siitä rakenne, suorituskyky tai ylläpito. Sama voi tapahtua myös omien aiempien hankkeiden kanssa, joita kirjoitimme, kun meillä oli paljon vähemmän kokemusta ohjelmoinnista.
Muissa tapauksissa muuten suuren hankkeen tavoitteet muuttuvat ajan myötä, ja meidän täytyy priorisoida muut asiat sovelluksessa kuin ennen.
Puhumme refaktoroinnista, kun me muuttaa (puhdistaa) olemassa olevaa koodia sen optimoimiseksi muuttamatta mitään sen toimintoja. Refaktorointi on tehtävä erittäin huolellisesti, ikään kuin se tehtäisiin väärällä tavalla, voimme helposti päätyä sellaiseen koodipohjaan, joka on vielä vähemmän optimaalinen kuin alkuperäinen..
Onneksi meillä on monia hyvin testattuja tekniikoita, jotka voivat tehdä sujuvasta prosessista refactoringin.
6. Selkeämpi virheenkorjaus
Vianmääritys vie merkittävän osan web-kehitysprosessista, ja se on tavallisesti ikävä tai jopa pelottava tehtävä. On tarpeeksi vaikeaa, jos meidän täytyy debugoida oma koodi, mutta se on paljon huonompi, kun meidän täytyy löytää vikoja jonkun toisen kanssa, varsinkin jos se on jotain sellaista, joka ei ole loputon spagetti-koodi, joka käyttää vain toimintoja.
Älykäs muotoilu ja arkkitehtonisia malleja, kuten käyttämällä kohteita ja eri moduuleja, ja selkeät koodausohjeet voi helpottaa virheenkorjausprosessia, vaikka todennäköisimmin se ei vieläkään ole rakkain tehtävä.
7. Parempi työnkulku
Monia web-kehityshankkeita hoitavat hajautetut tiimit, kuten avoimen lähdekoodin yhteisöt tai etäryhmät. Yksi vaikeimmista asioista tällaisen työnkulun hallinnassa on löytää tapa, jolla viestintä on tarpeeksi tehokas jotta ryhmän jäsenet voivat helposti ymmärtää toisiaan, ja ei tarvitse jatkuvasti keskustella oletusarvoista.
Parhaista käytännöistä ja tyylisuuntaajista sovittujen yhteyksien avulla voidaan ylittää eri taustoista tulevien ihmisten välinen kuilu, puhumattakaan tavallisista suunnittelu- ja kehitystyöryhmien välisistä viestintäongelmista useimmissa verkkoprojekteissa.
Koodin optimointi on myös työnkulun optimointi, kuin jos tiimin jäsenet puhuvat yhteistä kieltä ja jakavat samat julistetut tavoitteet, he voivat myös työskennellä yhdessä ilman paljon vähemmän vaivaa.
8. Helpompi Koodihuolto
Vaikka jotain rakentamista maasta ylöspäin on yleensä hauskempaa kuin olemassa olevan koodin ylläpito, on joskus vielä suoritettava käynnissä oleva koodin ylläpito. Työskentely jo olemassa olevien järjestelmien kanssa voi myös antaa meille uusia näkymiä koodin optimoinnista, koska se on erilainen kokemus kuin aikaisessa optimoinnissa uudessa projektissa.
Ohjelmistojen ylläpidossa olemme jo vaiheessa, jossa voimme tarttua todellisiin suorituskyky- ja tehokkuusongelmiin ja työskennellä todellisten käyttäjien kanssa hypoteettisten käyttötapojen sijasta.
Koodihuolto saa yleensä vähäistä kunnioitusta kehittäjien piireihin, mutta se voi silti olla palkitsevaa tehtävää, jos noudatamme parhaita käytäntöjä, kuten käyttämällä luotettavat versionhallinta, riippuvuuden hallinta, lavastus- ja testausalustat, ja oikein huolehdi asiakirjoista.
9. Nopeampi ominaisuuden kehittäminen
Jatkuva innovaatio on keskeinen asia, kun pysyt alalla tärkeänä, kuten jos emme ole näyttäneet käyttäjillemme mitään uutta jonkin aikaa, mutta voimme nopeasti jäädä pois. Projektin laajentaminen ja uusien ominaisuuksien lisääminen siihen on yleensä paljon nopeampaa, jos työskentelemme hyvin optimoidulla ja puhtaalla koodikannalla.
Jo käsiteltyjen koodin optimointimenetelmien lisäksi ominaisuuden kehittäminen voi myös vauhtia, jos pysymme mukana nykyaikaiset projektinhallintamenetelmät, esimerkiksi jos käytämme iteratiivisia elinkaarimalleja perinteisen vesiputousmallin sijasta.
10. Pienempi tekninen velka
Termi "tekninen velka" syntyi Ward Cunningham, ohjelmoija, joka kehitti myös ensimmäisen wikin. Siinä verrataan huonojen ohjelmointipäätösten seurauksia, jotka kertyvät ajan mittaan rahoitusvelkaan, jossa ihmiset maksavat korkoa tulevaisuudessa, jotta he voivat nopeasti saada rahaa nykyiseen.
Nämä vähemmän optimaaliset päätökset ilmenevät yleensä pikakorjauksina, kopioimalla ja liittämällä ohjelmointiin, kovaan koodaukseen, lastikulttuuriseen ohjelmointiin ja muihin koodaavat antipatternit ja huolimattomia työtapoja.
Se on pohjimmiltaan mahdotonta välttää täysin teknistä velkaa, koska myös hyvät päätökset voivat olla vähemmän toivottuja seurauksia tulevaisuudessa, mutta jos optimaalisesti optimoimme koodimme, olemme varmasti pienempi tekninen velka.
