Refaktorerar helt enkelt WordPress-baserad kod
Redan 2011 läste jag mycket om att arbeta med äldre kod, kodkvalitet och refaktorering.
Det finns ett citat av Martin Fowler (som bokstavligen skrev boken om refactoring) som tillskrivs farbror Bob som har fastnat för mig – och jag är säker på att många, många programmerare – sedan dess:
lämna alltid koden bakom dig i ett bättre skick än du hittade den
Grejen med just den här idén är att jag tror att det kanske låter lite mer idealistiskt tills du verkligen börjar försöka praktisera den i allt du gör.
Det vill säga, om du tar det till nominellt värde låter det som när du behöver arbeta på en kodbas, då måste du lämna hela kodbasen bättre än när du hittade den. Men ju mer jag har försökt tillämpa denna regel i mitt dagliga arbete, desto mer praktisk, desto renare och mer underhållbar har WordPress-specifik kod blivit.
Så när det gäller att omfaktorisera WordPress-baserad kod, hur ser det ut?
Det här kommer inte att bli ett långt inlägg. Istället kommer jag helt enkelt att dela med mig av några punkter som jag följer när det gäller att arbeta med kod som jag tidigare har skrivit, som jag stöter på från andra, eller som är från en kodbas som jag har arbetat på med andra i dåtid.
I ingen bestämd ordning:
- Var inte idealistisk; Var praktisk. Att omfaktorisera en hel kodbas är inte något som är praxis, särskilt om kodbasen inte är insvept i enhetstester. Titta på koden du arbetar med och se vilka mindre ändringar du kan göra för att förbättra den.
- Använd de senaste standarderna. Du behöver inte ställa in en helt ny utvecklingsmiljö för äldre kod. Se istället till att du har bra kodsniffer på plats. Om du har gått från WordPress Coding Standards till PSR, titta på varningarna eller meddelandena som sniffarna kastar och försöker uppdatera koden bara i den filen (eller uppsättningen filer).
- Skrivhjälpfunktioner. Om dina funktioner är för långa, leta efter sätt att göra dem lättare att arbeta med. Uppdatera först eventuella kontrollstrukturer som loopar eller villkor, skriv sedan hjälpfunktioner för att göra dem lättare att läsa.
- Lägg till tester (när det är möjligt). Om du redan har ett ramverk för enhetstestning, lägg till tester för din nya kod. Om du inte har tid eller inte har ramarna, svettas inte. Så mycket som pragmatiska programmerare predikar det, finns det inte alltid tid att lägga till tester. (Detta ska inte vara ett påstående om att de inte är användbara eller inte bör inkluderas, men att det inte alltid är praktiskt att införliva dem vid en given tidpunkt).
Några av de saker som jag har funnit mig göra i de senaste projekten inkluderar enkla saker också:
- uppdatera variabel- och funktionsnamn för att följa PSR,
- ändra flikar till blanksteg,
- lägga till hjälpfunktioner för att göra villkor och loopar mer läsbara,
- dela upp klasser för att de har en högre grad av sammanhållning,
- förbättra docblocken för varje funktion
Detta är bara några av exemplen och detta är uppenbarligen inte en uttömmande lista. Men det är inte meningen. Istället vill jag helt enkelt dela med dig av hur du kan tillämpa refaktorerande WordPress-baserad kod samtidigt som du får ditt dagliga arbete gjort på ett hanterbart sätt.
Alla ovanstående ändringar eller rekommendationer är saker som vanligtvis kan göras med hjälp av IDE, några genvägar och med kanske en halvtimmes extra tid (och jag är liberal med den uppskattningen).
Så nej, du behöver inte skriva om en hel kodbas. Jag vet inte ens om det är ett praktiskt mål att sikta på. Men du kan fixa en liten bit av det övergripande systemet som du är ansvarig för?
Och varför inte åtminstone sikta på det?