Paremman WordPress-koodin kirjoittaminen: PHPStan
Tämän sarjan viimeisimmässä viestissä (joka on tosin jonkin aikaa sitten), puhuin pitkään Composerista ja sen lukkotiedostosta.
Suosittelen lukemaan kaksi edellistä artikkelia, koska Composer tulee lopulta näyttelemään roolia tässä materiaalissa, jota tämä ja tulevat viestit jakavat. Mutta jos et halua seurata niitä (tai olet jo perehtynyt Composeriin), aiempien viestien ydin on vastaavasti seuraava:
En suosittele toimittajahakemiston tarkistamista arkistoon. Siitä voi myöhemmin tulla valtava hakemisto, ja se voi heikentää Composerin koko tarkoitusta.
Tavoitteena on varmistaa, että jokaisella on käytössä sama versio projektin riippuvuuksista – ei vanhempia tai uudempia versioita – mutta sama versio.
Tästä huolimatta voimme asentaa lukuisia riippuvuuksia tai paketteja, jotka auttavat meitä varmistamaan, että kirjoitamme mahdollisimman korkealaatuista koodia.
Toki jotkut näistä voivat olla koodausstandardien kaltaisia, mutta ne ovat todellakin enemmän sääntöjä kuin elementtejä korkealaatuisen koodin kirjoittamiseen (vaikka niitä ei mielestäni pitäisi jättää keskustelun ulkopuolelle – vain jättää pois tähän aikaan 🙃).
Takaisin kyseisiin työkaluihin: Mitkä työkalut auttavat kirjoittamaan korkealaatuista WordPress-koodia? Aion jakaa muutaman suosikkini, ja aion puhua niistä siitä, kuinka voimme käyttää niitä kaikkia koodipohjaa vastaan.
Katsotaanpa ensin staattista analyysiä PHPStanilla.
Parempi WordPress-koodi PHPStanilla
Mitä staattinen analyysi muuten on?
Ensinnäkin muutama sana staattisesta analyysistä. Nimittäin mikä se on? Se on suupala ensinnäkin:
Staattinen koodianalyysi (tunnetaan myös nimellä lähdekoodianalyysi) suoritetaan yleensä osana koodin tarkistusta (tunnetaan myös nimellä white-box -testaus) ja se suoritetaan Security Development Lifecyclen (SDL) käyttöönottovaiheessa.
Staattinen koodianalyysi viittaa tavallisesti staattisen koodin analyysityökalujen käyttöön, jotka yrittävät tuoda esiin mahdollisia haavoittuvuuksia "staattisessa" (ei-suorituskykyisessä) lähdekoodissa käyttämällä tekniikoita, kuten Taint Analysis ja Data Flow Analysis.
Ajattele asiaa näin: Se on tapa analysoida ohjelma mahdollisten virheiden varalta, joita et ehkä näe, kun työskentelet koodipohjan parissa.
Toisin sanoen on olemassa ongelmia, bugeja, tietoturvaongelmia, joita voi esiintyä, mutta et voi havaita useista syistä (joista vähin on, että olet liian lähellä koodia).
Ajan mittaan kehitysyhteisö on kuitenkin oppinut tapoja analysoida koodia, luoda sääntöjoukkoja ja rakentaa työkaluja, jotka auttavat löytämään täsmälleen kaikki edellä mainitut.
WordPress-keskeisen koodin staattinen analyysi
Ja tässä PHPStan tulee peliin.
Kuten mainittiin, paketin tavoitteena on tunnistaa koodissasi olevat virheet ennen kuin joku muu kuin kehittäjät käyttävät koodiasi, korostaa niitä ja antaa sinulle mahdollisuus korjata ne.
Koska tämänkaltaiset työkalut tutkivat koodipohjaa (verrattuna koodin suorittamiseen), ei aina ole mahdollista saada selkeää kuvaa. Tämä tarkoittaa, että voimme saada vääriä positiivisia tuloksia.
Tästä kuitenkin lisää hetken kuluttua.
Jos olet kiinnostunut aloittamaan PHPStanin käyttämisen koodipohjaasi vastaan, se on helppoa. Asennuksen jälkeen muista vain määrittää se niin, että se ei näy vendorhakemistossa tai vaikkapa WordPress-ytimessä.
Sen sijaan pyydä sitä tutkimaan koodisi.
PHPStanin asennus
Lisää ensin composer.jsontiedostosi osioon seuraava rivi require-dev:
"phpstan/phpstan": "^0.11.12"
Suorita composer updatesitten terminaalissasi.
Kun se on asennettu, voit käyttää sitä yksittäistä tiedostoa, hakemistoa tai hakemistojoukkoa vastaan. Jos olet lukenut aiemmat kirjoitukseni koodin organisoinnista, tiedät, että pidän suurimman osan projektin lähdekoodista srcmukanasi, saatat ajaa jotain tällaista:
$ vendor/bin/phpstan analyse src
Tämä tuottaa tulosteen sen perusteella, mitä apuohjelma löytää.
Muistatko aiemmin, kun sanoin, että se voi löytää asioita, kuten vääriä positiivisia? Tässä on tarkempi yhteenveto siitä, mitä saatat nähdä:
- Funktioille välitetyt lisäargumentit (esim. funktio vaatii kaksi argumenttia, koodi välittää kolme)
- Print/sprintf-funktioille välitetyt lisäargumentit (esim. muotomerkkijono sisältää yhden paikkamerkin, koodi välittää kaksi arvoa korvattavaksi)
- Ilmeisiä virheitä kuolleessa koodissa
- Maaginen käyttäytyminen, joka on määriteltävä.
Kaikki edellä mainitut suoraan arkistosta.
Tässä sääntötasoilla voi olla suuri merkitys, vaikkakin se saattaa vaatia hieman säätämistä, jotta saat sen tasolle, joka sopii tiimillesi tai projektillesi.
Entä WordPressin analyysi?
Viktor Szépe jakoi tämän resurssin kanssani (jotain hän itse asiassa on kirjoittanut), ja mielestäni se on jotain olennaista ja hyödyllistä. Paketin idea on yksinkertainen:
Se ratkaisee kaikki ongelmat, joita minulla oli WordPress-koodin analysoinnin aikana.
Ei paha, eikö?
Analysoi koodisi
Riippumatta projektistasi, koodiorganisaatiostasi tai millä tasolla käytät tätä apuohjelmaa, tarkoituksena on aina parantaa WordPress-koodin kirjoittamisen laatutasoa.
Tämän asentaminen Composer-paketina ja sen suorittaminen srchakemistossasi on askel oikeaan suuntaan.
Kuten aiemmin todettiin, aion jakaa muutamia muita työkaluja ja sitten jakaa, kuinka ne kaikki suoritetaan koodipohjaa vastaan ennen koodin siirtämistä arkistoon.
Merkintä
Jos sinulla on ongelmia paketin määrittämisessä, Dave Mackey otti minuun yhteyttä samanlaisen ongelman ja sen ratkaisun kanssa .