Sikta på att dela upp program i mindre komponenter
En av de saker som programmerare ofta pratar om är viljan att dela upp program i mindre komponenter, eller funktioner, så att det blir lättare att spåra, lättare att läsa och lättare att felsöka.
Men det är inte så ovanligt att se monolitiska funktioner med många kodkommentarer för att förklara vad som händer i programmet.
Jag knackar inte på det här, för jag vet inte vilka begränsningar en programmerare arbetade under. Det är:
- Vilken budget hade han/hon när han/hon byggde upp programmet?
- Hur mycket tid gavs för att slutföra projektet?
- Var det många som arbetade med projektet?
- Fick programmeraren tid att skriva koden så att de kunde enhetstesta den, omstrukturera den eller bara göra den lättare att läsa?
Kort sagt, det finns många skäl – tror jag – att vi kan läsa "dålig kod", och det behöver inte alltid vara programmerarens fel (det är bara det mest naturliga vi måste kasta ut när vi läser något vi ogillar).
Betyder detta dock att vi inte ska sträva efter att omstrukturera eller skriva kod på ett sätt som gör det lättare att förstå? Självklart inte. Förutsatt att vi har tid att göra det, hur kan vi göra det?
Dela upp program i mindre komponenter
När det kommer till att skriva om ett ämne som detta, särskilt i en ekonomi som är lika aktiv som e-handel i WordPress, kan det vara en utmaning.
"Låt oss bli specifika, Bob."
Det vill säga, jag kan skriva om det på en mycket detaljerad nivå med hjälp av en uppsättning plugins, titta på data, dissekera frågor och visa hur man gör det. Eller så kan jag skriva det om det på en lite högre nivå med det yttersta målet att visa hur man delar upp program i mindre komponenter.
Eftersom det finns så många sätt att uppnå det förra, väljer jag det senare. Det vill säga, detta kommer inte nödvändigtvis att använda några specifika plugins utan direkta frågor. Den kommer dock att använda exempel på hög nivå för att hjälpa dig gå igenom vad som kan vara en serie frågor och loopar och dela upp dem i mindre funktioner.
Ett allmänt exempel
Till exempel, låt oss säga att jag arbetar på en funktion i ett WordPress-plugin som är det yttersta syftet med är att hämta alla de olika betalningsmetoderna som en användare har lagrat och som är relaterade till deras konto.
Utmaningen är att denna information är spridd över flera databastabeller (på grund av olika plugins som används) så det finns några frågor som måste köras och sedan hämtas.
Stegen för att göra sådana frågor kan se ut ungefär så här:
- få den nuvarande användarens kund-ID,
- få alla order-ID-nummer för kunden
- avgöra vilka betalningsmetoder som användes för varje beställning
- hämta nämnda betalningsmetoder och sedan skicka informationen göra till kunden
Beroende på hur databasen är inställd, beroende på din SQL-kunskapsnivå, och beroende på hur de olika plugins för att hantera all ovanstående data fungerar tillsammans, kan det vara lätt att skriva en stor fråga för att hämta denna information.
Men om du har arbetat med e-handel i WordPress och olika plugins så vet du att det inte alltid är så lätt.
Istället tittar du på något som:
- vi behöver få en kunds profil från användarens metadata,
- vi måste hitta alla beställningar som användaren har gjort, och detta kan ofta associeras med inlägget eller inläggets metadatatabell,
- betalningsmetoderna kan med stor sannolikhet lagras i deras tabell som är kopplad till användaren genom någon typ av token,
- token ovan sitter i en tabell och är relaterad till en given information i en annan tabell som du sedan måste härleda genom att titta på den data som finns i hela databasen.
I slutändan måste du skapa en uppsättning frågor endast genom att först förstå hur du frågar efter den data du letar efter. Det är tillräckligt utmanande som det är. Men när du får göra det, låt oss säga att du skriver dina frågor sekventiellt och sedan använder resultaten av var och en för att komma till önskat resultat.
Detta kan resultera i något i stil med detta :
Men det behöver inte vara så här.
För det första är dessa alla oberoende frågor med oberoende uppsättningar resultat även om de måste användas tillsammans. Det betyder att vi kan bryta isär dem och utvärdera resultaten av var och en innan vi går vidare med nästa steg.
Dessutom tillåter det oss att skriva mindre, mer sammanhängande funktioner. Även om de kan bero på varandra, kan vi ställa in varje funktion för att acceptera ett argument (eller en uppsättning argument från vilka vi kan hämta all information.
Kanske kan slutresultatet se ut så här :
Naturligtvis kan jag inte visa någon faktisk SQL – ja, åtminstone inte överallt – eftersom jag inte kan den allmänna uppsättningen och inte heller vet exakt vilka plugins eller scheman det är som du arbetar med.
Men det har aldrig varit meningen med det här inlägget.
Istället är den ultimata poängen som jag försöker förmedla denna: Även om vi kanske arbetar under mycket begränsade begränsningar, kan vi fortfarande dela upp program i mindre komponenter som hjälper oss att beskriva vad som händer, förstå hur det görs och sedan skicka data fram och tillbaka mellan olika funktioner och till och från användaren.