PSR:ien käyttäminen (Versus WordPress Coding Standards)
Tässä vaiheessa en tiedä kuinka monta artikkelia olen kirjoittanut WordPress -koodausstandardien tärkeydestä (riittävästi linkittääkseni ne täällä, täällä ja täällä, mikä kai merkitsee jotain).
Mutta tehtyäni tarpeeksi projekteja asiakkaille ja työskenneltyäni kehittäjien kanssa, jotka ovat paljon älykkäämpiä ja perehtyneet edistyneisiin työkaluihin kuin minä, olen paikassa, jossa päätän aloittaa PSR:n käytön WordPress WordPress -kehityksessä.
Voi draamaa, eikö?
Vakavasti kuitenkin. Tälle on syitä, ja joskus minusta WordPress-koodausstandardeja pitäisi edelleen käyttää, mutta olen nopeasti vakuuttunut siitä, että minkä tahansa nykyaikaisen projektin rakentamisessa WordPressin päälle tulisi käyttää nykyaikaisempia PHP-työkaluja (jotka minä mainitaan lyhyesti myöhemmin).
PSR:ien käyttö WordPress-kehityksessä
Tämänkaltaiset viestit antavat usein tietoa keskustelusta tai dramaattisesta vastauksesta WordPressissä, mikä ei ole tarkoitukseni eikä mielestäni edes tarpeellista. Rehellisesti sanottuna tiedän melkoisen joukon muita kehittäjiä , jotka ovat kaikki tehneet tämän kauan sitten, puhuneet siitä, edenneet ja menestyneet edelleen niin liiketoiminnassaan kuin harrastusprojekteissaan.
Mutta koska olen puhunut yhdestä vastaan niin paljon, ajattelin jakamisen arvoisena näkemykseni siitä, miksi päätän tehdä tämän muutoksen nyt ja sen taustalla olevista syistä.
1 Pariteetti PHP-yhteisön kanssa
Noin viimeisen vuoden aikana ja oikeastaan pelkästään tämän vuoden viimeisten kuukausien aikana olen tottunut enemmän:
- kokeneempi PHP-suuntautunut kehittäjäystävä, joka tukee työkaluja, jotka odottavat PSR:n käyttöönoton,
- //@codingStandardsIgnoreStart ja //@codingStandardsIgnoreEnd käyttö koodissani,
- mukautetut säännöt projekteilleni niiden ympäristöjen perusteella, joissa ne on otettu käyttöön,
- ja enemmän.
Viime kädessä kyse on halusta säilyttää pariteetti (tai hieman sitä) suuremman PHP-yhteisön kanssa samalla kun kirjoitetaan luettavaa, standardeihin perustuvaa koodia WordPressin päälle. Ja haluaisin myös käyttää joitain muita työkaluja ja uudempia versioita olemassa olevista työkaluista (jota käsittelen myöhemmin tässä viestissä).
2 Nykyaikaisten ympäristöjen ongelmat
Tätä viestiä kirjoitettaessa PHP CodeSniffer (joka tarvitaan WordPress-koodausstandardien suorittamiseen) on versiossa 3.0.2. PHPCS:n ja WordPress-koodausstandardien kanssa on kuitenkin yhteensopivuusongelmia. Erityisesti :
PHP CodeSnifferin uudessa versiossa on joitain mukavia ominaisuuksia, mutta se tuo mukanaan murtuvia muutoksia, jotka tarkoittavat, että WordPress-koodausstandardit eivät ole yhteensopivia.
Selvyyden vuoksi (ja ohjelmiston luonteesta johtuen) on ajan kysymys, ennen kuin se korjataan. Mutta jos työskentelet koodikannan parissa ja käytät Composeria ja WordPress Coding Standards -standardeja, sinun on määritettävä erikseen PHP CodeSniffer -versio uusimman version sijaan.
Lisäksi olen kokenut ongelmia asiakkaiden kanssa, joissa se, että en ole ottanut käyttöön PSR:itä WordPress-kehityksessä, on johtanut outoon käyttäytymiseen koodia otettaessa. Ehkä voitaisiin harkita, että heidän pitäisi mukauttaa ympäristöä, mutta jos he työskentelevät saadakseen nykyaikaisimmat työkalut niitä käyttävien ihmisten saataville, miksi heikentää?
3 Yhteensopivuus nykyaikaisten työkalujen kanssa
Lopuksi, on useita nykyaikaisia työkaluja, joita en ole voinut käyttää, puhumattakaan oppimisesta, koska versioinnin luonne tukee ja mitä ei.
Esimerkiksi käytimme GrumPHP: tä äskettäisessä projektissa, jossa on tuki useille työkaluille, mutta emme voineet käyttää esimerkiksi PHPMD :tä, koska PSR:itä ei hyväksytty. Mitä minuun tulee:
- Haluan jatkuvasti kehittää taitojani kehittäjänä (ja tässä yhteydessä PHP-kehittäjänä),
- Nykyaikaisempien työkalujen tuen puute asettaa minut pitokuvioon, jota en muuten kokisi,
- Haluan jatkaa työskentelyä WordPressin kanssa, mutta tehdä sen nykyaikaisemman työnkulun avulla
Ja juuri nyt PSR:ien käyttämättä jättäminen luo aukon muun PHP-yhteisön ja WordPressin tekemisen välille. Haluaisin siis edetä ja jatkaa työskentelyä projektien parissa sellaisten ohjelmistojen parissa, joista edelleen nautin.
Entä WordPressin koodausstandardit
Joten mitä tämä tarkoittaa WordPressin koodausstandardeissa ja aiemmissa viesteissä? Ei oikeastaan mitään. Näen asian: WordPress-koodausstandardeja tulisi käyttää aina, kun työskentelet WordPress Coren tai siihen tiiviisti integroitavan asian parissa.
Mutta jos työskentelet sellaisen parissa, joka on WordPressin päällä, tai jotain, joka käyttää WordPressiä perustana, ja voit käyttää PSR:itä WordPress-kehityksessä sekä työkaluja, jotka voivat auttaa parantamaan luomasi koodikannan laatua.
Joten, ainakin toistaiseksi, tämä on se näkökulma, jonka aion omaksua. Odotan mielenkiinnolla, kuinka se kehittyy seuraavien kuukausien aikana. Ja kuten kaikessa muussakin jakamassani, kerron tämän muutoksen tekemisen näkökohdat.