Miksi vaivautua automaattiseen lataukseen WordPressissä, osa 1
Yksi helpoimmista asioista, jonka voimme tehdä työskennellessämme WordPress-laajennusten parissa, on hylätä request_once- tai include_once- lausekkeet koko koodiimme.
Ja miksi ei? Se on helppo tapa tuoda kaikki tarvittavat tiedostot tai riippuvuudet tietylle luokalle, saada se helposti luettavaksi, eikä sinun tarvitse huolehtia valtavien kooditiedostojen luomisesta. Tämä tarkoittaa, että se auttaa meitä yksinkertaistamaan kirjoittamaamme, jotta voimme saada luokkamme [useimmiten tai mieluiten] tekemään sen, mitä he tekevät hyvin.
Jos olet kuitenkin lukenut tätä sivustoa viimeisen vuoden ajan, tiedät, että olen automaattilatauksen fani, ja mielestäni jokaisen PHP:n kanssa työskentelevän pitäisi – riippumatta siitä, käytätkö WordPressiä vai jotakin muuta alustaa. käyttää.
Mutta se herättää kaksi kysymystä, varsinkin jos olet vasta aloittamassa:
- Miksi vaivautua automaattiseen lataamiseen, kun on muita tapoja käsitellä latausriippuvuuksia?
- Miten automaattinen lataus vastaa käännettyjä kieliä?
Joten ajattelin, että tähän kannattaa vastata parissa seuraavassa postauksessa.
Miksi vaivautua automaattiseen lataamiseen?
Lyhyesti on tämä:
- request_once ja include_once voivat johtaa koodiin, jota on vaikea korjata,
- koodia on vaikea jäljittää.
Mutta kuinka niin?
1 Vianetsintä on vaikeaa
Koodia kirjoitettaessa jos jokin on varmaa, se on, että jokin ei toimi toivotulla tavalla. Se kuuluu toimintaamme, eikö niin?
Joten mitä tulee virheenkorjauskoodiin, meillä kaikilla on strategiamme.
- jotkut meistä valitsevat echo- tai var_dump -koodin jäljittämiseen,
- käytä WordPressin laajennusta,
- toiset käyttävät debuggeria.
Vaikka tämä viesti ei käsittele virheenkorjausta, meidän on tehtävä virheenkorjaus. Joten jos tiedämme, että meidän on tehtävä se, eikö meidän pitäisi tehdä siitä mahdollisimman helppoa itsellemme?
PHP on dynaamisesti kirjoitettu kieli, joten meillä on yleensä paljon asioita, joista huolehditaan aina kun kirjoitamme koodia. Toisin sanoen tietyt asiat päätellään tai pakotetaan aina, kun koodia ajetaan.
Oletetaan esimerkiksi, että työskentelet merkkijonon kanssa ja vertaat sitä numeroon. Tulkki tekee kaikkensa arvatakseen, mitä olet tekemässä (haluatko jäsentää merkkijonon kokonaisluvuksi vai päinvastoin?) ja sitten työstää sitä.
Pelkästään muuttujien kanssa työskentely voi olla tarkkuuden harjoittelua, koska haluamme koodimme lukevan haluamallamme tavalla. Miksi jättää tulkin tehtäväksi arvata, mitä tarkoitamme? Ja jos tulkin on tehtävä ylimääräistä työtä, ihmiset varmasti tekevät.
Tätä varten, jos tiedämme, että bugeja tuodaan, ja tiedämme, että on olemassa tapoja kirjoittaa puhtaampaa koodia, miksi emme tekisi sitä?
2 Jäljitys on vaikeaa (tai ehkä vaikeampaa?)
Mutta tämä ei silti anna syytä sille, miksi meidän pitäisi luottaa johonkin, kuten automaattiseen latausohjelmaan, verrattuna kielen sisäänrakennettuihin palveluihin, eikö niin?
Harkitse tätä: Oletetaan, että etsit tiedostoa, joka yrittää löytää virheen ja törmäät funktioon, jossa on jokin koodi, joka käyttää include_once -koodia ja sitten jotain muuta koodia.
Tämä tarkoittaa, että sinun täytyy lukea koodi, pitää tämä henkisesti arkistoituna, hypätä toiseen tiedostoon, ymmärtää tämä koodi ja palata sitten alkuperäiseen tiedostoon. Ja tämä olettaa, että toinen tiedosto ei myöskään sisällä tai vaadi muita tiedostoja.
Sitä kutsutaan syystä spagettikoodiksi.
Näin ollen voit nähdä tämän aiheuttaman ahdingon, kun päätät sisällyttää tämän koodin koko ohjelmaan. Lyhyesti sanottuna, olet sisällyttänyt riippuvuuksiin, mikä vaikeuttaa luonnostaan seuraamista, missä jokin saattaa olla vialla.
Tämä ei tarkoita, että automaattinen lataus korjaa tämän automaattisesti, mutta se tarkoittaa, että sen ei tarvitse olla näin. Sen sijaan voit kirjoittaa koodia, joka instantoi luokkia, kutsuu menetelmiä ja suorittaa sitten koodin ilman, että sinun tarvitsee sisällyttää mitään manuaalisesti.
Luettavampi, jäljitettävä koodi
Näin tehdessäni huomaan, että se pakottaa meidät kirjoittamaan puhtaampaa koodia, luultavasti paremmin ylläpidettävää koodia. Se helpottaa myös koodin kirjoittamista, jonka jäljitys on helpompaa, ja sitä on helpompi hyödyntää debuggerilla.
Toisin sanoen voimme asettaa keskeytyspisteitä tiettyihin kohtiin koodissamme, saada debuggerin automaattisesti viemään meidät kutsuttavaan luokkaan ja astua takaisin toimintoon, joka kutsui sitä.
Tämä ei tarkoita, etteikö sitä voisi tehdä millään muulla tavalla, mutta hyödyt ovat paljon suuremmat kuin vaihtoehdot. Ja tietysti tämä jättää edelleen kysymyksen siitä, miksi automaattista latausta (tai kolmannen osapuolen tiedostojen sisällyttämistä) ylipäätään tarvitaan.
Mutta sitä käsitellään sarjan toisessa osassa.
Muuta lukemista
Viestini nimitiloista ja automaattisesta latauksesta WordPressissä sekä WordPressin Simple Autoloader -sovelluksesta ovat kaksi muuta resurssia, jotka liittyvät selvästi tähän viestiin. Joten jos sinulla on aikaa, tarkista ne (ja älä epäröi avata ongelmaa tai vetopyyntöä yksinkertaisessa automaattilatausprojektissa).