Praegu ma ei tea, mitu artiklit olen WordPressi kodeerimisstandardite olulisusest kirjutanud (piisab, et linkida neile siin, siin ja siin, mis vist loeb midagi).
Kuid pärast seda, kui olen teinud klientide jaoks piisavalt projekte ja töötanud arendajatega, kes on minust palju targemad ja tuttavad täiustatud tööriistadega, olen ma kohas, kus otsustan hakata kasutama PSR-e WordPressi WordPressi arenduses.
Oh seda draamat, eks?
Tõsiselt aga. Sellel on põhjused ja mõnikord arvan, et WordPressi kodeerimisstandardeid tuleks siiski kasutada, kuid olen kiiresti veendunud, et mis tahes moodsa projekti WordPressi peale ehitamine peaks kasutama kaasaegsemaid PHP tööriistu (mida ma mainin lühidalt hiljem).
PSR-ide kasutamine WordPressi arendamisel
Sellised postitused annavad sageli ülevaate arutelust või dramaatilisest vastusest WordPressis, mis pole minu eesmärk ega ka minu arvates vajalik. Ausalt öeldes tean päris palju teisi arendajaid , kes kõik on seda juba ammu teinud, sellest rääkinud, edasi liikunud ja jätkanud edu nii oma äris kui ka hobiprojektides.
Kuid arvestades, et olen nii palju rääkinud ühest ja teisest, mõtlesin, et tasub jagada oma seisukohta, miks ma otsustan selle nihke praegu teha, ja selle põhjustest.
1 Võrdsus PHP kogukonnaga
Umbes viimase aasta jooksul ja tegelikult ainult selle aasta viimaste kuude jooksul olen harjunud:
- kogenumad PHP-le orienteeritud arendajasõbrad, kes toetavad tööriistu, mis eeldavad, et PSR-id võetakse kasutusele,
- //@codingStandardsIgnoreStart ja //@codingStandardsIgnoreEnd kasutamine minu koodis,
- kohandatud reeglistikud minu projektide jaoks, mis põhinevad keskkondadel, kus need on juurutatud,
- ja veel.
Lõppkokkuvõttes on see soov säilitada võrdsus (või natuke sellest) suurema PHP kogukonnaga, kirjutades samal ajal ka loetavat standardipõhist koodi WordPressi peale. Samuti sooviksin kasutada mõnda muud tööriista ja olemasolevate tööriistade uuemaid versioone (mida käsitlen hiljem selles postituses).
2 Probleemid kaasaegse keskkonnaga
Selle postituse kirjutamise ajal oli PHP CodeSniffer (mis on vajalik WordPressi kodeerimisstandardite käitamiseks) versioonis 3.0.2. Siiski on PHPCS-i ja WordPressi kodeerimisstandarditega ühilduvusprobleeme. Täpsemalt :
PHP CodeSnifferi uuel versioonil on mõned toredad funktsioonid, kuid see sisaldab murrangulisi muudatusi, mis tähendab, et WordPressi kodeerimisstandardid ei ühildu.
Selguse huvides (ja tarkvara olemuse tõttu) on aja küsimus, millal see parandatakse. Kuid kui töötate koodibaasi kallal ja kasutate Composerit ja WordPressi kodeerimisstandardeid, peate konkreetselt määrama PHP CodeSnifferi versiooni, mitte selle, mis praegu on uusim versioon.
Lisaks olen kogenud probleeme klientidega, kus PSR-ide mittekasutamine WordPressi arenduses on põhjustanud koodi juurutamisel veidra käitumise. Võib-olla võiks mõelda, et nad peaksid keskkonda kohandama, kuid kui nad töötavad selle nimel, et neid kasutavatele inimestele oleksid kättesaadavad kõige kaasaegsemad tööriistad, siis miks taanduda?
3 Ühilduvus kaasaegsete tööriistadega
Lõpuks on mitmeid kaasaegseid tööriistu, mida ma pole saanud kasutada, rääkimata õppimisest, kuna seda, mida versioonide loomine toetab ja mida ei toeta.
Näiteks kasutasime GrumPHP – d hiljutises projektis, mis toetab mitmesuguseid tööriistu, kuid me ei saanud kasutada näiteks PHPMD -d, kuna PSR-e ei kasutatud. Mis minusse puutub:
- Soovin oma oskusi arendajana (ja selles kontekstis PHP arendajana) pidevalt täiendada.
- Moodsamate tööriistade toe puudumine paneb mind hoidmismustrisse, mida ma muidu ei kogeks,
- Soovin jätkata tööd WordPressiga, kuid teha seda kaasaegsema töövooga
Ja praegu tekitab PSR-ide mittekasutamine lõhe ülejäänud PHP kogukonna ja WordPressi tegemiste vahel. Seega tahaksin edasi liikuda, töötades samal ajal projektide kallal lisaks tarkvarale, mida mulle endiselt meeldib kasutada.
Kuidas on lood WordPressi kodeerimisstandarditega
Mida see siis WordPressi kodeerimisstandardite ja varasemate postituste kohta tähendab? Mitte midagi, tõesti. Kuidas ma seda näen: WordPressi kodeerimisstandardeid tuleks kasutada alati, kui töötate WordPress Core’i või muuga, mis on sellega tihedalt integreeritud.
Aga kui töötate millegi kallal, mis asub WordPressi peal või millegi kallal, mis kasutab WordPressi alusena, ja saate WordPressi arenduses kasutada PSR-e koos tööriistadega, mis aitavad teie loodava koodibaasi kvaliteeti tõsta.
Nii et vähemalt praegu on see vaatenurk, mille ma omaks võtan. Ootan põnevusega, kuidas see järgmise paari kuu jooksul välja kujuneb. Ja nagu kõige muu kohta, mida olen jaganud, jagan selle ümberlülitamise aspekte.