Share
2012 was een uitstekend jaar voor de PHP-community, dankzij de vele erg benodigde functies die aan versie 5.4 werden toegevoegd, evenals de talloze projecten, waarmee PHP naar het volgende niveau werd gebracht.
In dit artikel wil ik een handvol van de problemen bespreken die mensen in het verleden met PHP hadden, en een glimp opvangen van waarom 2013 misschien wel het jaar van PHP is!
Dit kan een verrassing voor je zijn, maar veel mensen hebben negatieve gevoelens ten opzichte van PHP-ontwikkelaars en de taal als geheel. Je weet waarschijnlijk precies wat ik bedoel, als je hebt overwogen om Ruby de afgelopen jaren te leren kennen, vanwege een gevoel van groepsdruk.
Voordat u echter wijzigingen aanbrengt, moet u zich afvragen: "Waarom heeft PHP zo'n stigma?"
Nou, zoals veel van de belangrijke vragen van het leven, is er geen eenduidig antwoord. Nadat je een beetje online hebt gezocht, voor sommige PHP-argumenten, zul je zien dat ongeveer tachtig procent van de argumenten tegen PHP geworteld zijn in onwetendheid, in een of andere vorm.
Ongeveer tachtig procent van de argumenten tegen PHP zijn geworteld in onwetendheid.
Er zijn beginners, die niet echt weten hoe PHP werkt. Dit resulteert in vragen, zoals "Waarom kan je niet naar knopgebeurtenissen luisteren met PHP?,en soortgelijke vragen over AJAX.
Vervolgens heb je de mensen die geen andere taal of raamwerk kennen dan degene die ze momenteel gebruiken. Dit zijn de soorten mensen die argumenten maken, zoals "Rails is veel eenvoudiger dan PHP," en dingen zoals dat.
De derde vorm van misvatting komt van de mensen die de vooruitgang van PHP in de loop der jaren niet hebben bijgehouden. In plaats daarvan vechten ze nog steeds tegen de taal zoals deze jaren en jaren geleden bestond. Dit resulteert in verklaringen, zoals: "PHP is niet object georiënteerd"of"PHP is sucks omdat het namespacing niet ondersteunt."Je snapt het.
Ten slotte hebben we de meer intelligente ontwikkelaars die geloven dat "PHP niet kan schalen" of "PHP heeft geen standaarden", wat volledig onwaar is. Schalen heeft minder te maken met de taal, en meer met de server en hoe uw app is gestructureerd. Wat betreft normen? Welnu, er is slechts een snelle Google-zoekopdracht voor PHP-FIG.
Wat is de PHP-FIG? "Het idee achter de groep is dat projectvertegenwoordigers praten over de overeenkomsten tussen onze projecten en manieren vinden om samen te werken. Ons voornaamste publiek is elkaar, maar we zijn ons ervan bewust dat de rest van de PHP-gemeenschap toekijkt. andere mensen willen aannemen wat we doen, ze zijn welkom om dat te doen, maar dat is niet het doel. "Het is een ongelukkige waarheid dat sommige argumenten, die via het web doordringen, hetzij volledig onwaar zijn, hetzij bijgewerkt.
Er zit echter waarheid in elke kritiek.
Er zit echter waarheid in elke kritiek. PHP is niet perfect. Als het gaat om de implementatie van kernfuncties en functies, is PHP inconsistent. Deze argumenten zijn volledig geldig.
Deze inconsistenties zijn echter niet zonder reden. PHP begon als wat we vandaag zouden noemen als een sjablonerende taal. Sindsdien heeft het meerdere paradigmaverschuivingen ondergaan, transformerend in een functionele taal, zoals C, en vervolgens naar de volledig OOP-taal die we vandaag genieten. Onderweg zijn best practices ontstaan en hebben verschillende mensen de controle gehad over wat er is toegevoegd. Dit resulteert in veel "verschillende" soorten code in één taal. Nu zou je kunnen vragen, "Waarom niet gewoon de slechte delen afkeuren?"
Het antwoord op deze vraag is hetzelfde als waarom we nog steeds sites bouwen voor oude versies van Internet Explorer. Begrijp me niet verkeerd; Ik zou het graag willen laten vallen, maar grote veranderingen zoals deze kunnen niet zonder een beetje tijd worden gedaan. Hopelijk zal PHP na verloop van tijd verder gaan in OOP, en beginnen met het converteren van de objecten om hun functies te gebruiken met de puntnotatie, in plaats van de weliswaar ongemakkelijke -> syntaxis. Dus in plaats van array_push ($ arr, "Waarde");, je zou iets schrijven, zoals $ Arr.push ( "Waarde");.
Maak je geen zorgen; dit soort dingen gebeurden langzaam. Kijk maar naar de nieuwe PHP 5.5-functies. De oude functie-georiënteerde MySQL-add-on is verouderd, in het voordeel van de nieuwere object-georiënteerde benadering.
Nu het verleden bedekt is, gaan we naar het heden. Er zijn een handvol echt coole projecten en bewegingen, waarvan sommige ideeën uit andere talen lenen, om PHP naar een hoger niveau te tillen.
Laten we het volgende overwegen:
De PHP-community kan nu stoppen met het opnieuw uitvinden van het wiel, dankzij Composer.
Geïnspireerd door tools, zoals Bundler en NPM, kan de PHP-community nu opnieuw stoppen met het opnieuw uitvinden van het wiel, dankzij Composer. Node.js was de eerste taal waardoor ik me comfortabel voelde bij het gebruik van pakketten. Als je het eerder hebt gebruikt, dan begrijp je wat ik bedoel. Pakketten worden lokaal in de directory van uw project geïnstalleerd, het is gemakkelijk om documentatie voor de meeste plug-ins te vinden en het is relatief eenvoudig om uw eigen pakketten in te dienen.
PHP bood al jaren een alternatief, PEAR, maar het was niet overdreven intuïtief of gemakkelijk te gebruiken. Het voelde volumineus voor iets dat uiteindelijk platte-tekstbestanden ophaalde. Verder installeerde het alle pakketten wereldwijd. Dit dwong je om mensen te informeren welke pakketten je hebt gebruikt bij het verspreiden van je broncode. Zoals je zou kunnen raden, resulteerde dit in niet-aangepaste versies en andere dingen van die aard.
Als u dat wilt, kunt u uw componenten kiezen en kiezen.
Composer lost dit allemaal op, dankzij lokaal opgeslagen pakketten en de mogelijkheid om per-project afhankelijkheidsbestanden te maken. Dit betekent dat u uw project eenvoudig kunt distribueren met dit afhankelijkheidsbestand en dat anderen hun eigen exemplaar van Composer kunnen gebruiken om automatisch alle opgegeven afhankelijkheden te downloaden en ze tegelijkertijd up-to-date te houden.
Bovendien is Composer een lichte applicatie - geschreven in PHP, zelf - en wordt geleverd met een autoloader-functie. Dit werkt los van de PSR-0-standaard (hierboven vermeld), die automatisch je afhankelijkheden laadt wanneer je ze nodig hebt, zodat je applicatie zo schoon mogelijk blijft.
Al deze functies zijn een duidelijke verbetering, maar zonder acceptatie door de gemeenschap betekent dit niets. Ik ben blij om u te informeren dat het zeer goed is geaccepteerd. Grote projecten, zoals Symfony en Laravel, hebben hun componenten al geüpload naar de Composer-bibliotheek, Packagist. Door het framework op te splitsen in componenten, kunt u eenvoudig uw eigen aangepaste framework samenstellen om aan uw wensen aan te passen. Met andere woorden, geen opgeblazen kaders meer. Als u dat wilt, kunt u uw componenten kiezen en kiezen.
Heb je een voorbeeld nodig? U kunt de databasecomponent van Laravel nemen en deze koppelen met de templating-component uit het Symfony-framework. In feite maakt het Laravel-framework zelf gebruik van veel goed geteste Symfony-componenten. Waarom het wiel opnieuw opbouwen, wanneer je in plaats daarvan je inspanningen op andere gebieden kunt richten?
Zelfs als je problemen hebt met een aantal van PHP's inconsistenties, abstraheert Laravel er bijna alles van.
Dit zou geen artikel over PHP's toekomst zijn zonder Laravel wat meer in detail te bespreken. Er wordt ons vaak gevraagd waarom Nettuts + Laravel zoveel lijkt te duwen als het is geweest. Dit is de verkeerde vraag. Vraag in plaats daarvan "Waarom niet?"
Zelfs als je problemen hebt met een aantal van PHP's inconsistenties, abstraheert Laravel het bijna allemaal, waardoor je het gevoel en de elegantie van een taal krijgt, zoals Ruby, maar met het gemak van PHP.
Laravel komt met Eloquent, een ORM die alles wat met databases te maken heeft opnieuw bedenkt. Ik gebruik meestal MySQL met PHP; Wat u uit de database terugkrijgt, is een bronobject, dat u vervolgens door een functie moet leiden om de resultaten vast te leggen. In Laravel wordt alles als standaard PHP geretourneerd; je krijgt objecten die je kunt wijzigen en opslaan. Je kunt dingen doen, zoals het combineren van resultaten uit meerdere tabellen om te besparen op databaseaanroepen (waarnaar gretig laden wordt verwezen) en belachelijk eenvoudig om dingen te doen, zoals validatie en aangepaste queries. Als een bonus, als je niet van SQL houdt, kan dit allemaal worden gedaan met een OOP-stijl, met behulp van eenvoudige en leesbare methoden, zoals vind en verwijderen.
We hebben alleen het topje van de ijsberg gezien met wat Eloquent naar de tafel brengt, maar je kunt de verbeteringen al zien. Laravel brengt dit soort innovatie naar bijna elk gebied van PHP, inclusief dingen als sjabloneren, routing, migraties, RESTful klassen en meer. Het beste deel is echter dat, met elke nieuwe release, de maker van Laravel, Taylor Otwell, de lat nog hoger legt.
Als je meer over Laravel wilt weten, raad ik de Tuts + Premium-cursus, Laravel Essentials, aan die door onze eigen Jeffrey Way wordt gegeven. Ik zeg dit niet als onderdeel van het Nettuts + personeel, maar als een persoon die de serie bekeek. Ik kan eerlijk zeggen dat ik geen enkele kennis had van Laravel om naar binnen te gaan, en Jeffrey deed het uitstekend om zoveel mogelijk te dekken.
Uiteindelijk gaat het niet echt om het framework, maar om de community-ondersteuning. Zolang er ondersteuning is voor een project, wordt het bijgewerkt en blijft het relevant. Als je je zorgen maakt over hoe lang het populair blijft, maak je je kansen eenvoudig door het actief te gebruiken!
Het volgende ding dat ik zou willen bespreken is de updates van PHP die in 2012 werden uitgebracht. Met de release van versie 5.4 kwam een overvloed aan uitstekende nieuwe functies. Voor een volledig overzicht van de updates, kunt u deze twee artikelen hier bekijken op Nettuts +: 5.4 artikel, 5.5 artikel.
Maar, voor een korte samenvatting van mijn favorieten:
Dit zijn slechts een paar van de nieuwe verbeteringen en het is een hele lijst met dingen die momenteel worden besproken voor de volgende versie, die later dit jaar wordt uitgebracht..
Laten we tenslotte een beetje praten over het testen van uw code. Hoewel we weliswaar iets te laat zijn met de game, zag onze community in 2012 de testgestuurde ontwikkelingsmethodologie op grote schaal worden toegepast. Ik zou een groeipercentage kunnen verzinnen, maar ik denk dat een betere indicatie van de waarheid is dat je gewoon rondkijkt op verschillende dev-sites en -forums. Je zult zeker een piek zien! Als het gaat om testen in PHP, is PHPUnit de geaccepteerde standaard.
Denk aan je project voordat je erin gaat duiken, zoals een cowboy.
Vaak bent u van plan een code te schrijven, maar u verliest iets in de vertaling. Wat ik hiermee bedoel is dat je maar één ding plant, maar bij het implementeren verlies je een beetje van de integriteit of functionaliteit. Een ander veel voorkomend probleem doet zich voor bij het schrijven van code voor grote projecten: u krijgt uiteindelijk meerdere klassen en bestanden die elk hun eigen dependances hebben. Wat je overhoudt is een "verweven evolutie" van functionaliteit die moeilijk kan worden bijgehouden en onderhouden. Als je een spel Jenga speelt, kun je door een update bij te werken, een andere stuk breken en je applicatie verlammen. Dit zijn slechts twee voorbeeldproblemen, maar er zijn zeker anderen.
Nou, je schrijft duidelijke tests voordat je een productiecode schrijft. Dit betekent dat wanneer u uw eigenlijke code gaat schrijven, deze zich moet conformeren aan uw oorspronkelijke plan. Niet alleen dit, maar in de loop van de tijd worden de afhankelijkheden bijgehouden in uw tests. Als u een stukje code bijwerkt en per ongeluk een van de tests afbreekt, ontvangt u onmiddellijk een melding.
Ja, het instellen van deze tests vereist een extra stap, maar dat is ook het denken voordat je spreekt. Heeft iemand daar de voordelen van? Natuurlijk niet. Hetzelfde geldt voor testen: denk aan je project voordat je erin gaat duiken, zoals een cowboy.
Het is een opwindende tijd om een PHP-ontwikkelaar te zijn. Veel van de inherente problemen hebben of worden opgelost. Zoals voor de andere kwesties, zullen we die gemakkelijk verhelpen met een goed kader en testen.
Dus wat denk je ervan? Kom je aan boord? Ben je het niet met me eens? Als dat het geval is, gaan we verder met de onderstaande discussie!
Accentsconagua