Web-kehitys 10 välttämätöntä koodikoodia

Verkkosivuston tai sovelluksen arkkitehtuurin suunnitteleminen tai tehokkaan koodauksen työnkulun asettaminen usein vaikeuttavat toistuvia ongelmia. Emme välttämättä tarvitse ratkaista näitä ohjelmistosuunnitteluongelmia tyhjästä, kuten arkkitehtuurin ratkaisuja voidaan käyttää uudelleen samalla tavalla kuin koodinpätkät mikrotasolla.

Suunnittelumallit ovat yleensä uudelleenkäytettäviä ratkaisuja tietyistä skenaarioista kätevä ratkaista yleisesti esiintyviä ongelmia, ja voimme auttaa meitä optimoimaan koodimme.

Vaikka suunnittelumallit ovat hyviä keinoja kehittää kehitysprosessiamme käyttämällä hyvin testattuja kaavoja, joskus voimme myös mennä vikaan. Näitä kutsutaan antipatterneiksi.

Mitä ovat antipatternit?

Termi “antisuunnittelumalli” se on syntynyt AntiPatterns-kirjassa vuonna 1998. Se viittaa uudelleen käytettyjä ratkaisuja, jotka näyttävät aluksi hyödyllisiltä, mutta myöhemmin osoittautuu tehdä enemmän haittaa kuin hyötyä.

Tämä voi tapahtua erilaisista syistä, esimerkiksi jos emme käytä malleja oikeaan kontekstiin, asetukseen tai aikaan (aikaisemmin tehneet ratkaisut eivät aina toimi nykyisissä) tai muissa tapauksissa koko paradigma oli vain huono alusta alkaen.

Antipatterneja kutsutaan myös usein epäonnistumismallit. Hyvä uutinen on se, että se on voidaan tunnistaa ja välttää.

Tässä viestissä tarkastelemme 10 yleistä koodaustyyppiä web-kehityksessä, jotka saattavat pettää meidät ajattelemaan, että meillä on hyvin optimoitu koodi. (Huomaa, että tässä viestissä luetellut antipatternit eivät välttämättä ole samat kuin mitä edellä mainitussa kirjassa on.)

1. Ennenaikainen optimointi

Hyvä ajoitus on ratkaiseva tekijä koodin optimoinnissa. Voimme helposti jäljentää antipatternia “ennenaikaista optimointia”, jos kiinnitämme huomiota pieniin tehokkuusetuihin ja optimoimme niitä liian varhain kehitysprosessissa, ennen kuin tiedämme tarkalleen, mitä haluamme tehdä.

Donald Knuthin kuuluisan lainauksen mukaan “ennenaikainen optimointi on kaiken pahan perusta“, mikä voi olla liioittelua, mutta näyttää edelleen, kuinka vakavia ongelmia ennenaikainen optimointi voi myöhemmin aiheuttaa.

Jos optimoimme suorituskyvyn ennen tehokasta arkkitehtuuria, voimme alhaisempi koodin luettavuus, tehdä virheenkorjausta ja ylläpitoa, ja lisää tarpeettomia osia meidän koodiin.

Ennenaikaisen optimoinnin estämiseksi on hyvä noudattaa YAGNI-ohjelmointiperiaatetta, joka suosittelee “toteuttaa aina asioita, kun niitä todella tarvitset, koskaan, kun vain ennakoit, että tarvitset niitä.”

2. Ratkaise pyörä uudelleen

“Pyörän keksiminen uudelleen” antipatterniä kutsutaan joskus myös nimellä “suunnittelu tyhjiössä”. Se tapahtuu, kun haluamme tee kaikkea itseämme ja kirjoita kaikki tyhjästä, etsimättä jo olemassa olevia menetelmiä, sovellusliittymiä tai kirjastoja.

Pyörän keksiminen ei ole pelkästään aikaa vievä asia, vaan räätälöityjä ratkaisuja, varsinkin perusfunktioita varten, ovat harvoin yhtä hyviä kuin tavalliset joita monet kehittäjät ja käyttäjät ovat jo testanneet.

3. Riippuvuus Hell

Vastakohta “Pyörän keksiminen uudelleen” antipattern on toinen yleinen antipattern, jota kutsutaan “riippuvuuden helvetti”.

Jos sen sijaan, että kirjoittaisit kaiken tyhjästä, käytämme liian monet kolmannen osapuolen kirjastot, jotka tukevat muiden kirjastojen tiettyjä versioita, voimme helposti joutua tuskin hallittavaan tilanteeseen, kun haluamme päivittää, koska nämä toissijaiset riippuvuudet ovat monissa tapauksissa yhteensopimattomia.

Riippuvainen helvetti voidaan ratkaista käyttämällä pakettien hallintoja, jotka pystyvät päivitä toisistaan ​​riippuvaisia ​​riippuvuuksia. Jos ongelma ylittää liikaa, refactoring voi olla myös hyvä idea.

4. Spagetti-koodi

“Spagetti-koodi” on luultavasti tunnetuin koodaava antipattern. Se kuvaa sovellus, jota on vaikea korjata tai muokata asianmukaisen arkkitehtuurin puutteen vuoksi.

Huonon ohjelmistosuunnittelun tuloksena on joukko koodia, joka on rakenteeltaan samanlainen kuin spagetti-kulhoon, so. takkuinen ja kiertynyt. Spagettikoodin luettavuus on hyvin vähäistä, ja tavallisesti on lähes mahdotonta ymmärtää, miten se toimii.

Spagetti-koodi on yleensä peräisin eri huonojen koodauskäytäntöjen yhdistelmä, kuten koodi, joka ei sisällä asianmukaisia ​​ehtoja, joissa on paljon goto-lausuntoja, poikkeuksia ja säikeitä, jotka sisältävät osia, jotka kuuluvat johonkin muualle, on minimaaliset suhteet objektien välillä, sillä on toimintoja tai menetelmiä, joita ei voida käyttää uudelleen tai joita ei voida käyttää uudelleen tai joita ei dokumentoida oikein tai ollenkaan.

5. Ohjelmointi Permutationilla

“Ohjelmointi permutaation avulla” tai “ohjelmointi vahingossa” tapahtuu, kun yritämme löytää ratkaisun ongelmaan kokeilemalla peräkkäin pieniä muutoksia, testaamalla ja arvioimalla niitä yksi kerrallaan ja lopulta toteuttamalla sen, joka toimii ensin.

Permutaation avulla ohjelmointi on helppoa ota käyttöön uusia virheitä koodiin, vielä pahempaa, ne ovat vikoja, joita emme välttämättä tunnista heti. Monissa tapauksissa on myös mahdotonta ennakoida, toimiiko ratkaisu kaikkiin mahdollisiin skenaarioihin vai ei.

6. Kopioi ja liitä ohjelmointi

“Kopioi ja liitä ohjelmointi” tapahtuu, kun emme noudata Älä toista itseäsi (DRY) -koodausperiaatetta, ja lisäämme yleisiä ratkaisuja sen sijaan, että lisäämme jo olemassa olevat koodinpätkät eri paikkoihin ja myöhemmin muokkaamme ne sopiviksi kyseiseen kontekstiin.

Tämä käytäntö johtaa koodiin, joka on erittäin toistuva, koska lisätyt koodiosat poikkeavat yleensä vain pienistä eroista.

Ohjelmoinnin kopioiminen ja liittäminen ei ole pelkästään aloittelijoiden, vaan kokeneiden ohjelmoijien tekemiä, sillä monet heistä ovat altis käyttää omia ennalta kirjoitettuja, testattuja koodinpätkiä tiettyjä tehtäviä varten, joka voi helposti johtaa tahattomia toistoja.

7. Cargo-Cult-ohjelmointi

Nimi “rahtikulttuurin ohjelmointi” on peräisin tietystä etnografisesta ilmiöstä, jota kutsutaan “rahtikulttuuri”. Tavaroiden kultit ilmestyivät Tyynenmeren eteläosaan toisen maailmansodan jälkeen, kun pakko koskettaa kehittyneitä sivilisaatioita johtamaan alkuperäiskansoja luulemaan, että valmistetut tuotteet, kuten Coca-Cola, televisiot ja jääkaapit, jotka rahtialukset ovat saaneet saarille, luotiin yliluonnollisella menetelmät; ja jos he suorittavat maagisia rituaaleja, jotka ovat samanlaisia ​​kuin länsimaalaiset, tavarat täytetään jälleen.

Kun teemme rahtikulttuurisen ohjelmoinnin antipatternin, teemme periaatteessa saman. Käytämme kehyksiä, kirjastoja, ratkaisuja, suunnittelumalleja jne., Jotka toimivat hyvin muille, ymmärtämättä, miksi teemme niin, tai miten mainitut tekniikat toimivat oikein.

Monissa tapauksissa kehittäjät vain rituaalisesti tehdä mitä on lonkaa tuolloin ilman todellista tarkoitusta. Tämä käytäntö ei ole vain huono, koska se tekee hakemuksestamme ylimääräisen turvotuksen, mutta se voi myös helposti tuoda uusia virheitä koodiin.

8. Lava-virtaus

Puhumme siitä “laavavirta” antipattern, kun meidän täytyy käsittele koodia, jossa on tarpeettomia tai huonolaatuisia osia että näyttävät olevan olennaisia ohjelmaan, mutta emme täysin ymmärrä, mitä se tekee tai miten se vaikuttaa koko sovellukseen. Tämä tekee sen poistamisesta riskialtista.

Se tapahtuu yleensä vanhan koodin, tai kun koodi on kirjoittanut joku muu (yleensä ilman asianmukaista dokumentaatiota) tai kun projekti siirtyi liian nopeasti kehityksestä tuotantovaiheeseen.

Antipatternin nimi tulee sen orjuudesta tulivuorista tulevaan laavaan, eli se liikkuu aluksi nopeasti ja sujuvasti ottamatta liian monta varovaisuutta, mutta myöhemmin se jähmettyy ja vaikeutuu poistettavaksi.

Teoriassa voimme päästä eroon laavavirroista kattava testaus ja refactoring, mutta käytännössä, täytäntöönpano on usein vaikeaa tai jopa mahdotonta. Koska laavavirroilla on yleensä korkeat suorituskyvyn kustannukset, on parempi estää niitä asettamalla hyvin suunniteltu arkkitehtuuri ja äänen työnkulku alusta alkaen.

9. Kova koodaus

“Kova koodaus” on tunnettu antipattern, jota vastaan ​​useimmat web-kehityskirjat varoittavat meitä etukäteen. Kova koodaus on valitettava käytäntö tallennamme kokoonpano- tai syöttötiedot, kuten tiedoston polku tai etäisäntänimi, lähdekoodissa sen sijaan, että hankit sen kokoonpanotiedostosta, tietokannasta, käyttäjän syötteestä tai muusta ulkoisesta lähteestä.

Tärkein ongelma kovalla koodilla on se se toimii vain tietyssä ympäristössä, ja at milloin tahansa olosuhteet muuttuvat, meidän on muutettava lähdekoodi, yleensä useissa eri paikoissa.

10. Pehmeä koodaus

Jos yritämme kovasti välttää kovan koodauksen ahdistuksen, voimme helposti joutua toiseen antipatterniin, jota kutsutaan “pehmeä koodaus”, mikä on sen päinvastainen.

Pehmeässä koodauksessa, asetamme lähdekoodissa olevat asiat ulkoisiin lähteisiin, esimerkiksi säilytämme liiketoimintalogiikan tietokantaan. Yleisin syy siihen, miksi teemme niin, on pelko siitä, että liiketoimintasäännöt muuttuvat tulevaisuudessa, joten meidän on kirjoitettava koodi uudelleen.

Äärimmäisissä tapauksissa pehmeä koodattu ohjelma voi tullut niin abstraktiksi ja mutkikkaaksi, että sitä on lähes mahdotonta ymmärtää (erityisesti uusien tiimien jäsenille) ja erittäin vaikea ylläpitää ja korjata.