✅ WEB- och WordPress -nyheter, teman, plugins. Här delar vi tips och bästa webbplatslösningar.

Utveckla inte utvecklingstunnelvision

5

I tidigare inlägg har jag pratat om tanken att fokusera på ett område och gå på djupet snarare än brett. Detta är naturligtvis personliga preferenser, men det är ändå mitt.

Under det senaste året är dock en av biprodukterna som jag har hittat ju längre du stannar i en viss bransch, desto vanligare blir vissa problem. (Detta borde inte komma som en överraskning eftersom det är just därför vi har designmönster .)

Men grejen med att göra det här är att man utvecklar ett slags tunnelseende för sätt att lösa problem.

Krediter

Exempel: Nyligen fick jag i uppdrag att behöva utveckla någon funktionalitet som skulle analysera uppmärkning och konvertera den till ett lite annorlunda format.

Utvecklingstunnelvision

Jag har gjort detta gång på gång och jag har ofta funnit [DOMDocument](https://www.php.net/manual/en/class.domdocument.php)att det är ett av de mest användbara verktygen för att göra detta. Men det finns ett problem: jag hade blivit så van vid att använda detta att jag försummade alternativa lösningar som inte var inbyggda i WordPress, utan i PHP.

Istället för att behöva ladda hela dokumentet i en instans av [DOMDocument](https://www.php.net/manual/en/class.domdocument.php), kunde jag stränga ersättningar med – nej, inte reguljära uttryck (även om det var frestande) – men [strip_tags](https://www.php.net/manual/en/function.strip-tags.php)och [str_replace](http://php.net/manual/en/function.str-replace.php).

För att ta detta ett steg längre, är detta något som påpekades av en välrenommerad kollega under en kodgranskning.

Om kodrecensioner, igen

Jag har också ägnat tidigare inlägg åt att prata om kodrecensioner, varför jag tycker att de är viktiga, hur man hanterar dem och hur man undviker att hålla fast vid dem.

Men det var en trevlig påminnelse att upptäcka att även när du tror att du är van att lösa ett vanligt problem i en given situation, kan det fortfarande finnas ett annat, ett renare och/eller ett bättre sätt att göra det på.

Min poäng är att oavsett vilken sida av kodgranskningen du befinner dig på och hur länge du än har gjort vad det än är som du gör, avfärda inte en kritik eftersom den är annorlunda.

Om något, det hindrar dig från att utveckla utvecklingstunnelseende; det gör att du kan tänka bredare om ett problem oavsett hur ofta du har löst det.

Inspelningskälla: tommcfarlin.com

Denna webbplats använder cookies för att förbättra din upplevelse. Vi antar att du är ok med detta, men du kan välja bort det om du vill. Jag accepterar Fler detaljer