Parema WordPressi koodi kirjutamine: PHPStan
Selle sarja viimases postituses (mis on tõsi küll, mõni aeg tagasi) rääkisin pikemalt heliloojast ja selle lukufailist.
Soovitan lugeda kahte eelmist artiklit, sest helilooja mängib lõpuks selles materjalis rolli, mida see ja tulevased postitused jagavad. Kui aga otsustate neile mitte järele jõuda (või olete Composeriga juba tuttav), siis eelmiste postituste põhisisu on vastavalt järgmine:
Ma ei soovita hankija kataloogi oma hoidlasse kontrollida. Sellest võib hiljem saada tohutu kataloog ja see võib kahjustada kogu Composeri eesmärki.
Eesmärk on tagada, et kõigil oleks sama versioon projekti sõltuvustest – mitte vanemaid ega uuemaid versioone, vaid sama versioon.
Seda arvestades saame installida arvukalt sõltuvusi või pakette, mis aitavad meil tagada, et kirjutame võimalikult kvaliteetset koodi.
Muidugi, mõned neist võivad olla kodeerimisstandardite kujul, kuid need on tõesti rohkem reeglid kui kvaliteetse koodi kirjutamise elemendid (kuigi ma arvan, et neid ei tohiks arutelust välja jätta – lihtsalt välja jätta sel ajal 🙃).
Tagasi kõnealuste tööriistade juurde: millised on mõned tööriistad, mis aitavad kirjutada kvaliteetset WordPressi koodi? Jagan mõnda oma lemmikut ja räägin neist, kuidas saaksime neid kõiki koodibaasi vastu käivitada.
Kõigepealt vaatame staatilist analüüsi PHPStaniga.
Parem WordPressi kood PHPStaniga
Mis on ikkagi staatiline analüüs?
Esiteks paar sõna staatilise analüüsi kohta. Nimelt, mis see on? See on üks suutäis:
Staatiline koodi analüüs (tuntud ka kui lähtekoodi analüüs) tehakse tavaliselt osana koodi ülevaatusest (tuntud ka kui valge kasti testimine) ja see viiakse läbi turvaarenduse elutsükli (SDL) juurutamisetapis.
Staatilise koodi analüüs viitab tavaliselt staatilise koodi analüüsi tööriistade käitamisele, mis püüavad esile tuua võimalikke haavatavusi „staatilises" (mittetöötavas) lähtekoodis, kasutades selliseid tehnikaid nagu Taint Analysis ja Data Flow Analysis.
Mõelge sellele järgmiselt: see on viis programmi analüüsimiseks võimalike vigade suhtes, mida te ei pruugi koodibaasi kallal töötades näha.
See tähendab, et võib esineda probleeme, vigu ja turvaprobleeme, mida te ei saa mitmel põhjusel tuvastada (väikseim neist on see, et olete koodile liiga lähedal).
Aja jooksul on aga arenduskogukond õppinud koodi analüüsimise, reeglistiku genereerimise ja tööriistade loomise viise, mis aitavad täpselt kõike ülalnimetatut leida.
WordPressi-keskse koodi staatiline analüüs
Ja siin tuleb mängu PHPStan.
Nagu mainitud, on paketi eesmärk tuvastada teie koodis esinevad vead või vead enne, kui teie koodi kasutab keegi muu kui arendajad, need esile tõsta ja anda teile võimalus need parandada.
Kuna sellised tööriistad uurivad koodibaasi (võrreldes koodi käitamisega), ei ole alati võimalik selget pilti saada. See tähendab, et võime saada valepositiivseid tulemusi.
Sellest aga pikemalt mõne aja pärast.
Kui olete huvitatud PHPStani käivitamisest oma koodibaasi vastu, on see lihtne. Pärast selle installimist ärge unustage seda lihtsalt seadistada nii, et see ei näeks vendorkataloogi ega näiteks WordPressi tuuma.
Selle asemel paluge tal oma koodi uurida.
PHPStani installimine
Esmalt composer.jsonlisage oma faili jaotisesse järgmine rida require-dev:
"phpstan/phpstan": "^0.11.12"
Seejärel käivitage composer updateoma terminalis.
Kui see on installitud, saate seda käivitada üksiku faili, kataloogi või kataloogide komplekti vastu. Kui olete lugenud minu eelmisi postitusi koodikorralduse kohta, siis teate, et ma olen fänn, kes hoiab suurema osa projekti lähtekoodist srcteie käsutuses, võin käivitada midagi sellist:
$ vendor/bin/phpstan analyse src
See loob väljundi selle põhjal, mida utiliit leiab.
Kas mäletate varem, kui ütlesin, et see võib leida selliseid asju nagu valepositiivsed tulemused? Siin on üksikasjalikum ülevaade sellest, mida võite näha:
- Funktsioonidele edastatavad lisaargumendid (nt funktsioon nõuab kahte argumenti, kood edastab kolm)
- Funktsioonidele print/sprintf edastatud lisaargumendid (nt vormingu string sisaldab ühte kohahoidjat, kood edastab asendamiseks kaks väärtust)
- Ilmsed vead surnud koodis
- Maagiline käitumine, mis tuleb määratleda.
Kõik ülaltoodu otse hoidlast.
See on koht, kus reeglitasemed võivad kõikvõimalikuks muuta, kuigi see võib vajada veidi kohandamist, et viia see tasemele, mis sobib teie meeskonna või projekti jaoks.
Aga WordPressi analüüs?
Viktor Szépe jagas seda ressurssi minuga (tegelikult on tema autoriks) ja ma arvan, et see on midagi asjakohast ja kasulikku. Paketi idee on lihtne:
See lahendab kõik probleemid, mis mul tekkisid WordPressi koodi analüüsimisel.
Pole paha, eks?
Analüüsige oma koodi
Sõltumata teie projektist, koodikorraldusest või sellest, millisel tasemel te seda konkreetset utiliiti käitate, on alati eesmärk parandada WordPressi koodi kirjutamise kvaliteedi taset.
Selle installimine Composeri paketina ja seejärel srckataloogis käivitamine on samm õiges suunas.
Nagu eelnevalt öeldud, jagan ma mõnda muud tööriista ja seejärel jagan, kuidas neid kõiki enne koodi hoidlasse sisestamist koodibaasi vastu käivitada.
Märge
Kui teil on paketi seadistamisel probleeme, võttis Dave Mackey minuga ühendust sarnase probleemi ja selle lahendusega.