Alvorens te lezen, toch volgende mededelingen:
- Alle ergernissen hieronder beschreven zijn mijn personlijke ergernissen en niet die van mijn werkgever.
- Ik viseer niemand, mensen die zich toch zouden aangesproken voelen beschikken blijkbaar over voldoende zelfkennis.
- Ik vind mezelf verre van perfect of alwetend, maar met de doorheen de jaren verworven kennis tracht ik toch het beste van mezelf te geven bij het realiseren van projecten
In mijn vorige post had ik het redelijk beknopt over de frontend ergernissen, maar laat ons vooral het geblunder van sommige backend developers niet vergeten. Frontend en backend zijn een tandem, 2 mensen die perfect moeten samenwerken en weten wat er waar moet gebeuren. Een site mag nog überclean gelayout zijn, met kraaknette w3 valide xhtml / css geschreven zijn, fancy javascript effectjes bevatten de grote dooddoener blijft SNELHEID.
Snelheid is dikwijls al de grootste fout bij vele developers. Soms werkt hun site traag, en meestal wordt de oorzaak geweten aan de “trage webserver”, bijgevolg worden klanten de kosten ingejaagd om zwaar te investeren in een energievretende killerserver die pagina’s serveert aan de luttele 5 bezoekers per dag.
Er kunnen verschillende oorzaken zijn, soms 1, mss 2, en soms is het helemaal in orde gedaan en zijn er 1001 zaken die van een slick site een lomp geheel maken.
Laat ons beginnen bij de basis, zijnde de database… Laat ons even de manual ter hand nemen. (Backend developers die nu mijn site verlaten, er bestaan wel degelijk manuals, en néén, deze zijn niet geschreven voor uw buurvrouw die weleens een stap op het wereldwijde web wil wagen, manuals zijn geschreven voor iedereen, en wél in het bijzonder voor diegene die zich goed genoeg achten om het zonder te kunnen.) Een goede database is genormaliseerd, beschikt indien nodig over de juiste relaties / tussentabellen en heeft vooral velden die geoptimaliseerd zijn voor de inhoud. Ok, je kan al je data opslaan in varchars, text of BLOB velden, dan heb je “plaats genoeg”, maar dan verlies je het doel van je database uit het oog.
De juiste velden gebruik je om:
- de juiste data te kunnen uitlezen en op QUERY niveau te kunnen filteren (datums selecteren op MONTH, etc…)
- de juiste data te kunnen inserten en laten valideren op DATABASE niveau
Als voorgaande punten al goed zitten, petje af, een bank vooruit en een kus van de juf! Op naar de volgende vaak voorkomen fout, zijnde te véél queries. Data selecteren is 1 ding, maar data filteren, grouperen en sorteren gebeurt op database niveau. Zaken als DISTINCT, GROUP BY, ORDER BY, ASC, DESC, JOIN, INNER JOIN, OUTER JOIN, … zijn geen fancy sql commando’s. Maar al te vaak wordt data uitgelezen, in een array gepompt om die op zijn beurt te sorteren / filteren, door te loopen en per loop nogmaals een query afvuren, performantie troef. Mensen die dit doen zouden moeten verplicht worden om enkel genoeg benzine in hun tank te doen tot aan het volgende tankstation, zodat ze mss het concept snappen. De pipeline tussen de webserver en database server is klein, zeer klein. Zorg er dus voor dat je niet méér dan de benodigde data terugkrijgt. Net zoals schoenen kopen weet je ook welke maat je nodig hebt (of mss 2 maten), welke kleur, mannen of vrouwenschoenen, etc… De verkoper alle schoenen laten aanrukken én ze vervolgens 1 voor 1 passen zou een beetje overhead zijn, niet? (voor sommige vrouwelijke lezers, ik veroordeel je niet als je de voorgaande stelling niet snapt). Voor diegene die Roger van Dobbit magazine kennen, vergeet zijn wekelijkse stelling. “Wat je zelf doet, doe je beter” klopt voor geen vliegende meter als het op databases aankomt.
Voor de betweters die bovenstaande stellingen zouden benchmarken, ga uw gang. Een vertraging van 0,2 ms is niet veel voor 1 record, maar wat bij 10.000 records?
Het programmeren op zich kan nog op 1001 vlakken fout gaan, teveel om op te noemen. Misschien volgende zaken toch in het achterhoofd houden:
- Object Oriented programmeren is vandaag de dag HOT, het maakte zijn opmars begin de jaren 90 maar het principe bestaat al van in de jaren 60. Het is niet omdat je volgens OO programmeert dat je een kickass developer bent. Bekijk OO design patterns, snap alle principen (inheritence, abstraction, encapsulation, polymorphism, decoupling)…
- Frameworks zijn geschreven om het leven te vergemakkelijken, gebruik ze dan ook indien mogelijk.
wordt vervolgd