Share
Met de wijdverbreide adoptie van PHP is het bijna te gemakkelijk om een script of fragment te vinden om te doen precies wat je nodig hebt. Helaas is er geen filter voor wat een "goede werkwijze" is en wat is, nou ja ... niet zo goed bij het schrijven van een PHP-script. We hebben betrouwbare bronnen nodig, die bewezen hebben dat ze een goed begrip hebben van de best practices van PHP.
We hebben PHP-masters nodig om ons de beste principes te laten zien die we moeten volgen voor hoogwaardige PHP-programmering.
Er is geen betere bron dan PHP's maker om te weten waar PHP toe in staat is. Rasmus Lerdorf creëerde PHP in 1995 en sindsdien verspreidt de taal zich als een lopend vuurtje door de ontwikkelaarscommunity en verandert het gezicht van internet. Rasmus heeft echter met die bedoeling geen PHP gemaakt. PHP is ontstaan vanuit de behoefte om webontwikkelingsproblemen op te lossen.
En net als bij veel open source-projecten die populair zijn geworden, was de motivatie nooit filosofisch of zelfs narcistisch. Het was puur een geval van het hebben van een tool om real-world web-gerelateerde problemen op te lossen. In 1994 waren de opties vrij beperkt wat betreft webontwikkelingstools.
Je kunt echter PHP niet voor alles gebruiken. Lerdorf is de eerste om toe te geven dat PHP eigenlijk slechts een hulpmiddel is in je gereedschapskist en dat zelfs PHP beperkingen heeft.
Gebruik het juiste gereedschap voor de klus. Ik heb bedrijven tegengekomen die volledig in PHP zijn gekocht, het absoluut overal gebruiken, maar het was nooit bedoeld als algemene taal die geschikt was voor elk probleem. Het is het meest thuis als de front-end scriptingtaal voor het web.
Proberen om PHP te gebruiken voor alles is niet efficiënt, en het is zeker niet het beste gebruik van je tijd als een webontwikkelaar. Wees niet bang om andere talen te gebruiken als PHP niet werkt voor uw project.
Niemand hoeft de autoriteit van Matt Mullenweg in twijfel te trekken met PHP. Hij heeft (naast een rabiate community) het populairste blogsysteem op aarde ontwikkeld: Wordpress. Nadat Mattpress en Wordpress zijn gemaakt, lanceerde het de stellaire Wordpress.com, een gratis blogsite op basis van de WordPress MU-programmabasisblogsoftware voor meerdere blogs. Op het moment van schrijven schrijft Wordpress.com meer dan 4 miljoen blogs en hun gebruikers hebben vandaag meer dan 140.000 berichten geschreven. (U kunt hier meer interessante statistieken over het gebruik van Wordpress.com zien.)
Als iemand weet hoe een website moet worden geschaald, is het Matt Mullenweg. In 2006 gaf Matt enig inzicht in de databasestructuur van Wordpress en legde uit waarom Wordpress MU voor elk blog een aparte MySQL-tabel gebruikt, in tegenstelling tot het gebruik van één gigantische "monolithische" tabel voor alle blogs..
We hebben deze aanpak getest voor MU, maar vonden dat het te duur was om voorbij een bepaald punt te schalen. Met monolithische structuren raak je een muur op basis van je hardware. In MU zijn gebruikers verdeeld en kunnen eenvoudig worden gepartitioneerd, bijvoorbeeld op WordPress.com hebben we de gebruikers gepartitioneerd tussen 4096 databases, waarmee je heel goedkoop en efficiënt kunt opschalen naar honderdduizenden en zelfs miljoenen gebruikers en extreem veel verkeer.
Doordat de tabellen kunnen worden gemigreerd, kan de code en uiteindelijk de blogs veel sneller worden uitgevoerd en gemakkelijker worden geschaald. Naast een aantal zware caching en slim databasegebruik heeft Matt aangetoond dat extreem populaire sites zoals Facebook en Wordpress.com van PHP kunnen afvloeien en de ongelofelijke verkeersbelasting aankunnen.
Dave Child is het geesteskind (teehee) achter de onlangs hernoemde Added bytes (voorheen ilovejackdaniels.com) website met Dave's uitstekende spiekbriefjes voor veel programmeertalen. Dave's werkte voor veel ontwikkelingsbedrijven in het Verenigd Koninkrijk en heeft zichzelf gevestigd als een autoriteit in de programmeerwereld.
Dave biedt wat wijs advies als het gaat om het schrijven van beveiligde code in PHP: vertrouw je gebruikers niet. Ze kunnen je gewoon pijn doen.
Dus de hoofdregel van alle webontwikkeling, en ik kan het niet genoeg benadrukken, is: Nooit, Ooit, vertrouw op uw gebruikers. Stel dat elk stukje gegevens dat uw site verzamelt van een gebruiker schadelijke code bevat. Altijd. Dat omvat gegevens waarvan u denkt dat u deze hebt gecontroleerd met validatie aan de kant van de klant, bijvoorbeeld met behulp van JavaScript. Als je dat kunt regelen, begin je goed. Als PHP-beveiliging belangrijk voor je is, is dit ene punt het belangrijkste om te leren.
Dave gaat verder met het geven van specifieke voorbeelden van veilige praktijken in delen een, twee en drie van zijn 'Writing Secure PHP'-serie. Maar zijn ultieme afhaal is dit:
Eindelijk, wees volledig en volkomen paranoïde.
Als je ervan uitgaat dat je site nooit onder vuur komt te liggen, of voor problemen komt te staan, als er uiteindelijk iets mis gaat, zul je in enorme problemen komen. Als u er echter van uitgaat dat elke bezoeker van uw site erop uit is om u te krijgen en dat u permanent in oorlog bent, helpt u uzelf om uw site veilig te houden en bent u voorbereid op het geval dingen fout zouden gaan.
Ben Balbo schreef voor Site Point, een zeer gerespecteerde handleiding voor ontwikkelaars en ontwerpers. Hij is lid van de commissie voor zowel de Melbourne PHP User Group als de Open Source Developers 'Club, dus hij weet een paar dingen over de taal. Het is geen verrassing met de achtergrond van Ben als PHP-ontwikkelaar en -trainer die hij aanbeveelt om een beetje meer na te denken over en voorbereiding op PHP-caching.
Als u een drukke en overwegend statische website hebt - zoals een blog - die wordt beheerd via een contentbeheersysteem, zal deze waarschijnlijk weinig wijzigingen vereisen, maar zou u kunnen profiteren van enorme prestatieverbeteringen als gevolg van een kleine investering van uw tijd. Het instellen van caching voor een meer complexe site die inhoud per gebruiker genereert, zoals een portal of winkelwagentjesysteem, zal wat lastiger en tijdrovender blijken, maar de voordelen zijn nog steeds duidelijk.
Er zijn veel verschillende technieken voor caching in PHP, en Ben raakt enkele van de grotere in het artikel aan, zoals:
en vele anderen. Vanwege de aard van dynamische talen zoals PHP, is caching van cruciaal belang om die delen van de pagina op te slaan die vaak worden bezocht en niet vaak veranderen.
Wanneer Chad Kieffer niet bezig is met het schommelen van gebruikersinterfaces en het beheren van databases, geeft hij deskundig advies van zijn blog 2 eetlepels. Vanwege Tsads brede vakgebied, kan hij vaak het grote beeld zien dat andere programmeurs misschien niet hebben, vooral als het gaat om de holistische benadering die Chad hanteert bij het ontwikkelen van een website. Hij is gespecialiseerd in alle aspecten van het ontwikkelingsproces, dus alle inzichten die hij kan bieden bij het samenstellen van een volledig project, zullen van pas komen.
Chad gelooft dat het gebruik van een IDE zoals Eclipse PDT (Eclipse's PHP-ontwikkelpakket) met een mix van sjablonen en fragmenten de doorlooptijd van een project aanzienlijk kan versnellen.
Drukke planningen, lange takenlijsten en deadlines maken het moeilijk voor ontwikkelaars om bekend te raken met enkele van de geavanceerde functies die hun hulpmiddelen bieden. Dit is een schande, omdat sommige functies, zoals Eclipse-sjablonen, de coderingstijd en -fouten echt kunnen verkorten.
Gezond verstand zegt dat je elke keer als je een taak kunt automatiseren, het project sneller gedaan krijgt. Hetzelfde geldt voor de theorie van Dan. Door de tijd te nemen om sjablonen te maken die u steeds weer opnieuw gebruikt, bespaart u veel tijd bij het automatiseren van de repetitieve delen van de codering.
Door een IDE zoals Eclipse en het PDT-pakket te gebruiken, zult u merken dat uw ontwikkelingstijd stapsgewijs sneller gaat. De IDE zal haakjes automatisch sluiten, die ontbrekende puntkomma toevoegen en je zelfs toestaan om te debuggen in de editor, zonder te moeten uploaden naar de server.
(Tsjaad heeft een handige tutorial over aan de slag gaan met Eclipse PDT en de voordelen van een IDE in het algemeen, als je geïnteresseerd bent.)
Hoewel Joey Sochacki misschien niet zo bekend is als Matt Mullenweg in de PHP-community, is hij een doorgewinterde webontwikkelaar en deelt hij tips die hij onderweg heeft opgepikt op zijn blog Devolio.
Joey heeft geconstateerd dat, hoewel er heel wat filtering moet gebeuren bij het schrijven van PHP-code, er niet veel programmeurs gebruik maken van de filterfuncties van PHP.
Gegevens filteren. We moeten het allemaal doen. De meesten, zo niet wij allemaal, verachten het te doen. De meeste zijn echter PHP's filter_ * -functies, die ons in staat stellen allerlei soorten filtering en validatie uit te voeren. Met behulp van PHP's filter_ * -functies kunnen we datatypen, URL's, e-mailadressen, IP-adressen, stripfouten en meer valideren en zuiveren, allemaal met relatief gemak.
Filteren kan lastig zijn, maar deze handleiding kan enorm helpen. Met Joey's hulp leert u hoe u de filters installeert en filtert u bijna iets, gebruik maken van de filterkracht van PHP.
Er is altijd een debat geweest over het gebruik van een PHP-raamwerk zoals Zend, CakePHP, Code Igniter of een ander kader. Er zijn voordelen en nadelen aan het gebruik ervan, en veel ontwikkelaars hebben hun eigen mening over het al dan niet afleggen van deze weg.
Josh Sharp is een webontwikkelaar die zijn brood en boter websites maakt voor klanten. Daarom zou je hem moeten vertrouwen als hij zegt dat het een goed idee is om een PHP-framework te gebruiken om tijd te besparen en fouten bij het programmeren te elimineren. Waarom? Josh gelooft dat het komt omdat PHP te gemakkelijk is om te leren.
Maar PHP's gebruiksgemak is ook zijn ondergang. Omdat er minder beperkingen zijn voor de structuur van de code die u schrijft, is het veel gemakkelijker om slechte code te schrijven. Maar er is een oplossing: gebruik een raamwerk.
PHP-frameworks helpen bij het standaardiseren van uw programmering en kunnen veel tijd besparen in het ontwikkelingsproces. Je kunt meer lezen over het voordeel van het gebruik van een PHP-framework op Josh's blog.
In tegenstelling tot Josh's overtuiging dat men een PHP-raamwerk moet gebruiken, gelooft Rasmus Lerdorf, de peetvader van PHP zelf, dat raamwerken niet zo goed zijn. Waarom? Omdat ze veel langzamer presteren dan eenvoudige PHP.
Tijdens Rasmus 'presentatie op Drupalcon 2008, vergeleek Rasmus de reactietijden met een PHP-pagina met een eenvoudig "Hello World" -voorbeeld en vergeleek het met een paar PHP-frameworks (dia's 24-32), en toonde aan dat PHP-frameworks veel langzamer zijn dan rechte PHP.
Je kunt luisteren of de hele presentatie bekijken waarin Rasmus de prestatieverliezen laat zien met PHP-frameworks. Kortom, Rasmus laat zien dat performance een grote hit wordt als je een PHP-framework gebruikt in plaats van pure PHP te gebruiken.
[Opmerking: als u een PHP-framework moet gebruiken, houdt Rasmus van Code Igniter het beste, omdat het "het minst op een framework lijkt"]
Jack Herrington is geen onbekende in PHP en de ontwikkelingswereld. Naast het schrijven van meer dan 30 artikelen voor de prestigieuze IBM developerWorks, heeft Jack ook programmeerboeken gepubliceerd, zoals PHP Hacks. Jack is een bonafide deskundige.
Herrington beveelt het gebruik van batchverwerking en cron aan om die taken aan te pakken die op de achtergrond kunnen worden verwerkt. Webgebruikers willen niet lang wachten op taken die moeten worden voltooid op internet. Sommige taken duren langer en zijn veel beter geschikt om op de achtergrond te worden uitgevoerd.
Zeker, in sommige kleine gevallen is het een beetje makkelijker om van een hulpdraad af te vuren om kleine klusjes te verwerken. Maar het is gemakkelijk om te zien dat met het gebruik van conventionele tools - cron, MySQL, standaard objectgeoriënteerde PHP en Pear :: DB - het creëren van batchtaken in PHP-applicaties gemakkelijk is, gemakkelijk te implementeren en eenvoudig te onderhouden is..
Jack gelooft in eenvoud, en in plaats van threading op servers te gebruiken, gebruikt hij de eenvoudige combinatie van cron, PHP en MySQL om taken op de achtergrond te verwerken.
Ik heb beide gedaan en ik denk dat cron het voordeel heeft van het "Keep It Simple, Stupid" (KISS) -principe. Het houdt de verwerking van de achtergrond eenvoudig. In plaats van een multithreaded opdrachtverwerkingstoepassing die voor eeuwig draait en dus nooit geheugen kan lekken, hebt u een eenvoudig batch-script dat cron start. Het script bepaalt of er iets te doen is, doet het en gaat dan uit. U hoeft zich geen zorgen te maken over geheugenlekken. U hoeft zich geen zorgen te maken dat een draad blokkeert of vast komt te zitten in een oneindige lus.
David Cummings heeft een eigen softwarebedrijf dat gespecialiseerd is in content management-systemen en heeft verschillende prijzen gewonnen. Als iemand efficiënt een PHP-applicatie weet te ontwikkelen, is het Dave.
David schreef in een SitePoint-artikel over de twee PHP-tips die hij wenste dat hij in het begin had geleerd. Een van de tips: schakel foutmeldingen onmiddellijk in. Op de lange termijn zal dit veel tijd besparen.
Het allerbelangrijkste dat ik vertel aan mensen die PHP gebruiken, is om foutmeldingen op het maximale niveau te zetten. Waarom zou ik dit willen doen? Over het algemeen wordt de foutrapportage ingesteld op een niveau dat veel kleine dingen verbergt zoals:
- een variabele van te voren aangeven,
- verwijzen naar een variabele die niet beschikbaar is in dat segment van code, of
- een definitie gebruiken die niet is ingesteld.
Deze factoren lijken misschien niet zo belangrijk - totdat je gestructureerde of objectgerichte programma's met functies en klassen ontwikkelt. Te vaak zou het schrijven van code zonder foutmeldingen hoog oprijzen u uren kosten omdat u lange functies hebt doorzocht die niet werkten omdat een variabele verkeerd gespeld of niet toegankelijk was.
Foutrapportage kan het vinden van de reden voor een fout veel gemakkelijker maken. Een kleine fout in de code kan snel worden geïdentificeerd als PHP's foutrapportage hoog wordt ingeschakeld. Bespaar jezelf wat tijd en haartrekken door PHP je bugs voor je te laten vinden.
Lees het vorige bericht in deze serie: 10 Principes van de CSS Masters.
Glen Stansberry is een webontwikkelaar en blogger die meer worstelt dan hij zou willen toegeven met CSS. Je kunt meer tips over webontwikkeling lezen op zijn blog Web Jackalope.
Accentsconagua