2011 aastal lugesin ma palju pärandkoodiga töötamise, koodikvaliteedi ja ümbertegemise kohta.
Onu Bobile omistatud Martin Fowleri tsitaat (kes kirjutas sõna otseses mõttes ümbertöötlemise kohta) on mulle – ja ma olen kindel, et paljud programmeerijad – sellest ajast peale kinni jäänud:
jätke kood maha alati paremas olekus, kui selle leidsite
Selle konkreetse ideega on see, et ma arvan, et see võib tunduda veidi idealistlikum, kuni hakkate seda kõike oma tegevuses harjutama.
See tähendab, et kui võtta seda nimiväärtusega, siis tundub, et kui teil on vaja koodibaasi kallal töötada, peate jätma kogu koodibaasi paremaks kui selle leidmisel. Kuid mida rohkem olen püüdnud seda reeglit oma igapäevatöös rakendada, seda praktilisemaks, puhtamaks ja hooldatavamaks on muutunud WordPressispetsiifiline kood.
Kuidas see siis välja näeb, kui rääkida WordPressi-põhise koodi ümbertöötamisest?
Sellest ei tule pikka postitust. Selle asemel jagan lihtsalt mõnda punkti, mida järgin, kui töötan koodi kallal, mille olen varem kirjutanud, mida ma kohtan teistelt või mis pärineb koodibaasist, mille kallal olen teistega koos töötanud. minevik.
Mitte mingis kindlas järjekorras:
- Ära ole idealistlik; Ole praktiline. Terve koodibaasi ümbertöötamine ei ole tavapärane, eriti kui koodibaasi ei kasutata ühikutestidesse. Vaadake koodi, mille kallal töötate, ja vaadake, milliseid väiksemaid muudatusi saate selle täiustamiseks teha.
- Kasutage uusimaid standardeid. Te ei pea vanema koodi jaoks täiesti uut arenduskeskkonda seadistama. Selle asemel veenduge, et teil oleks paigas head koodinuusutajad. Kui olete WordPressi kodeerimisstandarditelt üle läinud PSR-ile, vaadake hoiatusi või märkusi, mida nuusutajad viskavad, ja proovige värskendada just selles failis (või failide komplektis) olevat koodi.
- Kirjutage abifunktsioonid. Kui teie funktsioonid on liiga pikad, otsige võimalusi nende töö hõlbustamiseks. Esmalt värskendage mis tahes juhtimisstruktuure, nagu tsüklid või tingimuslikud tingimused, ja seejärel kirjutage abifunktsioonid, et neid oleks lihtsam lugeda.
- Lisage teste (kui võimalik). Kui teil on juba üksuse testimise raamistik, lisage oma uue koodi testid. Kui teil pole aega või raamistikku, ärge pingutage. Nii palju kui pragmaatilised programmeerijad seda jutlustavad, pole alati aega testide lisamiseks. (See ei ole väide, et need ei ole kasulikud või ei peaks olema kaasatud, vaid et alati ei ole otstarbekas neid igal ajahetkel lisada).
Mõned asjad, mida olen viimaste projektide käigus avastanud, hõlmavad ka lihtsaid asju:
- muutujate ja funktsioonide nimede värskendamine PSR-i järgimiseks,
- vahekaartide vahetamine tühikuteks,
- abifunktsioonide lisamine, et muuta tingimused ja tsüklid loetavamaks,
- klasside jagamine, et neil oleks suurem ühtekuuluvus,
- parandada iga funktsiooni dokumendiplokke
Need on vaid mõned näited ja see ei ole ilmselgelt ammendav loetelu. Aga see pole asja mõte. Selle asemel soovin lihtsalt jagada, kuidas saate rakendada WordPressi-põhise koodi ümberkujundamist, tehes samal ajal oma igapäevast tööd juhitaval viisil.
Kõik ülaltoodud muudatused või soovitused on asjad, mida saab tavaliselt teha IDE abiga, mõne otsetee ja võib-olla pooletunnise lisaajaga (ja ma olen selle hinnanguga liberaalne).
Seega ei, sa ei pea tervet koodibaasi ümber kirjutama. Ma isegi ei tea, kas see on praktiline eesmärk, mida sihtida. Kuid kas saate parandada ühe väikese osa üldisest süsteemist, mille eest vastutate?
Ja miks mitte vähemalt see eesmärk olla?