Yksinkertaisesti WordPress-pohjaisen koodin muokkaaminen uudelleen

Vuonna 2011 luin paljon vanhan koodin, koodin laadun ja uudelleenmuodostuksen parissa työskentelemisestä.

Martin Fowlerin (joka kirjaimellisesti kirjoitti kirjan refaktoroinnista) lainaus, joka johtuu Bob -sedästä, on jäänyt minuun – ja olen varma, että monet, monet ohjelmoijat – siitä lähtien:

Jätä koodi aina paremmassa kunnossa kuin löysit sen

Asia tässä nimenomaisessa ajatuksessa on se, että mielestäni se saattaa kuulostaa hieman idealistisemmalta, kunnes alat todella yrittää harjoittaa sitä kaikessa mitä teet.

Eli jos otat sen nimellisarvolla, se kuulostaa siltä, ​​että milloin tahansa sinun täytyy työskennellä koodikannan parissa, sinun on jätettävä koko koodikanta paremmaksi kuin silloin, kun löysit sen. Mutta mitä enemmän olen yrittänyt soveltaa tätä sääntöä päivittäisessä työssäni, sitä käytännöllisempää, puhtaampaa ja ylläpidettävämpää WordPress-kohtainen koodi on tullut.

Joten mitä tulee WordPress-pohjaisen koodin muokkaamiseen, miltä se näyttää?

Tästä ei tule pitkä postaus. Sen sijaan aion vain jakaa muutaman luettelokohdan, joita noudatan, kun käsittelen koodia, jonka olen aiemmin kirjoittanut, jonka olen kohdannut muilta tai joka on peräisin koodikannasta, jota olen työskennellyt muiden kanssa mennyt.

Ei tietyssä järjestyksessä:

• Älä ole idealisti; Ole käytännöllinen. Koko koodikannan refaktorointi ei ole käytäntöä, varsinkin jos koodikanta ei ole kääritty yksikkötesteihin. Katso käsittelemääsi koodia ja katso, mitä pieniä muutoksia voit tehdä parantaaksesi sitä.
• Käytä uusimpia standardeja. Sinun ei tarvitse perustaa kokonaan uutta kehitysympäristöä vanhemmalle koodille. Varmista sen sijaan, että sinulla on hyvät koodinhauskijat paikallaan. Jos olet siirtynyt WordPressin koodausstandardeista PSR:ään, katso haistelijoiden antamat varoitukset tai huomautukset ja yritä päivittää vain kyseisessä tiedostossa (tai tiedostojoukossa) oleva koodi.
• Kirjoita aputoiminnot. Jos toimintosi ovat liian pitkiä, etsi tapoja helpottaa niiden käyttöä. Päivitä ensin kaikki ohjausrakenteet, kuten silmukat tai ehdolliset, ja kirjoita sitten aputoimintoja, jotta ne on helpompi lukea.
• Lisää testejä (jos mahdollista). Jos sinulla on jo yksikkötestauskehys, lisää testit uudelle koodillesi. Jos sinulla ei ole aikaa tai puitteita, älä hikoile sitä. Niin paljon kuin pragmaattiset ohjelmoijat saarnaavatkin, ei aina ole aikaa lisätä testejä. (Tämä ei tarkoita sitä, että ne eivät olisi hyödyllisiä tai ettei niitä pitäisi sisällyttää mukaan, mutta että niitä ei aina ole käytännöllistä sisällyttää milloin tahansa).

Jotkut asiat, joita olen huomannut tekeväni viimeaikaisissa projekteissa, sisältävät myös yksinkertaisia ​​asioita:

• muuttujien ja funktioiden nimien päivittäminen PSR:n mukaan,
• vaihtaa sarkaimet välilyönneiksi,
• aputoimintojen lisääminen ehtojen ja silmukoiden luettavuuden parantamiseksi,
• luokkien jakaminen, jotta heillä olisi korkeampi yhteenkuuluvuus,
• parantaa kunkin toiminnon dokumenttilohkoja

Nämä ovat vain muutamia esimerkkejä, eikä tämä selvästikään ole tyhjentävä luettelo. Mutta siitä ei ole kysymys. Sen sijaan haluan yksinkertaisesti kertoa, kuinka voit käyttää WordPress-pohjaisen koodin uudelleenmuodostusta samalla kun saat päivittäisen työsi tehtyä hallittavalla tavalla.

Kaikki edellä mainitut muutokset tai suositukset ovat asioita, jotka voidaan yleensä tehdä IDE:n avulla, muutamalla pikanäppäimellä ja ehkä puolen tunnin lisäajalla (ja olen vapaa tämän arvion kanssa).

Joten ei, sinun ei tarvitse kirjoittaa uudelleen koko koodikantaa. En edes tiedä, onko se käytännön tavoite, johon tähdätä. Mutta voitko korjata yhden pienen palan koko järjestelmästä, josta olet vastuussa?

Ja miksi ei ainakaan pyritä siihen?