Share
2012 var et utmerket år for PHP-fellesskapet, takket være mange dårlige funksjoner som ble lagt til versjon 5.4, samt de utallige prosjektene, som fortsetter PHP til neste nivå.
I denne artikkelen vil jeg gjerne vurdere en håndfull av problemene som folk hadde med PHP tidligere, og gi et glimt på hvorfor 2013 bare kan være året for PHP!
Dette kan komme som en overraskelse for deg, men mange mennesker har negative følelser mot PHP-utviklere, og språket som helhet. Du vet sannsynligvis nøyaktig hva jeg mener, hvis du har vurdert å lære Ruby de siste par årene på grunn av noen følelse av peer press.
Men før du gjør noen endringer, må du spørre deg selv: "Hvorfor har PHP et slikt stigma?"
Vel, som mange av livets viktige spørsmål, er det ikke noe klart svar. Etter å ha gjort litt på nettet, for noen PHP-argumenter, finner du at omtrent åtti prosent av argumentene mot PHP er forankret i uvitenhet, i en eller annen form.
Om lag åtti prosent av argumentene mot PHP er forankret i uvitenhet.
Det er nybegynnere, som egentlig ikke vet hvordan PHP fungerer. Dette resulterer i spørsmål, som "Hvorfor kan du ikke lytte til knapphendelser med PHP?,"og lignende spørsmål om AJAX.
Deretter har du folkene som ikke vet om annet språk eller rammeverk enn det de bruker. Dette er typer mennesker som lager argumenter, for eksempel "Rails er mye enklere enn PHP,"og ting som det.
Den tredje form for misforståelse kommer fra de som ikke har holdt opp med PHPs fremskritt gjennom årene. I stedet bekjemper de fremdeles språket, slik det eksisterte for mange år siden. Dette resulterer i uttalelser, som: "PHP er ikke objektorientert"eller"PHP suger fordi det ikke støtter namespacing."Du får ideen.
Til slutt har vi de mer intelligente utviklerne som tror at "PHP ikke kan skalere" eller "PHP har ingen standarder", som er helt feil. Skalering har mindre å gjøre med språket, og mer med serveren og hvordan appen din er strukturert. Når det gjelder standarder? Vel, det tar bare et raskt Google-søk etter PHP-FIG.
Hva er PHP-FIG? "Ideen bak gruppen er at prosjektrepresentanter skal snakke om fellesforholdene mellom prosjektene våre og finne måter vi kan jobbe sammen. Vårt hovedmålgruppe er hverandre, men vi er veldig klar over at resten av PHP-fellesskapet ser på. andre folk ønsker å vedta hva vi gjør, de er velkommen til å gjøre det, men det er ikke målet. "Det er en uheldig sannhet at noen argumenter, som gjennomsyrer gjennom nettet, enten er helt falske eller oppdatert.
Det er imidlertid sannhet i enhver kritikk.
Det er imidlertid sannhet i enhver kritikk. PHP er ikke perfekt. Når det gjelder implementering av kjernefunksjoner og funksjoner, er PHP inkonsekvent. Disse argumentene er helt gyldige.
Disse inkonsekvensene er imidlertid ikke uten grunn. PHP startet som det vi ville referere til i dag som et templerende språk. Siden da har det gått gjennom flere paradigmeskift, som forvandler seg til et funksjonelt språk, som C, og deretter til det helt OOP-språket vi nyter i dag. Underveis er det kommet gode fremgangsmåter, og forskjellige mennesker har vært i kontroll over hva som er lagt til. Dette resulterer i mange "forskjellige" typer kode på ett språk. Nå kan du spørre, "Hvorfor ikke bare deaktivere de dårlige delene?"
Svaret på dette spørsmålet er det samme som hvorfor vi fortsatt bygger nettsteder for gamle versjoner av Internet Explorer. Ikke misforstå meg; Jeg vil gjerne bare slippe det, men store endringer som dette kan ikke gjøres uten litt tid. Forhåpentligvis vil PHP over tid gå videre inn i OOP, og begynne å konvertere sine objekter til å bruke sine funksjoner med punktnotasjonen, i stedet for det riktignok vanskelig -> syntaks. Så, i stedet for array_push ($ arr, "Value");, du ville skrive noe, som $ Arr.push ( "Value");.
Ikke bekymre deg; ting som dette har skjedd sakte. Bare se på de nye PHP 5.5-funksjonene. Den gamle funksjonsorienterte MySQL-tillegget har blitt avskrevet, til fordel for den nyere objektorienterte tilnærmingen.
Nå med fortiden dekket, la oss flytte opp til nåtiden. Det er en håndfull veldig kule prosjekter og bevegelser, hvorav noen låner ideer fra andre språk, for å drive PHP til neste nivå.
La oss vurdere følgende:
PHP-fellesskapet kan nå slutte å gjenoppfinne hjulet igjen og igjen, takk til Komponist.
Inspirert av verktøy, som Bundler og NPM, kan PHP-fellesskapet nå slutte å gjenoppfinne hjulet igjen og igjen, takket være Komponist. Node.js var det første språket som fikk meg til å føle meg komfortabel med å bruke pakker. Hvis du har brukt det før, vet du hva jeg mener. Pakker er installert lokalt i prosjektets katalog, det er lett å finne dokumentasjon for de fleste pluginene, og det er relativt enkelt å sende inn egne pakker.
PHP tilbyr et alternativ i mange år, PEAR, men det var ikke altfor intuitivt eller enkelt å bruke. Det føltes tungt for noe som til slutt hentet ren tekstfiler. Videre installerte den alle pakker globalt. Dette tvang deg til å informere folk hvilke pakker du brukte når du distribuerte kildekoden. Som du kanskje gjetter, resulterte dette i feilmatchede versjoner og andre ting av den typen.
Hvis du ønsker det, kan du velge og velge komponenter.
Komponist reparerer alt dette, takket være lokalt lagrede pakker, og muligheten til å opprette avhengighetsfiler per prosjekt. Dette betyr at du enkelt kan distribuere prosjektet ditt med denne avhengighetsfilen, og andre kan bruke sin egen kopi av Composer til å automatisk laste ned alle angitte avhengigheter, samtidig som de holder seg oppdatert.
I tillegg er Composer en lett applikasjon - skrevet i PHP, i seg selv - og leveres med en autoloader-funksjon. Dette fungerer utenom PSR-0-standarden (nevnt ovenfor), som automatisk laster dine avhengigheter etter behov, slik at søknaden forblir så ren som mulig.
Alle disse funksjonene er en konkret forbedring, men uten samfunnsvedtak betyr det ingenting. Jeg er glad for å informere deg om at det har vært veldig godt akseptert. Store prosjekter, som Symfony og Laravel, har allerede lastet opp komponentene sine til Composer-biblioteket, Packagist. Å ha rammen oppdelt i komponenter betyr at du enkelt kan bygge ditt eget tilpassede rammeverk for å matche din smak. Med andre ord, ikke flere oppblåste rammer. Hvis du ønsker det, kan du velge og velge komponenter.
Trenger du et eksempel? Du kan ta databasekomponenten fra Laravel, og koble den sammen med den templerende komponenten fra Symfony-rammen. Faktisk utnytter Laravel-rammen seg selv mange velprøvde Symfony-komponenter. Hvorfor gjenoppbygge hjulet, når du i stedet kan fokusere innsatsen på andre områder?
Selv om du har problemer med noen av PHP's inkonsekvenser, abstraper Laravel nesten alt.
Nå ville dette ikke være en artikkel om PHPs fremtid uten å diskutere Laravel i litt mer detaljert. Vi blir ofte spurt hvorfor Nettuts + synes å presse Laravel så mye som det har vært. Dette er feil spørsmål. I stedet spør "Hvorfor ikke?"
Selv om du har problemer med noen av PHP's inkonsekvenser, lar Laravel nesten alt av det, og gir deg følelsen og elegansen til et språk, som Ruby, men med enkel PHP.
Laravel kommer med Eloquent, en ORM som helt nyter alt å gjøre med databaser. Jeg bruker mest MySQL med PHP; hva du kommer tilbake fra databasen er et ressursobjekt, som du da må løpe gjennom en funksjon for å fange resultatene. I Laravel returneres alt som standard PHP; Du får objekter, som du kan endre og lagre. Du kan gjøre ting, for eksempel å kombinere resultater fra flere tabeller for å lagre på databasesamtaler (referert til som ivrig lasting), og latterlig enkelt å gjøre ting, for eksempel validering og tilpassede spørringer. Som en bonus, hvis du ikke liker SQL, kan alt dette gjøres med en OOP-stil, ved hjelp av enkle og lesbare metoder, for eksempel finne og slette.
Vi har bare sett toppen av isfjellet med hva Eloquent bringer til bordet, men allerede kan du se forbedringene. Laravel bringer denne typen innovasjon til nesten alle områder av PHP, inkludert ting som templering, ruting, migreringer, RESTful klasser og mer. Den beste delen er imidlertid at Laraves skapende, Taylor Otwell, fortsetter å heve baren med hver ny utgivelse.
Hvis du vil lære mer om Laravel, anbefaler jeg Tuts + Premium kurset, Laravel Essentials, undervist av vår egen Jeffrey Way. Jeg sier ikke dette som en del av Nettuts + -personalet, men som en person som så på serien. Jeg kan ærlig si at jeg hadde null kjennskap til Laravel går inn, og Jeffrey gjorde en utmerket jobb med å dekke så mye som mulig.
Til slutt handler det egentlig ikke om rammen, men samfunnet støtter. Så lenge det er støtte for et prosjekt, vil det bli oppdatert og vil forbli relevant. Hvis du er bekymret for hvor lenge den vil forbli populær, så, ved å bare bruke den, sikres du oddsen din!
Den neste tingen jeg vil diskutere, er oppdateringene til PHP som ble utgitt i 2012. Med utgivelsen av versjon 5.4 kom en mengde gode nye funksjoner. For en full oversikt over oppdateringene, kan du se på disse to artiklene her på Nettuts +: 5.4 artikkel, 5,5 artikkel.
Men for en rask omtale av mine favoritter:
Disse representerer bare noen få av de nye forbedringene, og deres er en hel liste over ting som for tiden blir diskutert for neste versjon, planlagt å bli utgitt senere i år.
Til slutt, la oss snakke litt om å teste koden din. Selv om det var litt sent til spillet, i 2012, så samfunnet vår utbredt adopsjon av den testdrevne utviklingsmetoden. Jeg kunne utligne en vekstprosent, men jeg føler at en bedre indikasjon på sannhet er å bare se på forskjellige dev-steder og fora. Du vil sikkert se en spike! Når det gjelder testing i PHP, er PHPUnit den godt aksepterte standarden.
Tenk på prosjektet ditt før du dykker inn, som en cowboy.
Mange ganger har du satt ut for å skrive noen kode, men du mister noe i oversettelsen. Det jeg mener med dette er at du planlegger en ting, men når du implementerer det, mister du litt av integriteten eller funksjonaliteten. Et annet vanlig problem oppstår når du skriver kode for store prosjekter: du ender opp med flere klasser og filer som hver har sine egne avhengigheter. Det som igjen er en "sammenvunnet evolusjon" av funksjonalitet som kan vise seg vanskelig å holde styr på og vedlikeholde. Som et spill av Jenga, ved å oppdatere et stykke, kan du ødelegge en annen, kremerende søknaden din. Dette er bare to eksempelproblemer, men det er sikkert andre.
Vel, du skriver klare tester før du skriver noen produksjonskode. Dette betyr at når du kommer til å skrive din faktiske kode, er den tvunget til å overholde den opprinnelige planen. Ikke bare dette, men nedover linjen alle, vil avhengigheter bli sporet i testene dine. Hvis du oppdaterer litt kode, og ved et uhell bryter en av testene, vil du umiddelbart bli varslet.
Ja å sette opp disse tester krever et ekstra trinn, men det tenker før du snakker. Har noen fordelene med det? Selvfølgelig ikke. Det samme gjelder for tester: Tenk på prosjektet ditt før du dykker inn, som en cowboy.
Det er en spennende tid å være en PHP-utvikler. Mange av de iboende problemene har eller blir løst. Som for de andre problemene, blir de lett lindret med et godt rammeverk og testing.
Så hva tror du? Kommer du ombord? Uenig med meg? Hvis ja, la oss fortsette diskusjonen nedenfor!
Accentsconagua