Fork me on GitHub

PHP

Den forkerte måde

Sidst opdateret: 31/1-2023
cartoon

Velkommen

I PHP programmeringens verden bliver et sæt af populære regler massivt propaganderet af nogle mennesker (i deres bøger og på deres hjemmesider) som værende “Moderne PHP”, alt imens alle andre fremgangsmåder bliver der set ned på som værende gammeldags, dumme eller blot forkerte.

Disse mennesker synes at arbejde utrætteligt mod at få andre mennesker til at følge deres måde at gøre tingene på.

Denne hjemmeside er blevet lavet i et forsøg på at præsenterer et pragmatisk syn på PHP programmering. Et syn dikteret af erfaring og praktisk konsekvens fremfor populære tendenser, teori eller akademisk dogme.

Hjemmesiden PHP - The Wrong Way er et levende dokument og det vil fortsætte med at blive opdateret med mere information efterhånden som det bliver gjort tilgængeligt.

Du er velkommen til at bidrage.

Oversættelser

Det farlige ved ekstremisme

Et problem med programmeringsregler og retningslinjer er at de ofte kun tjener et formål inden for en specifik kontekst. Når de tages ud af kontekst kan en god regel blive en forfærdelig regel. Faktisk er det sådan at enhver god regel bliver dårlig når den bliver taget til det ekstreme.

Det er vigtigt at forstå dette fordi mange af de softwareudviklingsprincipper og regler der udvikles over tid, og som præsenteret af mange forskellige mennesker, ofte bliver misbrugt i hænderne på ekstremister.

Erfaring har lært os at misbrug af en generelle regler og retningslinjer altid resulterer i komplikationer, mangel på sikkerhed, fejlbehæftede resultater, og i nogle tilfælde, fuldstændig og total katastrofe.

KISS princippet, der er et akronym for “Keep It Simple, Stupid” (Hold Det Simpelt, Dumme), er et meget viis og fornuftigt princip der generelt betragtes af erfarende mennesker som et meget godt råd at følge, men selv dette fremragende princip bliver farligt for et projekt hvis det bliver praktiseret til det ekstreme. Der er sådan en ting som at noget er “for simpelt”, et resultat hvor grundlæggende funktionalitet mangler.

Den forkerte måde: Religiøs følgen af regler og retningslinjer. Thumbs down

Altid bruge et framework

Alle PHP frameworks der har et generelt formål stinker!

Rasmus Lerdorf

I PHP samfundet er en virkelig dårlig tendens blevet “de-facto” standard for udvikling af web-applikationer, og det er ved brugen af et populært framework der har et generelt formål.

Denne tendens er ikke opstået og blevet populær fordi det på nogen måde forbedrer resultatet af udviklingsprocessen, eller fordi det er det rigtige at gøre fra et teknologisk og arkitektonisk synspunkt. Denne tendens er blevet populær fordi nogle af udviklerne af disse frameworks har formået at forføre masserne med deres polemik imod at programmere fra bunden af, det har de gjort med strofer som “Du skal ikke genopfinde den dybe tallerken!” og “Du må ikke gøre det selv, andre er dygtigere end dig”.

Mange af hvor tids programmører ignorerer fuldstændigt de grundlæggende principper for forsvarlig programmering, og de bruger en stor mængde tid på at fantasere nye lag af kompleksitet for at fremstå mere kloge, mere “cool”, og mere acceptable af hvem de nu betragter som deres jævnaldrende.

Disse mennesker synes at være betagede af tanken om at have andre mennesker følge deres “måde at gøre tingene på”, at blive en form for PHP samfundsledere, og have andre mennesker til at bruge deres nyeste “hippe” Open Source værktøjer, at de helt glemmer at sørge for at den rådgivning de giver er sund og solid.

I softwareindustrien kan du sammenligne et præ-bygget hus med et framework med et generelt formål. Udvikling af software ved hjælp af generelle formåls frameworks gør dig ikke til en koder eller en programmør mere end at sammensætte et præ-bygget hus gør dig til en tømrer.

På denne hjemmeside skælner vi imellem frameworks og bibliotekker på følgende måde:

I Python og Ruby’s verden er opbygning af hjemmesider fra bunden af trættende fordi hverken Python eller Ruby oprindeligt blev udviklet til at bygge hjemmesider. Som et resultat udvikledes frameworks med generelle formål som Django og Ruby on Rails og de blev hurtigt populære til opbygning af hjemmesider i disse sprog.

PHP blev på den anden side udviklet i begyndelsen af Rasmus Lerdorf som et sæt af værktøjer skrevet i C, som ville give dig mulighed for nemt og hurtigt at udvikle dynamisk HTML. Som sådan var og er PHP stadig et frameworks i sig selv.

PHP har udviklet sig massivt siden da, og i dag PHP kan bruges til meget mere end at bygge HTML og hjemmesider, men at betragte PHP som et slags ramme i sig selv er ikke forkert. PHP er af natur et lag af abstraktion til at udvikle web-applikationer skrevet helt i en proceduremæssig C.

At bruge et bibliotek i dit projekt er kun naturligt. PHP selv kommer med et sæt af biblioteker som du kan bruge til at udvide din egen kode. PDO for eksempel er et letvægts bibliotek der giver en ensartet grænseflade til at få adgang til databaser i PHP.

At bruge et framework ovenpå PHP er på den anden side en helt anden sag.

Når du bruger et framework i PHP tilføjer du et lag af abstraktion oven på endnu et lag af abstraktion, et, der allerede var på plads til at bruge til at begynde med. Det ekstra lag af abstraktion som frameworks giver kan f.eks. tjene til at organisere din kode ind i et på forhånd fastsat sæt af mønstre, eller det kan tilføje endnu mere kompleksitet ved at sammenflette hundredvis eller endda tusindvis af klasser og metoder til et mareridt af afhængigheder, uanset så tilføjer du flere lag af kompleksitet til din kode der ikke er nødvendige!

Al erfaring starter med brugerfladen. Oplevelsen af brugerfladen er resultatet af den underliggende teknologi og mængden af lag af abstraktion. Jo mere abstraktion du bruger, jo mindre effektiv bliver brugerfladen, og jo mere fejlbehæftede bliver applikationen. Jo højere abstraktionsniveau desto mere tabes detaljer og effektivitet.

Forstå dette klart: Det ideelle antal linjer af kode i ethvert projekt er så få som mulige samtidig med at være så klare og letlæselige som muligt!

Hvad ingen har brug for er et framework med et generelt formål. Der er ingen der har et generelt problem, alle har et specifikt problem de forsøger at løse.

Rasmus Lerdorf

Nogle virksomheder begyndte at lytte til hypen om PHP frameworks og de opstartede deres næste projekter ved hjælp af et af disse populære frameworks kun for at ende i en katastrofe. Ikke alene opdagede de at frameworket var virkelig dårlig til at løse deres meget specifikke behov, men det var også meget langsom til at gøre det. Det var umuligt at skalere, og som et resultat begyndte de at rive frameworket fra hinanden i et desperat forsøg på at trække alle de ting ud de ikke havde brug for.

Brug altid den pragmatiske tilgang:

Handling eller politik dikteret af hensyn til de umiddelbare praktiske konsekvenser snarere end af teori eller dogme.

– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014

Den forkerte måde: Altid at bruge et framework ovenpå PHP. Thumbs down

Altid bruge et designmønster

Jeg har den her store allergi overfor elfenbenstårn designs og designmønstre. Peter Norvig, da han var på Harlequin, skrev han dette papir om hvordan designmønstre i virkeligheden bare udgør fejl i dit programmeringssprog. Få et bedre programmeringssprog. Han har fuldstændig ret. Tilbede mønstre og tænke: “Åh, jeg skal bruge mønster X.”

– Brendan Eich i Coders at work - Reflections on the Craft of Programming

Indenfor software udviklingen er et designmønster en genbrugelig løsning på et almindeligt forekommende problem i software design. Et designmønster er ikke et færdigt design som kan transformeres direkte til kode. Det er en beskrivelse eller en idé til hvordan man løser et problem, der kan anvendes i mange forskellige situationer. Objektorienteret designmønstre viser typisk relationer og interaktioner mellem klasser eller genstande, uden at specificere den endelige implementering af klasser eller objekter, der er involveret.

PHP understøtter imperativ, funktionel, objekt-orienteret, proceduremæssig og reflektiv paradigmer. PHP er en kæmpe værktøjskasse med masser af forskellige værktøjer som gør det muligt at løse mange problemer på mange forskellige måder - ikke blot på én måde.

PHP handler om frihed, hurtige og skalerbare løsninger, og at have mange forskellige måder at håndtere problemer på.

Når vi forsøger at forbedre os selv, og i dette tilfælde mere specifikt vores kode, så bliver vi nogle gange låst fast i filosofien om et bestemt mønster eller en idé, og har tendens til at glemme at tænke praktisk.

Når jeg ser mønstre i mine programmer, ser jeg det som et tegn på problemer. Formen af et program bør kun afspejle det problem det skal løse. Enhver anden regelmæssighed i koden er et tegn, for mig i hvert fald, på at jeg bruger abstraktioner, der ikke er stærke nok - ofte, at jeg genererer i hånden udvidelser af en makro, som jeg har brug for at skrive.

Paul Graham

Vi bør ikke blive fanget i filosofien eller ideen bag et bestemt mønster eller løsning. Vores største bekymring er at holde koden så let at navigere og forstå som muligt, og som et resultat let at vedligeholde og nem at holde sikker.

Vi skal også huske at der findes sådan noget som et anti-mønster. Det er et mønster som kan blive almindeligt anvendt, men som er ineffektiv og/eller kontraproduktiv i praksis.

Jeg tror mønstre startede som almindeligt anerkendte bedste løsninger til almindelige problemer. Men nu hvor de har eksisteret et stykke tid, og vi har oplevet applikationer blive gjort ti gange mere kompliceret end de behøver at være, fordi folk forsøger at proppe alle de mønstre, som de har læst om (“min applikation er godt designet, fordi den er fyldt til randen med mønstre”), har mit indtryk af værdien af mønstre ændret sig lidt.

– Paul Weaton i Evil Design Patterns

Brug altid den pragmatiske tilgang:

Handling eller politik dikteret af hensyn til de umiddelbare praktiske konsekvenser snarere end af teori eller dogme.

– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014

Den forkerte måde: At lede efter et mønster for at løse et problem. Thumbs down

Altid bruge objektorienteret programmering

Problemet med objektorienterede sprog er at de har fået alt det her implicitte miljø, som de bærer rundt med dem. Du ville have en banan, men det du fik var en gorilla der holder banane og hele junglen.

– Joe Armstrong i Coders at work - Reflections on the Craft of Programming

Abstraktion er kraftfuldt. Hvad jeg er virkelig allergisk over for, og hvad jeg havde en reaktion på i 90’erne, var alt det CORBA, COM, DCOM, objektorienteret nonsens. Hver nystartet virksomhed havde en eller anden vanvittig ting der ville tage 200.000 metodekald at starte og skrive “Hello world”. Det er en forvrængning! Du vil ikke være en programmør der sættes i forbindelse med den slags ting.

– Brendan Eich i Coders at work - Reflections on the Craft of Programming

Mange softwareudviklere, og mange virksomheder, føler, at objektorienteret programmering er den eneste fornuftige måde at udvikle software på i dag. Enhver der taler imod objektorienteret programmering bliver straks gjort opmærksomme på at de argumenterer imod industriens “konventionelle visdom”.

På programmeringsblogs og programmeringsfora er der rigtig mange mennesker der forsvarer objektorienteret programmering, og som føler sikre på, at de ved, hvad de taler om, på trods af manglen på en standard definition!

Faktum er, at såkaldt objektorienteret programmering som sådan ofte påfører en tung byrde af unødvendig kompleksitet!

Som dataloger og programmører må vi lære at afsætte fordomme og finde den bedste løsning på et givet problem.

I dag er en af ​​de største styrker i PHP dets støtte til både imperativ, funktionel, objektorienteret, proceduremæssig, og reflekterende paradigmer. PHP er en enorm værktøjskasse med masser af forskellige værktøjer, som gør det muligt at løse mange problemer på mange forskellige måder - ikke blot på en måde!

Så snart vi forsøger at tvangsfodre forskellige problemer i en applikation til et enkelt og specifikt programmeringsparadigme, tænker vi ikke kreativt, og vi arbejder ikke effektivt!

En lille historielektion

En af de bedste måder at forstå et bestemt programmeringsparadigme på er ved at se på hvordan det først udviklede sig. Hvad var grunden til dets udvikling? Hvilke problemer eksisterede der med andre programmeringsparadigmer, der nødvendiggjorde en ny måde at tænke på? Var det et problem fra den virkelig verden eller var det blot et akademisk problem? Og hvordan har det siden udviklet sig?

Det er ligegyldigt hvad personen X siger, eller hvilke definitionen personen Y giver, det der betyder noget i forbindelse med paradigmer er historien bag.

Der findes to måder at konstruere et software design på. En måde er at gøre det så enkelt at der naturligvis ingen mangler findes. Og den anden måde er at gøre det så kompliceret at der ikke er nogen åbenlyse mangler.

C.A.R. Hoare

Før i tiden, før indførelsen af ​​objektorienteret programmering, omkring slutningen af ​​halvtredserne, blev meget software er udviklet ved hjælp programmeringssprog der understregede ustruktureret programmering, sommetider omtalt som første- og andengenerationssprog. Ustruktureret programmering (eller ikke-struktureret programmering) er historisk det tidligste programmeringsparadigme. Det blev stærkt kritiseret for at producere “spaghetti” kode.

Der findes både høj og lav-niveau programmeringssprog, der bruger ikke-struktureret programmering. Disse omfatter tidlige versioner af BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, maskinkode, tidlige assemblersystemer (dem uden proceduremæssige meta operatører) og nogle scriptsprog.

Et program i et ikke-struktureret sprog består normalt af sekventielle kommandoer, eller sætninger, som regel én i hver linje. Linjerne er normalt nummereret eller kan have etiketter der tillader strømmen af ​​udførelse at springe til enhver linje i programmet (ligesom med den upopulære GOTO erklæring).

I tresserne opstod struktureret programmering så - primært på grund af det berømte dokument af Edsger Dijkstra Go To udsagn anses for skadelige.

Struktureret programmering er et programmeringsparadigme der forbedrer klarhed, kvalitet og udvikling af software ved at gøre brug af subrutiner, blok strukturer og sløjfer. Dette er i modsætning til brugen af simple spring såsom GOTO-sætningen.

Senere blev proceduremæssig programmering udledt fra struktureret programmering. Procedural programmering er baseret på begrebet “procedure kald”. Et “procedure kald” er blot et andet navn for et “funktionskald”. Procedurer er også kendt som rutiner, underprogrammer eller metoder. En procedure indeholder blot en række beregningsmæssige trin der skal udføres. Enhver given procedure kan kaldes på ethvert tidspunkt under programmets udførelse, herunder igennem andre procedurer eller igennem sig selv.

I starten var enhver procedurer tilrådige for enhver del af et program som global data. I små programmer er dette ikke et problem, men som tingene blev mere komplicerede, og som størrelsen af ​​programmerne voksede, blev små ændringer i en del af programmet et problem mange andre steder.

Ingen havde planer om at ændre programmet og en masse afhængigheder eksisterede. En mindre ændring i en procedure ville resultere i en kaskade af fejl i masser af andre procedurer, som afhang af den oprindelige kode.

En ny teknik blev udviklet der tillod data at blive opdelt i adskilte rækkevidder kaldet “objekter”. Kun specifikke procedurer der tilhørte samme rækkevidde kunne få adgang til de samme data. Dette kaldes “at skjule data” eller “indkapsling”. Resultatet var en meget bedre organiseret kode.

I begyndelsen blev objekter ikke kaldt for objekter, de blev blot betragtet som adskilte områder. Senere da afhængigheder blev reduceret og forbindelser imellem procedurer og variabler indefor disse områder blev betragtet som isolerede segmenter, blev begreberne “objekter” og “objekt-orienteret programmering” født.

Senere, hovedsageligt på grund af udviklingen af ​​Java, opståd visse “buzzwords” og “en procedure” eller “en funktion” blev ikke længere kaldt en funktion, men blev omdøbt til “en metode”, når det boede inde i et separat område. Variabler blev heller ikke længere kaldt “variabler”, men blev omdøbt til “attributter”, når de boede inde i et separat område.

Så et objekt er i dets essens blot en samling af funktioner og variabler nu kaldet for “metoder og attributter”.

Den måde metoder og attributter holdes isoleret i et adskilt område er ved brugen af “en klasse”. En klasse, når den er startet, kaldes for et objekt.

Objekter kan referere til hinanden og igennem en sådan reference kan metoder (funktioner) “kommunikere” med hinanden. Objekter kan også “arve” metoder fra andre objekter og dermed udvide disse, dette kaldes “arv”. Det er en måde at genbruge kode og tillade uafhængige udvidelser af software via offentlige klasser og grænseflader. Relationerne mellem objekter giver anledning til et hierarki. Arv blev opfundet i 1967 til programmeringssproget Simula 67.

Objekter kan også arve metoder fra andre objekter og “overskrive” disse med tilføjet eller ændret funktionalitet, dette kaldes “polymorfi”.

Hvordan disse forskellige ideer implementeres, varierer meget fra programmeringssprog til programmeringssprog.

Objektorienteret programmering handler om at organisere kode på en anden måde end før. Det er en udvidelse af proceduremæssig programmering og det handler om at skjule data (indkapsling) og at undgå global rækkevidde. Det handler om at udvide funktioner ved “låne” deres opbgning uden faktisk at påvirke den oprindelige kode (arv). Og det handler om overskrive funktioner uden at påvirke den oprindelige kode (polymorfi).

Den objektorienterede model gør det nemt at opbygge programmer ved aggregation. Hvad dette ofte betyder i praksis, er at det giver en struktureret måde at skrive spaghetti kode på.

– Paul Graham i Ansi Common Lisp

Den forkerte måde: Altid at bruge objektorienteret programmering. Thumbs down

At være bange for andre menneskers kode

Et argument der ofte udtrykkes for brugen af et framework er, at folk ikke ønsker at beskæftige sig med kodebaser, der er blevet skrevet fra bunden af andre mennesker.

Dette er imidlertid en mærkelig mentalitet, primært stødt på blandt webudviklere i PHP samfundet, det er en mentalitet der udstråler en mangel på professionalisme og erfaring.

At skrivning software og beskæftige sig med andre folks kode er normalt, det er en del af det daglige arbejde i en professionel programmørs hverv, og det er ikke noget at være bange for.

En professionel programmør ser ikke på andre folks kode og begynder at klynke over, hvordan han eller hun er fuldstændig prisgivet den tidligere programmør, som måske ikke længere er forbundet med virksomheden eller projektet, og hvis bare den tidligere programmør havde brugt framework A eller framework B så ville dagen have været reddet.

Dette er ikke en professionel programmørs mentalitet. Ingen gør dette.

Måske skyldes denne mentalitet den lave adgangsbarriere til PHP web udvikling. Uanset, er det et tegn på en person der er i den helt forkerte branche.

En stor del af programmering handler om at skulle arbejde med andre menneskers kode. Det er en del af arbejdet at forsøge at forbedre den eksisterende kodebase, og nogle gange involverer det sågar en fuldstændig omskrivning.

Tag ved lære af de store programmeringsmestre, læs bogen Coders at work - Reflections on the Craft of Programming.

Nogle af de største og mest succesfulde kodebaser i verden er kodebaser der er blevet udviklet af hundredvis af mennesker, der aldrig har mødt hinanden, kodebaser udviklet uden brug af nogen former for frameworks, kodebaser udelukkende udført i et proceduremæssig programmeringssprog uden brug af andet end det proceduremæssige paradigme, og de ville aldrig drømme om at gøre det anderledes.

Linux Kernen består af mere end 20 millioner linjer kode alle skrevet udelukkende ved hjælp proceduremæssig programmering af mere end 14.000 deltagere uden brug af nogen former for frameworks.

De forskellige BSD varianter og det meste af Linux GNU userland er blevet skrevet udelukkende via proceduremæssig programmering uden anvendelsen af nogen former for frameworks.

Det samme gælder for hundredvis af Open Source projekter rundt om i verdenen der til sidst blev opgivet af de oprindelige programmører kun at blive adopteret af andre dygtige programmører. Mange af disse projekter havde meget lidt dokumentation (hvis nogen overhovedet), ingen kommentarer i kodebasen, og ingen retningslinjer eller hjælp at tilbyde overhovedet.

Hele PHP kodebasen er skrevet i C, et rent proceduremæssigt programmeringssprog, uden anvendelse af nogen former frameworks overhovedet.

Når du definerer en klasse i PHP eller når du fyre op for dit favorit PHP framework, så kører du på en eller andens proceduremæssige arbejde!

Selvfølgelig eksisterer der sådan en ting som forfærdelig kode, kode der måske ikke er designet fra starten af, eller kode der måske er vokset fra sig selv mange gange, men kunden ønskede ikke at foretage en renskrivning, kode der er så slem at du kan ikke kan finde hovede eller hale på det længere, men intet framework ville have forhindret denne situation. Dette er ofte den naturlige vækstproces af et program. Til sidst ville ethvert framework være blevet sønderrevet alligevel.

Og ja, der findes forfærdelig spagetti kode, men ingen skriver forfærdelig spagetti kode med vilje. Nogle gange sker det som et resultat af manglende erfaring, ofte er det kundens skyld fordi de ændrer specifikationen flere gange undervejs i udviklingen, men uanset, i begge tilfælde, selv hvis der blev brugt et framework, så ville resultatet stadig være spagetti kode, og uanset hvor meget af det objektorienterede paradigme der blev anvendt, så ville resultatet stadig være spagetti kode.

Som programmører forsøger vi alle at forhindre disse situationer, men det er normalt, det er kunsten at programmerer, det er en del af hvad det vil sige at være programmør!

Den forkerte måde: At være bange for andre menneskers kode Thumbs down

At følge PHP-FIG standarderne religiøst

FIG står for “Framework Interoperability Group”.

PHP-FIG blev udviklet af en gruppe framework udviklere ved php|tek 2009. Siden da har forskellige andre medlemmer tilmeldt sig, og er blevet stemt ind.

Der eksisterer en masse kontroverser angående PHP-fig. Nogle mennesker mener at PHP-FIG er det bedste, der er sket for PHP samfundet siden PHP selv, mens andre betragter gruppen som noget der skal gå i glemmebogen.

Et af problemerne med PHP-FIG er at den præsenterer sig selv på følgende måde i deres spørgsmål/svar sektion:

Ideen bag gruppen er at projektrepræsentanter kan tale om fællestræk mellem vores projekter, og finde måder vi kan arbejde sammen på. Vores primære målgruppe er hinanden, men vi er meget opmærksomme på at resten af PHP samfundet ser på. Hvis andre folk ønsker at adopterer det vi laver, så er de velkomne til at gøre det, men det er ikke målet. Ingen i gruppen ønsker at fortælle dig som programmør hvordan du skal bygge din applikation.

Men når vi ser på hvordan flere medlemmer af gruppen arbejder, kan vi tydeligt se at formålet er ganske i strid med ovenstående udtalelse. Disse medlemmer arbejder utrætteligt i et forsøg på at gøre PHP-FIG til en accepteret “PHP-standard gruppe”, hvilket også var det oprindelige navn på gruppen. Dette gør de ved at klassificere PHP-FIG’s arbejde som “Moderne PHP” i deres bøger, på deres hjemmesider, blog-indlæg, fora, osv., og ved at klassificere andre måder som værende bagud.

Et af problemerne med PHP-FIG er at selvom mange frameworks og Open Source projekter har vedtaget flere af deres standarder, så beskæftiger disse standarder sig primært med problemer fra et “framework perspektiv”, hvilket gør dem temmelig ubrugelige i industriens virkelige liv.

Mange mennesker udvikler software til industrien der skal være yderst effektiv, sikker og omkostningseffektiv. Software som kunderne er villige til at købe og bruge. De kan ikke blive generet med standarder der skal være i overensstemmelse med de behov framework fanatikere stiller. Hvis de forsøgte ville det være en katastrofe for erhvervslivet.

Hvis der er behov for at oprette en slags standardgruppe, skal denne afspejle interesser i hele PHP samfundet, ikke kun framework og Open Source CMS projektudviklere. Den skal repræsenteres af udviklerne af PHP programmeringssproget selv, og den skal være repræsenteret af et meget større medlemskab med stemmeret.

Hvis du vælger at adoptere de standarder, der er udviklet af PHP-FIG, er du nødt til at forstå at nogle af disse standarder - såsom autoloader standarderne PSR-0 og PSR-4, og flere andre standarder - har en direkte indvirkning på hvordan du koder din software.

Mange virksomheder kræver meget skalerbar, run-time kritisk og omkostningseffektiv software, der simpelthen ikke kan udvikles ved hjælp af disse standarder fra PHP-FIG.

Den forkerte måde: At følge PHP-FIG religiøst. Thumbs down

At forsømme sikkerhed

Problemet med programmører er at du kan aldrig vide hvad en programmør laver før det er for sent.

Seymour Cray

Sikker kodning er den praksis at skrive programmer der er modstandsdygtige overfor angreb af ondsindede eller drillesyge mennesker eller andre programmer. Sikker kodning hjælper med at beskytte data imod tyveri eller korruption. Derudover kan et usikkert program give adgang til at en angriber kan tage kontrol over en server eller en brugers identitet, og det kan resultere i alt fra et “denial of service” mod en enkelt bruger til at hemmeligheder kompromitteres, services forsvinder, eller flere tusinde brugere får skade på deres systemer.

Ethvert computerprogram er et potentielt mål for et sikkerhedsangreb. Angribere vil forsøge at finde sikkerhedsfejl i dine applikationer. De vil så forsøge at udnytte disse sikkerhedsfejl til at stjæle hemmeligheder, ødelægge programmer og data, og opnå kontrol over servere og netværk. Dine kunders ejendom og dit rygte er på spild.

Sikkerhed er ikke noget der kan tilføjes til software!

En usikker applikation kan kræve omfattende redesign for at sikre den. Du er nød til at identificerer naturen af de trusler din software står overfor, og så inkorporere sikker kodning fra begyndelsen og igennem hele planlægningen og udviklingen af din applikation.

Det at sikre software ressourcer er blevet mere vigtigt end nogensinde da fokus fra angriberne stødt har bevæget til imod applikationslaget. En 2009 SANS undersøgelse fandt at angreb imod webapplikationer udgør mere end 60% af den samlede mængde af angreb observeret på internettet.

PHP er usædvanlig i at det både er et programmeringssprog og et web-framework på samme tid. Dette betyder at PHP har en stor del indbygget funktionalitet i sproget der gør det meget let at skrive usikker kode.

Sikker som standard

Kompleksitet dræber. Det suger livet ud af udviklere, det gør produkter vanskelige at planlægge, bygge og teste, det medfører sikkerhedsmæssige udfordringer, og det forårsager frustrationer for slutbrugeren og administratoren.

Ray Ozzie

For at applikationer skal designes og implementeres med sikkerhedskrav der er i orden, skal sikre kodningsprocedurer og fokus på sikkerhedsrisiko integreres i dag-til-dags operationer, tanker, og i selve udviklingsprocessen.

Generelt er det meget billigere at bygge sikkert software end det er at rette sikkerhedsfejl efter at et stykke software er blevet færdiggjort, for ikke at tale om omkostningerne forbundet med et sikkerhedsbrist.

Den forkerte måde: At man ikke udvikler sikker software som standard. Thumbs down

Spørgsmål og svar

Det er nemt at misforstå et skriftligt dokument så lad os præcisere nogle spørgsmål.

Spørgsmål: Hvad er pointen med denne hjemmeside? Og hvorfor den konfronterende tilgang?

Svar: Formålet er at skabe diskussion og overvejelse om den nuværende praksis og de ekstreme synspunkter.

Spørgsmål: Siger du at objektorienteret programmering er dårligt eller forkert?

Svar: Nej, selvfølgelig ikke! Vi siger at det at man altid tænker i, og altid kun bruger det objektorienterede paradigme til at løse problemer er dårligt. Når du tænker i sort og hvidt kun, det er forkert.

Selv indenfor en enkelt applikation eksisterer der forskellige problemer. Et multi-paradigme er nogle gange den bedste løsning, det hele afhænger af det problem du forsøger at løse.

Når du stopfodre et specifikt problem til en uegnet løsning sker der dårlige ting.

Spørgsmål: Siger du at at alle frameworks er dårlige?

svar: Vi forsøger ikke at dømme specifikke frameworks. Vi behandler emnet om altid at bruge et framework ovenpå PHP.

Spørgsmål: Hvis et framework kan få mig hurtigt op og køre, hvorfor er det så dårligt?

Hvis du har analyseret situationen og de langsigtede konsekvenser, og du derefter kan se at det “at få det op at køre hurtigt”, er det eneste problem du nogensinde bliver nød til at beskæftige dig med, så er det ikke dårligt, men så beskæftiger vi os næppe med programmering eller softwareudvikling, så har vi at gøre det meste med peg-og-klik løsninger.

At komme op og køre hurtigt er ikke software design, det betyder for det mester, at du ikke har analyseret det problem, du står over for, og at du ikke har forstået de langsigtede konsekvenser af dit valg.

Spørgsmål:? Siger du at tredjeparts pakker er dårlige?

Svar: Nej, vi er fremmer brugen af ​​tredjeparts biblioteker. Kode som du nemt kan integrere i dine egne projekter uden at håndhæve eventuelle begrænsninger eller restriktioner overhovedet. Sådanne er fantastiske!

Q: Hvem er du?

A: Denne hjemmeside handler om ideer og om at bekæmpe ekstremisme i PHP samfundet, den handler ikke om personlig berømmelse eller genkendelse. Offentliggørelse af navne vil kun flytte opmærksomheden væk fra de problemer som hjemmesiden behandler til de mennesker der behandler dem. Bare hold dig fokuseret på ideerne.

Q: Hvad er din erfaring med softwareudvikling?

A: Ideerne, tankerne og konklusionerne der udtrykkes på denne hjemmeside, kræver ikke megen erfaring at komme frem til hvis du blot holder fokus på hovedtemaet, hvilket er at man altid gør én bestemt ting, fordi andre mennesker siger, at man skal.

Anbefalet læsning

PHP The Wrong Way on Hacker News

Why bad scientific code beats code following “best practices”

How to program without OOP

Coders at work - Reflections on the Craft of Programming

The traits of a proficient programmer

OWASP Secure Coding Guidelines

Security by Design Principles

Survive The Deep End: PHP Security

Refactoring Improving the Design of Existing Code

The Practice of Programming

The pragmatic programmer

Understanding programming languages

Hvordan du kan hjælpe

Bidrag på GitHub.