Att ärva WordPress-projekt: Tips för utveckling

Om du driver ett företag som fokuserar både på att utveckla lösningar från grunden eller som fokuserar på att implementera en skräddarsydd lösning i samband med redan existerande projekt (eller kanske båda), så har du sannolikt – någon gång – varit i situationen att ärva WordPress-projekt.

Att tackla projekt från båda handtagen medför sina utmaningar – de flesta välkomna – men det verkar vara mycket vanligare för människor att klaga på att arbeta med en redan existerande kodbas.

Det är inte så att jag inte får den känslan, men jag tror att det finns en grad av omogenhet i att göra det. Å ena sidan, ja vissa kodbaser är direkt hemska. Men vissa kodbaser är inte så illa. Jag skulle faktiskt hävda att de bara skiljer sig lite från hur du skulle utveckla det.

Det här är ett fall där standarder spelar in, men jag avviker från detta för tillfället.

Så låt oss säga att du ärver WordPress-projekt och att du inte är särskilt sugen på kodbasen som du arbetar med. Hur kommer det sig att du fortfarande kan njuta av det arbete du gör utan att känna att du behöver kritisera varje aspekt av vad det än är som du har att göra med?

Ärver WordPress-projekt

För det första är denna föreställning om att klaga på andra människors arbete det ökända vattnet som jag inte gillar att trampa i.

• Jag vet inte bakgrunden som ledde till att kodbasen var i sitt tillstånd,
• Jag vet inte varför vissa saker utvecklades som de var (tidsbrist, bristande förtrogenhet med ett projekt, etc.),
• Jag har i uppdrag att göra något inom ramen för projektet så varför lägga tid på att fokusera på saker som inte är en del av mitt ansvar?

Jag förstår: Det finns tillfällen då vi koder vi skriver måste kommunicera med kod som redan finns. Och det kan vara svårt. Det finns designmönster som inte är specifikt för den här situationen.

Men istället för att täcka det tänkte jag dela med mig av tre saker som jag tycker visar mognad när det kommer till utveckling när man ärver WordPress-projekt som kan irritera oss.

1 Refaktorera inte allt

Som Martin Fowler sa:

Denna opportunistiska refaktorering hänvisas av farbror Bob till att följa pojk-scoutregeln – lämna alltid koden bakom dig i ett bättre skick än du hittade den.

Generellt sett gillar jag den här regeln, men beroende på projektets krav kan detta vara utanför vårt ansvarsområde.

Så varje gång vi stöter på något som vi vet behöver omstruktureras men projektet löper smidigt. Om du gör en ändring av något för att du tror att det måste göras, vet du inte hur detta kommer att falla igenom hela projektet.

Om du har tid att göra en fullständig revision av koden är det en sak, men om inte, då är din uppgift att presentera vad du har gått med på att göra.

2 Fokusera på vad du gick med på att göra

Och det leder till den här punkten: När du ärver WordPress-projekt får du en viss mängd arbete och inget mer (det är därför vi har en arbetsbeskrivning, eller hur?).

Så trots hur mycket du än vill förändra miljön du befinner dig i, gör det inte. Fokusera på vad du kan göra, vad bara du kan göra och vad du har gått med på att göra.

Jag tycker att det är bra att ta anteckningar om problem, och jag tror att detta till och med kan vara fördelaktigt (och jag ska prata om detta för en stund), men tappa inte fokus på vad du gick med på att göra. Att göra allt annat än är oprofessionellt.

3 Döm inte den tidigare utvecklaren

En annan sak som är vanligt – särskilt i öppen källkod – är att bedöma utvecklaren som skrev den första uppsättningen kod som du arbetar med.

Vad är detta? Jag skulle aldrig skriva det så.

Jag menar hur många gånger har vi tänkt så för oss själva? Men vi vet inte i vilken tid, begränsningar, erfarenhet eller sammanhang som utvecklaren arbetade i.

Koden vi släpper är inte nödvändigtvis representativ för vår kompetensnivå. Det dikteras ofta av tredjepartsvariabler som har inflytande över hur vi implementerar en lösning.

Och vi vet hur det är, eller hur? Hur många gånger har vi velat göra något på ett sätt men begränsningarna och schemat som vi arbetar under dikterar vad vi gör?

Så varför skulle vi förvänta oss att dessa utvecklare skulle vara annorlunda?

Valfritt: Erbjud framtida support

Som nämnts tidigare, om du stöter på områden i kodbasen som är problematiska, betyder det inte att det är en förlorad sak.

Istället, när du stöter på den typen av problem, då tror jag att det är en bra idé att:

• gör anteckningar om det du har sett,
• kommentera vad du skulle göra för att fixa det och varför,
• prata med kunden om vad du har sett och fördelarna med att uppdatera det.

Detta leder uppenbarligen till framtida arbete, men kanske ovanför det låter det dig erbjuda lösningar för att skapa bättre, mer välarbetad programvara och det låter dig se till att du gör internet till en bättre plats för ett CMS som är så populärt.

Nej, det här arbetet är aldrig garanterat, men det är till hjälp.

Jag är säker på att det finns mer

Det här är bara tre tips som jag erbjuder baserat på den erfarenhet jag har när jag ärver WordPress-projekt. Det är inte menat att vara allomfattande.

Istället är det tänkt att ge några tips som gör att du kan ta mer hänsyn till andra människors arbete i förhållande till ditt arbete, att tänka tydligare på vad du kan göra när du ställs inför liknande situationer och att få mer arbete genom att förbättra det befintliga lösning potentiellt.

Men jag vet att de saker jag har nämnt bara är några av mina observationer. Har du din egen? Nämn dem i kommentarerna.