WordPressi pistikprogrammide raamatukogud, 1. osa

Mida rohkem te WordPressiga töötate, eriti kui kasutate selliseid tööriistu nagu Composer ja muud sarnased, seda tõenäolisemalt leiate teatud teeke, tööriistu ja sarnaseid asju, mis moodustavad teie töötavate projektide aluse.

Mõnikord võite need leida, kui otsite teiste inimeste koodi, võib-olla leiate need GitHubi sirvides või võib-olla soovitab keegi, kellega koos töötate, olenevalt projektist teeki (või mõnda).

Isiklikult olen kogenud kõike eelnevat ja mida rohkem ma töötan enda või teiste jaoks lahenduste loomise kallal, seda rohkem leian end iga projekti jaoks sama vundamenti rajamas (mis on tavaliselt mingi pistikprogramm). .

WordPressi pistikprogrammide raamatukogud

Sel eesmärgil arvasin, et tasub jagada teeke, mida ma WordPressi pistikprogrammide loomisel kasutan. Sisu jaotatakse mõne postituse vahel, et iga postitus oleks lühike ja keskendunud, kuid võib-olla leiate midagi, mida te pole varem kasutanud (või mis parandab teie praegust kasutust).

PHPUnit

Igaüks, kes on kirjutanud mis tahes koodi mis tahes programmeerimiskeeles, tunneb tõenäoliselt igat tüüpi *Unit teeki. Lühidalt öeldes on see viis ühikutestide hõlpsaks kirjutamiseks.

Projekti kodulehelt :

PHPUnit on programmeerijale orienteeritud PHP testimisraamistik. See on xUnit arhitektuuri eksemplar üksuste testimise raamistike jaoks.

Ma ei ole keegi, kes tellib tingimata 100% koodikatvuse (ja see on teise postituse teema), kuid kui kavatsete kirjutada ühikuteste, siis on see defacto teek teie koodi üksuse testimiseks.

GrumPHP

Kogu selle aasta jooksul on GrumPHP-st saanud vaieldamatult minu lemmikteek (kuigi seda on paremaks muutnud täiendavad teegid, mida ma selle postituste seeria jooksul kajastan).

Olen sellest ka teistes postitustes rääkinud. Kuigi see kirjeldab end kui "koodikvaliteedi tööriista", ei saa te tõesti eeliseid näha enne, kui ühendate selle koodi jälgimiseks enne hoidlasse salvestamist.

Pikem kirjeldus on järgmine:

Kui testid ebaõnnestuvad, ei saa te muudatusi sisse viia. See mugav tööriist mitte ainult ei paranda teie koodibaasi, vaid õpetab ka teie kaastöötajaid kirjutama paremat koodi, järgides teie meeskonnana kindlaks määratud parimaid tavasid.

Ja just nagu oleksite oma IDE-s kasutanud mis tahes kodeerimisstandardite monitori, on see üks neist asjadest, mille kasutamine võib alguses pettumust valmistada.

Kuid seda õppides on lihtsam teada, mida see märgib, nii et hakkate automaatselt kirjutama kõrgema kvaliteediga koodi.

PHPMD

PHPMD (lühend sõnast PHP Mess Detector) töötab hästi koos GrumPHP-ga, kuna suudab teie koodi töödelda enne, kui selle hoidlasse sisestate.

Projekt kirjeldab ennast järgmiselt:

See võtab ette antud PHP lähtekoodi baasi ja otsib selles allikas mitmeid võimalikke probleeme.

Nagu paljude sarnaste teekide puhul, saab see konkreetne konfigureerida reeglistiku, et saaksite asju hõlpsalt sisse ja välja lülitada vastavalt teie või teie meeskonna eelistustele.

PHP-parser

Idee oma koodi analüüsimiseks PHP-parseri teegi seadistusest tundub natuke meta, eks? Pean silmas seda, et teil on PHP käitusaeg ja paljud IDE-d teevad seda ka, kuid see toimib veidi teistmoodi.

Hoidlast:

See on PHP 5.2 kuni PHP 7.1 parser, mis on kirjutatud PHP-s. Selle eesmärk on lihtsustada staatilise koodi analüüsi ja manipuleerimist.

Neile, kes tunnevad programmeerimiskeelte (ja seega ka grammatika) tööd, on mõte teha koodi staatiline analüüs .

Sellest hoolimata on see veel üks teek, mis aitab parandada koodi kvaliteeti, vähendades koodi keerukust.

Rohkem tuleb

Sarja lõpus jagan, kuidas lisada need kõik composer.jsonfaili, mida saate oma projektis kasutada.

Kui töötate kliendi jaoks lahenduse kallal, peate võib-olla muutma kõigi nende tööriistade versioone, kuid avastate, et enamik neist pakub tuge PHP5.6-le ja kuni PHP7.1-le.