Aneeminen ryhmä php. Venäläiset PHP Core Teamissa: "Kieli kasvaa kuin koralli." Miten pääsit PHP Core Teamiin, mitä polkua kuljit päästäksesi sinne?

PHP ohjelmointikieli on kulkenut pitkän tien henkilökohtaisten sivujen luomistyökalusta yleiskäyttöiseen kieleen. Nykyään se on asennettu miljoonille palvelimille ympäri maailmaa, ja sitä käyttävät miljoonat kehittäjät, jotka luovat monenlaisia projekteja.

Se on helppo oppia ja erittäin suosittu erityisesti aloittelijoiden keskuudessa. Siksi kielen kehitystä seurasi sitä ympäröivän yhteisön voimakas kehitys. Valtava määrä skriptejä kaikkiin tilanteisiin, eri kirjastot, puitteet. Suunnittelun ja koodin kirjoittamisen yhtenäisten standardien puute on johtanut valtavan tietotuotteiden kerroksen syntymiseen, jotka on rakennettu tämän tuotteen kehittäjän omien periaatteiden mukaan. Tämä oli erityisen havaittavissa erilaisten kanssa työskennellessä PHP-kehykset, joka edusti pitkään suljettua ekosysteemiä, joka ei yhteensopiva muiden kehysten kanssa huolimatta siitä, että niiden ratkaisemat tehtävät ovat usein samanlaisia.

Vuonna 2009 useiden puitteiden kehittäjät sopivat yhteisön luomisesta PHP Framework Interop Group (PHP-FIG), joka laatii suosituksia kehittäjille. On tärkeää korostaa, että tässä ei ole kyse ISO-standardit, on oikeampaa puhua suosituksista. Mutta niistä lähtien, jotka loivat PHP-KUVA Koska kehittäjäyhteisö edustaa suuria kehyksiä, heidän suosituksellaan on vakava painoarvo. Tuki PSR (PHP-standardin suositus) -standardit mahdollistaa yhteensopivuuden, mikä helpottaa ja nopeuttaa lopputuotteen kehitystä.

Yhteensä kirjoitettaessa standardeja on 17, joista 9 on hyväksytty, 8 on luonnosvaiheessa, niistä keskustellaan aktiivisesti, 1 standardia ei suositella käytettäväksi.

Siirrytään nyt suoraan kunkin standardin kuvaukseen. Huomaa, että en mene tässä yksityiskohtaisesti jokaisesta standardista, vaan tämä on lyhyt johdanto. Myös artikkelissa käsitellään vain niitä PSR-standardit, jotka on virallisesti hyväksytty, ts. ovat Hyväksytty-tilassa.

PSR-1. Peruskoodausstandardi

Se edustaa yleisimpiä sääntöjä, kuten esimerkiksi käyttöä PHP-tunnisteet, tiedostojen koodaus, funktion määrityspaikan, luokan ja käyttöpaikan erottelu, luokkien ja menetelmien nimeäminen.

PSR-2. Koodityyliopas

Se on jatkoa ensimmäiselle standardille ja säätelee välilehtien ja rivinvaihtojen käyttöä koodissa, koodirivien enimmäispituutta, ohjausrakenteiden suunnittelun sääntöjä jne.

PSR-3. Kirjausliittymä.

Tämä standardi on suunniteltu mahdollistamaan sisäänkirjoitettuihin sovelluksiin kirjautuminen (kirjautuminen). PHP.

PSR-4. Käynnistysstandardi

Tämä on luultavasti tärkein ja tarpeellisin standardi, jota käsitellään erillisessä yksityiskohtaisessa artikkelissa. Luokat, jotka toteuttavat PSR-4, voidaan ladata yhdellä automaattilatauksella, jolloin yhden kehyksen tai kirjaston osia ja komponentteja voidaan käyttää muissa projekteissa.

PSR-6. Välimuistin käyttöliittymä

Välimuistia käytetään parantamaan järjestelmän suorituskykyä. JA PSR-6 mahdollistaa tietojen tallentamisen ja hakemisen tavallisesti välimuistista yhtenäisen käyttöliittymän avulla.

PSR-7. HTTP-viestiliittymä

Kun kirjoitat enemmän tai vähemmän monimutkaista PHP-sivustot, sinun on melkein aina työskenneltävä HTTP-otsikot. Varmasti, PHP kieli tarjoaa meille valmiita vaihtoehtoja työskentelyyn niiden kanssa, kuten superglobaali taulukko $_SERVER, toiminnot otsikko(), setcookie() jne., mutta niiden manuaalinen analyysi on täynnä virheitä, eikä aina ole mahdollista ottaa huomioon kaikkia heidän kanssaan työskentelyn vivahteita. Ja niin, helpottaaksemme kehittäjän työtä sekä tehdäksemme käyttöliittymästä vuorovaikutusta varten HTTP-protokolla tämä standardi otettiin käyttöön. Kerron tästä standardista yksityiskohtaisemmin yhdessä seuraavista artikkeleista.

PSR-11. Kontin käyttöliittymä

Kun kirjoitat PHP ohjelmat Usein joudut käyttämään kolmannen osapuolen komponentteja. Ja jotta ei eksyisi tähän riippuvuuksien metsään, koodiriippuvuuksien hallintaan keksittiin erilaisia menetelmiä, jotka ovat usein yhteensopimattomia keskenään, minkä tämä standardi tuo yhteisen nimittäjän.

PSR-13. Hypermedia linkit

Tämä käyttöliittymä on suunniteltu helpottamaan sovellusohjelmointirajapintojen kehittämistä ja käyttöä ( API).

PSR-14. Yksinkertainen välimuistikäyttöliittymä

Se on standardin jatko ja parannus PSR-6

Joten tänään katsoimme PSR-standardit. Ajantasaiset tiedot standardien tilasta saat ottamalla yhteyttä:

Jos olet kehittänyt PHP:tä muutaman viime vuoden ajan, olet todennäköisesti tietoinen kielen ongelmista. Kuulet usein, että se on pirstoutunut kieli, hakkerointityökalu, että sillä ei ole todellista määritystä jne. Tosiasia on, että PHP on kasvanut paljon viime aikoina. PHP 5.4 toi sen lähemmäksi täysobjektimallia ja esitteli paljon uusia toimintoja.

Ja tämä kaikki on tietysti hyvää, mutta entä puitteet? PHP:ssä niitä on valtava määrä. Kun aloitat etsimisen, huomaat, että sinulla ei ole tarpeeksi aikaa tutkia niitä kaikkia, koska uusia kehyksiä ilmaantuu jatkuvasti ja jokaiseen keksitään jotain erilaista. Joten miten voit muuttaa tämän joksikin, joka ei vie kehittäjiä ja mahdollistaa toiminnallisuuden siirtämisen helposti kehyksestä toiseen?

Mikä on PHP-FIG

PHP-FIG (PHP Framework Interop Group) on organisoitu ryhmä kehittäjiä, jonka tavoitteena on löytää tapoja, joilla useat puitteet toimivat yhdessä.

Kuvittele vain: tuet tällä hetkellä Zend Framework -projektia, joka tarvitsee ostoskorimoduulin. Olet jo kirjoittanut tällaisen moduulin aiempaan projektiin, joka oli Symphonyssa. Mikset tekisi sitä uudelleen? Onneksi sekä ZendF että Symphony ovat osa PHP-FIG:tä, joten on mahdollista tuoda moduuli kehyksestä toiseen. Eikö olekin hienoa?

Selvitetään, mitkä puitteet sisältyvät PHP-FIG:hen

PHP-FIG-jäsenet

Kuka tahansa kehittäjä voi lisätä kehyksensä PHP-FIG-osallistujien luetteloon. Sinun on kuitenkin maksettava rahaa tehdäksesi tämän, joten jos sinulla ei ole yhteisön tukea, et todennäköisesti suostu siihen. Tämä tehdään sen estämiseksi, että miljoonia mikrokehyksiä rekisteröidään ilman mainetta.

Nykyiset jäsenet:

Mikä on PSR?

PSR (PHP Standards Recommendations) - standardisuositukset, PHP-FIG:n työn tulos. Jotkut ryhmän jäsenet ehdottavat sääntöjä kullekin PSR:lle, kun taas toiset äänestävät sääntöjen tukemisen tai poistamisen puolesta. Keskustelua käydään Google-ryhmissä ja PSR-sarjat ovat saatavilla virallisella PHP-FIG-verkkosivustolla.

Katsotaanpa joitain PSR:itä:

Ensimmäinen askel kohti kehysten yhdistämistä on yhteinen hakemistorakenne, minkä vuoksi otettiin käyttöön yhteinen käynnistysstandardi.

Nimiavaruuden ja luokan rakenteen on oltava \*.
Jokaisen nimitilan on sisällettävä ylätason tila ("Vendor Name").
Jokaisella nimiavaruudella voi olla niin monta tasoa kuin halutaan.
Jokainen nimitilan erotin muunnetaan DIRECTORY_SEPARATOR-muotoon ladattaessa.
Jokainen "_"-merkki luokassa LUOKAN NAME muunnetaan muotoon DIRECTORY_SEPARATOR.
Täysin pätevä nimiavaruus ja luokka lisätään .php:llä, kun ne ladataan.

Esimerkki automaattilataustoiminnosta:

PSR-1 - Peruskoodausstandardi

Nämä PSR:t säätelevät ydinstandardeja, joiden pääajatuksena on, että jos kaikki kehittäjät käyttävät samoja standardeja, koodi voidaan siirtää ilman ongelmia.

Tiedostoissa saa käyttää vain tunnisteita
Tiedostoissa saa käyttää vain UTF-8-koodausta ilman tuoteluetteloa.
Tilan nimien ja luokkien tulee seurata PSR-0:aa.
Luokkien nimet on ilmoitettava StudlyCaps-merkinnöissä.
Luokkavakiot on ilmoitettava isoilla kirjaimilla alaviivalla erotettuina.
Menetelmät on ilmoitettava camelCase-merkinnöissä.

PSR-2 - Koodaustyyliopas

Nämä ovat laajennettuja ohjeita PSR-1:lle, jotka kuvaavat koodin muotoilusäännöt.

Koodin on oltava PSR-1:n mukainen.
Sarkainten sijasta tulee käyttää 4 välilyöntiä.
Rivin pituudelle ei pitäisi olla tiukkaa rajoitusta, suositeltu pituus on enintään 80 merkkiä.
Nimiavaruuden ilmoituksen jälkeen tulee olla yksi tyhjä rivi.
Luokkien sulkeiden tulee avautua seuraavalla rivillä määrityksen jälkeen ja sulkeutua luokan rungon jälkeen (sama menetelmät).
Menetelmien ja ominaisuuksien näkyvyys on määriteltävä (julkinen, yksityinen).
Ohjausrakenteiden avaussulut tulee olla samalla linjalla, sulkukannattimet seuraavalla rivillä rakenteen rungon jälkeen.
Välilyöntejä ei sijoiteta ohjausrakennemenetelmien aloittavien sulkeiden jälkeen ja ennen sulkevia sulkeita.

PCR-3 - Loggerin käyttöliittymä

PCR-3 säätelee kirjaamista, erityisesti yhdeksää päämenetelmää.

LoggerInterface tarjoaa 8 menetelmää kahdeksan RFC 5424 -tason kirjaamiseen (debug, ilmoitus, varoitus, virhe, kriittinen, hälytys, hätätilanne).
Yhdeksäs log()-menetelmä ottaa varoitustason ensimmäisenä parametrinaan. Metodin kutsumisen hälytystason parametrilla täytyy palauttaa sama tulos kuin menetelmän kutsumisen tietyllä lokitasolla (log(ALERT) == alert()). Määrittämättömän varoitustason menetelmän kutsumisen täytyy antaa Psr\Log\InvalidArgumentException.

Aivan kuten PSR-0, PSR-4 tarjoaa parannettuja automaattilatausmenetelmiä

Termi "luokka" tarkoittaa luokkia, rajapintoja, ominaisuuksia ja muita vastaavia rakenteita
Täysin pätevällä luokan nimellä on seuraava muoto: \ (\)*\
Kun lataat tiedoston, joka vastaa täysin hyväksyttyä luokan nimeä:

Yhden tai useamman johtavan nimiavaruuden peräkkäinen sarja täysin määritetyssä luokan nimessä, lukuun ottamatta johtavaa nimitilan erotinta, vastaa vähintään yhtä "juurihakemistoa".
Hakemistojen ja alihakemistojen nimien on vastattava nimiavaruuden kirjainkokoa.
Luokan koko nimen pääte vastaa .php-päätteistä tiedostonimeä. Tiedostonimen kirjainkoon on vastattava koko luokan nimen päätteen kirjainkokoa.
Autoloader-toteutus ei saa heittää poikkeuksia, tuottaa minkään tason virheitä, eikä sen tarvitse palauttaa arvoa.

Johtopäätös

PHP-FIG muuttaa tapaa, jolla puitteet kirjoitetaan, mutta ei sitä, miten ne toimivat. Asiakkaat vaativat usein, että työskentelet olemassa olevan koodin kanssa kehyksessä tai määrität, minkä kehyksen kanssa sinun tulee työskennellä projektin parissa. PSR-suositukset helpottavat paljon kehittäjien elämää tässä suhteessa, ja se on hienoa!

Koska tekniikan kehitys on johtanut siihen, että jokaisella ohjelmoijalla on nyt oma tietokone, meillä on sivuvaikutuksena tuhansia erilaisia kirjastoja, puitteita, palveluita, API:ita jne. kaikkiin tilanteisiin. Mutta kun tämä elämäntapaus tulee, syntyy ongelma - mitä käyttää ja mitä tehdä, jos se ei oikein sovi - kirjoita se uudelleen, kirjoita omasi tyhjästä tai liitä useita ratkaisuja eri käyttötapauksiin.

Luulen, että monet ovat huomanneet, että projektin luominen ei usein johdu niinkään ohjelmointiin kuin koodin kirjoittamiseen useiden valmiiden ratkaisujen integroimiseksi. Joskus tällaiset yhdistelmät muuttuvat uusiksi ratkaisuiksi, joita voidaan käyttää toistuvasti myöhemmissä ongelmissa.

Siirrytään tiettyyn "käytävään" tehtävään - objektikerrokseen tietokantojen käsittelyä varten PHP:ssä. Ratkaisuja on laaja valikoima PDO:sta monitasoisiin (ja mielestäni ei täysin sopiviin PHP:ssä) ORM-moottoreihin.

Suurin osa näistä ratkaisuista siirtyi PHP:hen muista alustoista. Mutta usein kirjoittajat eivät ota huomioon PHP:n ominaisuuksia, mikä yksinkertaistaisi huomattavasti sekä siirrettyjen konstruktien kirjoittamista että käyttöä.
Yksi tämän luokan tehtävien yleisimmistä arkkitehtuureista on Active Record -malli. Tätä mallia käytetään erityisesti ns. entiteettien rakentamiseen, joita käytetään muodossa tai toisessa useilla alustoilla aina EJB3:n persistent beaneista .NET:n EF:iin.

Rakennetaan siis samanlainen rakenne PHP:lle. Yhdistetään kaksi hienoa asiaa - valmis ADODB-kirjasto ja PHP-kieliobjektien heikosti kirjoitetut ja dynaamiset ominaisuudet.
Yksi ADODB:n monista ominaisuuksista on niin sanottu SQL-kyselyjen automaattinen generointi tietueiden lisäämistä (INSERT) ja päivittämistä (UPDATE) varten perustuen assosiatiivisiin datataulukoihin.
Itse asiassa ei ole mitään sotilaallista ottaa taulukkoa, jossa avaimet ovat kenttien nimiä ja arvot vastaavasti dataa ja luovat SQL-kyselymerkkijonon. Mutta ADODB tekee sen älykkäämmällä tavalla. Kysely perustuu taulukkorakenteeseen, joka on aiemmin luettu tietokantaskeemasta. Seurauksena on, että ensinnäkin vain olemassa olevat kentät sisällytetään sql:ään, eikä kaikkea peräkkäin, toiseksi kentän tyyppi otetaan huomioon - merkkijonoihin lisätään lainausmerkit, päivämäärämuotoja voidaan muodostaa aikaleiman perusteella, jos ADODB näkee sen. merkkijono lähetetyssä arvossa jne. .

Mennään nyt PHP:n puolelta.
Kuvitellaan tällainen luokka (yksinkertaistettuna).

Luokkaentiteetti( suojatut $kentät = array(); julkinen loppufunktio __set($nimi, $arvo) ($this->fields[$name] = $arvo; ) julkinen lopullinen funktio __get($name) ( return $ tämä- >kentät[$nimi] ) )

Välittämällä sisäisen taulukon ADODB-kirjastoon voimme automaattisesti luoda SQL-kyselyitä tietokannan tietueen päivittämiseksi tietyllä objektilla. Samalla ei tarvita hankalia suunnitelmia tietokantataulukkokenttien yhdistämiseksi XML-pohjaiseen kokonaisuuteen. objektikentät ja vastaavat. On vain välttämätöntä, että kentän nimi vastaa objektin ominaisuutta. Koska tietokannan kenttien ja objektin kenttien nimeämisellä ei ole tietokoneelle väliä, ei ole mitään syytä, miksi ne eivät täsmää.

Näytämme kuinka se toimii lopullisessa versiossa.
Valmistun luokan koodi löytyy Gististä. Tämä on abstrakti luokka, joka sisältää tietokannan kanssa työskentelyyn tarvittavan vähimmäismäärän. Huomaan, että tämä luokka on yksinkertaistettu versio ratkaisusta, jota on testattu useissa kymmenissä projekteissa.

Kuvitellaan, että meillä on tällainen merkki:

LUO TAULUKKO "käyttäjät" ("käyttäjänimi" varchar(255) , "created" päivämäärä , "user_id" int(11) EI NULL AUTO_LISÄYS, ENSISIJAINEN AVAIN ("user_id"))
Tietokannan tyypillä ei ole väliä - ADODB tarjoaa siirrettävyyden kaikkiin yleisiin tietokantapalvelimiin.

Luodaan Entity-luokan perusteella User entiteettiluokka

/** * @table=users * @keyfield=user_id */ luokka Käyttäjä laajentaa entiteettiä( )

Siinä kaikki.
Helppokäyttöinen:

$käyttäjä = uusi käyttäjä(); $user->username="Vasya Pupkin"; $käyttäjä-> luotu=aika(); $käyttäjä->tallenna(); //tallenna tallennustilaan //lataa uudelleen $thesameuser = User::load($user->user_id); echo $thesameuser ->käyttäjänimi;

Ilmoitamme taulukon ja avainkentän pseudomerkinnöissä.
Voimme myös määrittää näkymän (esimerkiksi view =usersview), jos, kuten usein tapahtuu, entiteetti valitaan sen taulukon perusteella, jossa on liitetyt tai lasketut kentät. Tässä tapauksessa tiedot valitaan näkymästä ja taulukko päivitetään. Ne, jotka eivät pidä tällaisista huomautuksista, voivat ohittaa getMetatada()-metodin ja määrittää taulukon parametrit palautetussa taulukossa.

Mitä muuta hyötyä Entity-luokasta on tässä toteutuksessa?

Voimme esimerkiksi ohittaa init()-menetelmän, jota kutsutaan entiteettiinstanssin luomisen jälkeen, alustaaksemme oletusarvoisen luontipäivämäärän.
Tai ylikuormita afterLoad()-menetelmää, jota kutsutaan automaattisesti, kun entiteetti on ladattu tietokannasta, muuntaaksesi päivämäärän aikaleimaksi helpompaa käyttöä varten.
Tuloksena ei ole paljon monimutkaisempi rakenne.

/** * @table=users * @view=usersview * @keyfield=user_id */ luokka Käyttäjä laajentaa entiteettiä( suojattu funktio init() ( $this->created = time(); ) suojattu toiminto afterLoad() ( $this -> luotu = strtotime($this->created);

Voit myös ylikuormittaa beforeSave- ja beforeDelete-menetelmiä ja muita elinkaaritapahtumia, joissa voit esimerkiksi suorittaa vahvistuksen ennen tallentamista tai muita toimenpiteitä - esimerkiksi poistaa kuvia ladattavasta käyttäjästä poistettaessa.

Lataamme luettelon kokonaisuuksista kriteerien mukaan (olennaisesti WHERE-ehto).
$users = User::load("käyttäjänimi kuten "Pupkin" ");
Lisäksi Entity-luokka antaa sinun suorittaa mielivaltaisen, "natiivi" SQL-kyselyn niin sanotusti. Haluamme esimerkiksi palauttaa käyttäjäluettelon, jossa on joitain tilastoihin perustuvia ryhmittelyjä. Ei ole väliä mitkä kentät palautetaan (tärkeintä on, että user_id on oltava, jos entiteettiä on edelleen käsiteltävä), sinun on vain tiedettävä niiden nimet, jotta voit käyttää valittuja kenttiä. Entiteettiä tallennettaessa, kuten yllä olevasta ilmenee, sinun ei myöskään tarvitse täyttää kaikkia entiteettiobjektissa olevia kenttiä, vaan ne menevät tietokantaan. Eli meidän ei tarvitse luoda lisäluokkia satunnaisille näytteille. Aivan kuten anonyymit rakenteet haettaessa EF:ssä, vain tässä se on sama entiteettiluokka kaikillaä.

Tarkkaan ottaen yllä olevat menetelmät luetteloiden hankkimiseksi ovat jonkin verran AR-mallin ulkopuolella. Pohjimmiltaan nämä ovat tehdasmenetelmiä. Mutta kuten Occamin vanha mies testamentaa, älkäämme luoko kokonaisuuksia enempää kuin on tarpeellista, vaan luodaan erillinen Entity Manager tai jotain vastaavaa.

Huomaa, että yllä olevat ovat vain PHP-luokkia ja niitä voidaan laajentaa ja muokata haluttaessa lisäämällä entiteettiin (tai perusentiteettiluokkaan) ominaisuuksia ja liiketoimintalogiikkamenetelmiä. Toisin sanoen emme saa vain kopiota tietokantataulukon rivistä, vaan liiketoimintakokonaisuuden osana sovelluksen objektiarkkitehtuuria.

Kuka tästä voisi hyötyä? Ei tietenkään kokeneille kehittäjille, jotka uskovat, että oppia yksinkertaisemman käyttö ei ole kunnioitettavaa, eikä perfektionisteille, jotka luottavat siihen, että jos ratkaisu ei tuota miljardia kutsua tietokantaan sekunnissa, se ei ole ratkaisu. . Foorumien perusteella monet tavalliset kehittäjät, jotka työskentelevät tavallisten (99,9 %) projektien parissa, kohtaavat ennemmin tai myöhemmin ongelman löytää yksinkertainen ja kätevä objektipohjainen tapa päästä tietokantaan. Mutta he joutuvat kohtaamaan sen tosiasian, että useimmat ratkaisut ovat joko kohtuuttoman pitkälle kehitettyjä tai ovat osa jonkinlaista kehystä.

P.S. Ratkaisu tehtiin viitekehyksestä erillisenä projektina