Refactoring WordPress Plugins: Ett litet exempel
Ett av sätten som WordPress-plugins blir till är att de, åtminstone i mitt fall, börjar som en samling funktioner som används för att hjälpa till med ett visst syfte för ett givet projekt. Därifrån tänker du "Hej, kanske någon annan kommer att ha nytta av det här."
Det har åtminstone varit min erfarenhet oftare än inte.
Men grejen är att innan du släpper den för andra att prova, vill du gå igenom processen att rensa upp koden. Jag pratar inte heller om att omstrukturera WordPress-plugins – åtminstone inte ännu.
Jag pratar om att ta koden, ta upp den till något som kommer att fungera som ett WordPress-plugin, och sedan eventuellt omfaktorisera koden.
Refaktorering av WordPress-plugins
Att gå igenom hela processen med att omstrukturera WordPress-plugin-program – än mindre ett enda WordPress-plugin – kan vara svårt, men att dela med sig av hur man refaktorerar en del av ett plugin är något som är genomförbart.
Så jag kommer att använda ett exempel på hur jag använde något nyligen (med koden abstraherad lite för att inte bry mig om att bli specifik om ett givet projekt).
Kartlägga den idealiska produktionen av alternativ.
Innan jag gör det tror jag dock att det är viktigt att dela min process kan skilja sig – eller sannolikt – skilja sig från din (eftersom många av oss har olika processer).
- Designa komponenten (ja, inte ens hela plugin-programmet) i en anteckningsbok,
- Kom med en checklista över användningsfallen där den ska passera och när den ska misslyckas,
- Skriv ut vilken data som behövs, hur den behövs och när den ska ignoreras
- Konvertera allt ovan till kod.
Naturligtvis konverterar jag inte allt bokstavligen till kod, men du fattar. Det kanske mest kortfattade sättet att uttrycka det är så här:
- Börja med en lång metod som passar perfekt. Refaktorera sedan den koden så att funktionerna blir mindre och ta hänsyn till fall där resultatet skulle misslyckas.
Så med det sagt, så här kan koden se ut.
1 Att skriva för den perfekta användningen
I det här exemplet är det idealiska användningsfallet när användaren laddar alternativen, alternativen finns och sedan måste de utföra en åtgärd om alternativen har vissa värden.
Den här delen bör vara lätt att läsa, men den tar inte hänsyn till något annat än den ideala vägen genom koden.
2 Bli lite defensiv
Därefter vill jag se till att alternativen är inställda innan jag försöker läsa dem. I vissa fall kanske du vill visa ett meddelande, skicka ett undantag eller logga information.
I det här exemplet ska jag bara återkomma eftersom det är lätt att läsa och lättast kan anpassas för din användning.
Så det hanterar alternativen, men hur är det när alternativen är inställda men inte har de värden vi förväntar oss? Det betyder att vi också måste verifiera att de gör det. Och om inte, ignorera dem, returnera, logga ett fel, kasta ett undantag och så vidare.
Du vet: Samma sak som ovan. Förutom att i det här fallet kommer jag inte att vidta några åtgärder om inte koden har den perfekta informationen.
3 Bli lite lång
Vid det här laget börjar metoden bli lite lång och blir svårare att läsa. Visst, om du är en erfaren programmerare kan du hävda att "Detta är kod, det är inte engelska", men varför inte sträva efter att göra det lite lättare att följa?
Dessutom gör det det lite lättare att testa. Men det ligger utanför ramen för detta inlägg. Ta alternativutvärderingen som det första exemplet på koden.
- Detta är något som kan lindas in i sin funktion som inte bara isolerar denna kontroll utan också gör det resulterande samtalet lite lättare.
- Ta sedan det andra kodblocket som letar efter de idealiska alternativvärdena. Detta kan också abstraheras av samma skäl ovan.
- Och slutligen, ställ in en funktion för att se till att de förväntade värdena är inställda för vart och ett av värdena som anges :
Så nu har du två mindre metoder som kapslar in samma kontroll som du gjorde.
4 Slutfunktionen
Vid det här laget är den slutliga funktionen mycket lättare att läsa eftersom den har två hjälpfunktioner som kapslar in deras ansvar medan den här är tillbaka till att utvärdera den ideala vägen genom koden:
Det räcker med att säga att när det kommer till att omstrukturera WordPress-plugins är detta bara ett exempel på hur man gör bara ett segment av det. Men det är en början, eller hur?
Hela plugins?
Eller hur? Att omstrukturera WordPress-plugins är inget skämt. Men om du börjar med små funktioner som denna och gradvis arbetar dig runt kodbasen blir det lättare.
Och om du lägger ner tid på att planera projektet från början kan det spara mycket tid på att gå tillbaka och omstrukturera den här typen av saker.