10 põhjust, miks te vajate koodi optimeerimist
Kuigi me kirjutame koodi, teeme pidevalt otsuseid ja valime lahenduste vahel, mis kõigepealt võivad tunduda samaväärsed. Hiljem selgub tavaliselt, et mõned valikud toovad kaasa tõhusama programmi kui teised, nii tekib loomulikult parim kodeerimispraktika ja optimeerimismeetodite otsing ning me hakkame vaadake kogu arendusprotsessi kui optimeerimisprobleemi lahendamiseks.
Kuigi optimeerimisprobleemid ei ole ainsad, tegelevad regulaarselt arendajad, näiteks on probleeme otsuste tegemisega ja probleemide otsimisega, optimeerimine on ülesanne, mis hõlmab veebiarenduse erinevaid etappe kõige tõenäolisemalt.
Koodide optimeerimine võib toimuda erinevatel tasanditel, sõltuvalt sellest, kui lähedal on meie teostatav optimeerimine masina koodile. Veebiarenduses saame teha ainult kõrgema taseme optimeeringuid, kui assamblee või käitusaja taseme optimeerimine ei ole meile valikuvõimalus, kuid meil on veel palju võimalusi.
Me saame oma koodi optimeerida arhitektuurilisel tasandil arukad disainimustrid, lähtekoodi tasemel, kasutades parimaid kodeerimispraktikaid ja kasutades sobivaid vahendeid, ning saame ka parandada meie meeskonna tööd kodeerimise stiili juhendite tutvustamine meie töövoogu.
Sõltumata sellest, millist tehnikat me tahame koos minna, on olemas rusikareegel, et iga koodi optimeerimise püüdlus peab järgima: me peame alati olema teostage optimeerimine viisil, mis ei muuda koodi tähendust.
Koodi optimeerimise eelised kasvavad kooskõlas meie projekti kasvuga ja nii isegi algselt võivad väikesed projektid aja jooksul suureks muutuda, tahkete koodide optimeerimise oskuste omandamisel on peaaegu alati mõõdetavad positiivsed tulemused.
1. Cleaner Code Base
Projekti valmimisel ja üha enam arendajaid hakkab sellega töötama, kattuvad ja kattuvad tavaliselt varem või hiljem, ja äkki mõistame, et me vaevalt aru saame, mis toimub.
See ei ole juhus, et DRY (Don't Repeat Yourself) põhimõtte pidamine on tõhusa tarkvara arendamise üks nurgakive. Hästi arenenud, hoolikalt optimeeritud koodibaas, milles me suudame korduvalt kasutada samu elemente mitu korda on alati sile ja tidier, ja seetõttu on palju lihtsam mõista ja töötada.
2. Kõrgem järjepidevus
Järjepidevus on nagu majapidamistööd, kui seda hoolikalt ei hoolitse keegi, kuid kui see on tähelepanuta jäetud, tundub kogu koht räpane ja me oleme kaos.
Täieliku järjepidevuse saavutamine on raske tagantjärele ühilduvuse tagamine võib lõpuks parandada, kuid pöörates tähelepanu kasutades ühtset koodi suuniseid, ühilduvaid API-sid ja ühtseid standardeid võib kindlasti valu vähendada.
Koodi järjepidevuse pidamine on eriti oluline kui me peame tegelema pärandkoodiga, suuremate projektide puhul kaasata paljud arendajad.
3. Kiiremad saidid
Koodi optimeerimine sarnaneb kiirema auto ostmisega. Selle tulemusena meie kood täidab kiiremini, ja meie veebisait või rakendus tarbib vähem mälu kui enne. Kuigi optimeerimise protsess võib nõuda lisaaega ja raha, tulemus on a parem kogemus, mitte ainult arendajatele, vaid ka lõppkasutajatele.
See tähendab kiiremat koodi lühem lehekülje laadimise aeg samuti, mis on suur asi nii otsingumootori optimeerimise kui ka konversiooniturunduse mõlemas maailmas. Teadus ütleb seda “ligi pooled veebikasutajatest eeldavad, et sait laaditakse 2 sekundi jooksul või vähem, ning nad kalduvad loobuma saidist, mida ei laadita 3 sekundi jooksul”, nii et kiirus ei ole ilmselgelt valdkond, mida me saame ohutult ignoreerida.
4. Parem koodi loetavus
Loetavus on koodide hooldamise oluline aspekt. Ad hoc vormindusega korrektne kood on raske lugeda, mistõttu on seda raske mõista, eriti arendajatele, kes on projekti jaoks uued.
Me saame end kaitsta vale tegeleda ebaselge koodiga kui rakendame teatud koodi optimeerimise tehnikaid, näiteks:
- kasutades ühtset nimetamiskonventsiooni sisuliste nimedega, näiteks BEM
- järjekindel vormindamine, milles kasutatakse loogilist kasutamist, tühikut ja vertikaalset vahekaugust
- tarbetu müra vältimine, nagu näiteks seletavad selgitused
See on põhjus, miks suurtel projektidel, nagu WordPress, jQuery ja Mootools, on selged kodeerimisstiilid, mida iga arendaja peab järgima.
5. Tõhusam refaktoriseerimine
Veebiarenduses esineb sageli seda, et me pärime koodi kelleltki teiselt ja mõistame kiiresti, et see on kaugeltki optimaalne, kas nii struktuur, jõudlus või hooldatavus. Sama võib juhtuda ka meie endiste projektidega, mida me kirjutasime, kui meil oli programmeerimisel palju vähem kogemusi.
Muudel juhtudel muidu suure projekti eesmärgid aja jooksul muutuvad, ja me peame prioriteediks teised rakenduse asjad kui enne.
Me räägime refaktoriseerimisest, kui me muutke (puhastage) olemasolevat koodi selle optimeerimiseks, muutmata selle funktsioone. Refaktoreerimine peab toimuma väga ettevaatlikult, nagu oleks see valesti tehtud, kuid me saame hõlpsasti lõpetada koodi baasi, mis on isegi vähem optimaalne kui originaal oli.
Õnneks on meil käes palju hästi testitud tehnikaid, mis võimaldavad tõrgeteta toimimise protsessi ümber kujundada.
6. Lihtsam silumine
Silumine võtab olulise osa veebiarenduse töövoogust ja see on tavaliselt tüütu või isegi hirmuäratav ülesanne. See on küllalt raske, kui me peame oma koodi debugima, aga see on palju hullem, kui me peame leidma vigu kellegi teise juures, eriti kui see on midagi sellist, mis on lõputu spagetikood, mis kasutab ainult funktsioone.
Nutikas disain ja arhitektuurilised mustrid, nagu näiteks objektide kasutamine ja erinevaid mooduleid, ja selged kodeerimisjuhised võib hõlbustada silumisprotsessi, isegi kui see tõenäoliselt ei ole meie kõige armsam ülesanne.
7. Parem töövoog
Paljusid veebiarendusprojekte juhivad hajutatud meeskonnad, näiteks avatud lähtekoodiga kogukonnad või kaugrühmad. Sellise töövoo juhtimise üks raskemaid asju on leida viis, mis muudab suhtluse piisavalt tõhusaks võimaldada meeskonnaliikmetel üksteist kergesti mõista, ja ei pea pidevalt arutama vaikimisi.
Parimate tavade ja stiilijuhiste osas on kokku lepitud, et ületada lõhe erinevate taustaga inimeste vahel, rääkimata tavapärastest kommunikatsiooniprobleemidest disaini- ja arendusmeeskondade vahel enamikus veebiprojektides.
Koodi optimeerimine on ka töövoo optimeerimine, kui meeskonnaliikmed räägiksid ühist keelt ja jagavad samu deklareeritud eesmärke, saavad nad ka koos töötada ilma palju vähem vaeva.
8. Lihtsam koodide hooldus
Kuigi maapinnast üles ehitamine on tavaliselt lõbusam kui olemasoleva koodi säilitamine, on mõnikord veel vaja käimasolevat koodide hooldust. Töötamine juba olemasolevate süsteemidega võib anda meile ka uusi seisukohti koodide optimeerimise kohta, sest see on erinev kogemus kui varajane optimeerimine uues projektis.
Tarkvara hooldamisel oleme juba selles staadiumis, kus saame püüda tegelikke tulemuslikkuse ja tõhususe probleeme ning töötada reaalsete kasutajatega hüpoteetiliste kasutusjuhtude asemel..
Koodide hooldamine muutub arendajate ringkondades tavaliselt vähe, kuid see võib siiski olla rahuldav ülesanne, kui järgime parimaid tavasid, näiteks kasutades usaldusväärsed versioonikontrollid, sõltuvuse haldamine, peatamis- ja testimisplatvormid, ja korralikult hoolitseda dokumentide eest.
9. Kiirem funktsioonide arendamine
Pidev innovatsioon on meie valdkonnas olulise tähtsusega tuum, nagu näiteks siis, kui me pole mõnda aega kasutajatele midagi uut näidanud, et saaksime kiiresti maha jääda. Projekti laiendamine ja uute funktsioonide lisamine sellele on tavaliselt palju kiirem, kui me töötame hästi optimeeritud ja puhta koodi baasiga.
Lisaks juba arutatud koodide optimeerimismeetoditele võib ka funktsioonide arendamine hoogustada, kui me sammu pidada kaasaegsed projektijuhtimise meetodid, näiteks kui kasutame traditsioonilise juga mudeli asemel iteratiivseid elutsükli mudeleid.
10. Väiksem tehniline võlg
Mõiste "tehniline võlg" on loodud Ward Cunningham, programmeerija, kes töötas välja ka esimese wiki. See võrdleb meie halbade programmitöö otsuste tagajärgi, mis aja jooksul kogunevad finantsvõlale, milles inimesed maksavad tulevikus intressi, et kiiresti raha saada..
Need vähem optimaalsed otsused avalduvad tavaliselt kiirparanduste, kopeerimise ja kleepimise, programmeerimise, kodeerimise, lasti-kultuuri programmeerimise ja muu kujul. kodeerivad antipatternid ja lohakas tööharjumused.
See on põhimõtteliselt võimatu täielikult vältida tehnilist võlga, kuna isegi head otsused võivad tulevikus olla vähem soovitud tagajärjed, aga kui me oma koodi hoolikalt optimeerime, siis kindlasti oleme palju väiksem tehniline võlg.
