✅ WEB- ja WordPress -uutiset, -teemat, -laajennukset. Täällä jaamme vinkkejä ja parhaita verkkosivustoratkaisuja.

WordPress-widgetit: Refaktorointi, osa 1

16

Viimeinen viesti sisälsi paljon tietoa koodinlaatutyökalujen määrittämisestä WordPress-kehitysympäristössäsi, mutta ne ovat välttämättömiä, jos aiomme tehdä paljon uudelleenkäsittelyä.

Mutta kuten mainitsin tämän viestin alussa, koodin laatutyökalujen asettaminen antaa meille ensin perustan, jota voimme käyttää kattilalevyn uudelleenmuodostamiseen (mikä meidän on selvästikin tehtävä GrumPHP:n osoittaman punaisen määrän vuoksi).

Rehellisesti sanottuna pidän näitä tarpeellisina, jos aiot tehdä kaikenlaista kehitystä, joten sinun on näytettävä, kuinka ne määritetään.

Siitä huolimatta edellinen viesti osoittaa, kuinka paljon työtä olemme tehneet meille, eikö niin?

Aloitamme nyt WordPress Widget Boilerplaten uudelleenmuodostamisesta .

Tämä ei ainoastaan ​​paranna koodin laatua, vaan myös opastaa meidät oliolähtöisten periaatteiden läpi, joita voimme soveltaa widgettejämme rakentaessamme ja joita voimme soveltaa tulevissa WordPress-kehityksessä.

WordPress Widget Boilerplate: Refactoring, osa 1

Ehkä jännittävintä minulle on saattaa tämä arkisto nykyaikaisten standardien tasolle. Jos katsot GitHubin päähaaraa tämän viestin julkaisuhetkellä (tai arkiston historiaa myöhemmin), huomaat, että se on kuusi vuotta vanha.

WordPress-widgetit: Refaktorointi, osa 1

Tämä asia on kuusi vuotta vanha (tämän viestin ajankohtana).

Se on pitkä aika Internet-vuosina, eikö?

Joka tapauksessa, aiomme tehdä joitain asioita uudelleenjärjestelytoimissamme:

  • luodaan haara, josta se toimii, ennen kuin se yhdistetään takaisin päähaaraan,
  • toteuttaa yhtenäisempi tapa järjestää tiedostot,
  • koodausstandardien päivittäminen noudattamaan sitä, mikä on enemmän linjassa PSR:n kanssa,
  • ja enemmän.

Esitän tämän nyt, koska emme todennäköisesti tule käsittelemään kaikkea tässä viestissä, mutta käsittelemme paljon. Joten tämän sanottua, aloitetaan.

1 Kehityshaaran luominen

Olettaen, että sinulla on kopio arkistosta paikallisella koneellasi, jonka sinulla pitäisi olla viimeisen viestin jälkeen, ensimmäinen asia, joka meidän on tehtävä, on luoda haara, josta voimme tehdä työmme.

Paras käytäntö on olla työskentelemättä päähaaralla. Sen sijaan isäntäkonetta tulisi aina käyttää koodin uusimman vakaan version käyttöönotossa.

Kirjoita tätä varten seuraava komento terminaaliin:

$ git checkout -b develop

Tämä luo uuden paikallisen haaratoimiston. Sitä ei ole vielä lisätty GitHubiin tai etävarastoasi (missä tahansa säilytät sitä).

Kirjoita seuraavaksi seuraava komento:

$ git push --set-upstream origin develop

Tämä työntää kehityshaaran etävarastoon asti. Kun se on tehty, sinun pitäisi pystyä näkemään kaikki muutokset, jotka toteutimme viimeisessä viestissäsi etävarastossasi.

Jos käytät GitHubia, sen pitäisi näyttää suunnilleen tältä:

WordPress-widgetit: Refaktorointi, osa 1

Jos käytät toista palvelua, sen pitäisi silti näyttää samalta. Toisin sanoen hakemistorakenteen tulee olla sama, mutta se, miltä se näyttää selaimessa, vaihtelee.

Huomautus sivuliikkeestä

Muista, että tämän haaran tarkoitus on, että teemme kaiken työmme. Tällä tavalla emme puutu päähaaraan, josta monet ihmiset vetäytyvät.

Selvyyden vuoksi, ehkä kukaan ei vetäydy tästä. Ehkä he tekevät. Tästä huolimatta tässä esitellyt käytännöt on tarkoitettu osoittamaan, kuinka projektia ajetaan käyttämällä lähteenhallinta- ja koodilaatutyökaluja, jotta voit rakentaa parempia projekteja itsellesi, yrityksellesi ja muille.

2 Järjestä tiedostot uudelleen

Ensimmäinen asia, joka meidän pitäisi tehdä, on järjestää tiedostot uudelleen, jotta ne jäljittelevät nykyaikaisempaa rakennetta. Teen parhaani perustellakseni päätökset, joita teen projektille, kun teemme tätä; voit kuitenkin vapaasti valita, miten haluat tehdä sen.

Tekemäni päätökset vaikuttavat viime kädessä ensisijaiseen kattilalevyyn. Se, mitä valitset, vaikuttaa siihen, kuinka käytät sitä päivittäisessä työssäsi tai kuinka päätät edetä projektissa kokonaisuutena.

Päivitetään hakemistoja

Yksi asioista, joita yritän tehdä, on hajottaa hakemistoni, jotta ne ovat mahdollisimman selkeitä. Tämä tarkoittaa, että yritän tehdä seuraavaa:

  • luo omaisuushakemisto JavaScriptille ja tyylitaulukoille,
  • luo src -hakemisto kaikille PHP-tiedostoille,
  • luo kielihakemisto kansainvälistymistiedostoille,
  • säilytä kaikki muut tiedostot arkiston juuressa, jotta muiden on helppo seurata mukana toimitetun README:n mukana.

Tätä varten aion ensin poistaa ja siirtää muutamia asioita. Olen yrittänyt järjestää tämän tiettyyn järjestykseen:

  1. Aion poistaa README.txt – tiedoston. Tätä tiedostoa käytetään vakiona README-mallina, jos aiot lähettää koodin WordPress Plugin Repositoryyn, mutta se ei ole välttämätön sille, mitä haluan Boilerplatelle.
  2. Nimeän plugin.php :n uudelleen muotoon Plugin .php noudattaakseni PSR-käytäntöjä.
  3. Nimeän myös langin uudelleen kieliksi.
  4. Aion luoda omaisuushakemiston ja siirtää ja sitten siirtää css- ja js – hakemistot kyseiseen hakemistoon. Luon jokaiseen näistä hakemistoista dev -alihakemiston, jossa voimme työskennellä Sass- ja vähentämättömien JavaScript-tiedostojen parissa (molemmat tulevat myöhemmin sarjassa).
  5. Sen jälkeen luon src -hakemiston ja siirrän näkemysten tyylisivun siihen hakemistoon.
  6. Nimeän myös näkymät uudelleen Viewsiksi ja kirjoitan myös sen sisältämät tiedostot isoilla kirjaimilla.
  7. Lopuksi siirrän kaiken hakemiston juureen. Tämä tarkoittaa, että widget-boilerplate katoaa ja kaikki tiedostot sijaitsevat arkiston juurihakemistossa.

Nämä ovat monta askelta, mutta ne ovat pieniä. Haluan esitellä ne ensin, jotta on selvää, mitä tämän osan loppuosan aikana tapahtuu.

Poista README

Voit tehdä tämän kirjoittamalla seuraavan komennon päätteeseen widget-boilerplate- hakemiston juuresta :

$ rm readme.txt

Tämä poistaa tiedoston. Jos kirjoitat seuraavan komennon terminaaliin:

$ git status

Sinun pitäisi nähdä jotain tämän kaltaista:

WordPress-widgetit: Refaktorointi, osa 1

Pidän siitä, että erilaiset ylös työnnettävät muutokset ovat selkeitä ja ytimekkäitä, jotta niitä on helpompi peruuttaa yksi kerrallaan. Joten mennään eteenpäin ja sitoudutaan ja työnnetään tätä muutosta.

Kirjoita seuraava:

$ git rm README.txt
$ git add. $ git commit -n -m "Removing the original README.txt template."
$ git push

Tämä käskee Gitiä poistamaan tiedoston, lisäämään yksittäisen muutoksen muutosjoukkoon, sitomaan sen suorittamatta mitään koodinlaatutyökaluja (koska meidän ei tarvitse tehdä sitä juuri nyt, muuten se epäonnistuu) ja työntää sen etätietovaraston kehityshaaraan.

Nyt kun se on tehty, mennään eteenpäin ja nimetään uudelleen joitain tiedostoja.

Tiedostojen uudelleennimeäminen

Samalla kun olemme tässä, emme aio vain nimetä uudelleen plugin .php -tiedosto, vaan myös muut PHP-tiedostot. Nämä ovat tiedostoja, jotka voidaan loogisesti ryhmitellä samaan muutosjoukkoon, joten on järkevää mennä eteenpäin ja tehdä niin.

Joten kirjoita seuraavat komennot terminaalistasi:

$ mv plugin.php Plugin.php
$ mv views/admin.php views/Admin.php
$ mv views/widget.php views/Widget.php

Tätä tehdessämme emme ole vielä tehneet mitään muutoksia tiedostoihin, joten mitään sitovaa ei ole. Jatketaan hakemistojen uudelleennimeämistä.

Luo hakemistoja; Nimeä hakemistot uudelleen

Aivan kuten teimme tiedostojen kanssa, mennään eteenpäin ja luodaan uusi omaisuushakemisto. Kirjoita terminaaliin seuraava komento:

$ mkdir assets

Seuraavaksi haluamme siirtää css- ja js – hakemistot kyseiseen hakemistoon, joten kirjoita terminaaliin myös seuraava:

$ mv css assets
$ mv js assets

Ja nimetään lang – hakemisto uudelleen Kielet kirjoittamalla seuraava komento:

$ mv lang Languages

Nimetään lopuksi näkymä uudelleen Viewsiksi:

$ mv views Views

Tässä vaiheessa olemme tehneet kaikkemme päähakemistossa olevien tiedostojen kanssa. Meidän on kuitenkin vielä valmisteltava alihakemistot esikäsitellyille resursseillemme.

Ennen kuin teet sen, on kuitenkin hyvä tapa suorittaa nopea git-tilan tarkistus nähdäksesi, mitä muutoksia voidaan lisätä. Jos arkistosi on samanlainen kuin minun, näet todennäköisesti jotain seuraavanlaista:

WordPress-widgetit: Refaktorointi, osa 1

Tässä tapauksessa mielestäni on okei lisätä kaikki yhteen muutosjoukkoon kommentilla, joka osoittaa, että olemme nimenneet uudelleen ja siirtäneet tiedostoja.

Saatat olla erimieltä, ja jos on, se on täysin ok. Sinun käskysi eroavat hieman minun, mutta tässä on mitä minulla on sitoumusta varten:

$ git add. $ git commit -n -m "Creating new directories; Renaming files."
$ git push

Siirry nyt esikäsiteltyjen tiedostojemme alihakemistoihin.

Luo alihakemistoja

Luo CSS-hakemistoon alihakemisto nimeltä dev ja tyhjä tiedosto nimeltä admin.scss ja widget.scss, sillä käsittelemme näitä tiedostoja myöhemmin sarjassa.

Lisää seuraavaksi dev -hakemisto JavaScript-hakemistoon ja lisää näihin tiedostoihin tyhjät admin.js- ja widget.js -tiedostot. Jos olet niin halukas, voit siirtää olemassa olevat tiedostot dev – hakemistoihin, koska käytämme näitä tiedostoja kehitystiedostojemme perustana.

Se on valinnainen vaihe; Olen kuitenkin mennyt eteenpäin ja tehnyt niin, koska niin haluan työskennellä. Tässä on joukko komentoja, jotka olen suorittanut.

css – hakemistosta…

$ mkdir dev
$ mv admin.css admin.scss && mv widget.css widget.scss
$ mv *.scss dev

Yllä olen luonut tyylitaulukoilleni dev – hakemiston, nimennyt ne uudelleen Sass-tiedostoiksi ja siirtänyt ne dev – hakemistoon.

Ennen kuin siirryt eteenpäin, nyt on hyvä aika tarkistaa git-tila ja tehdä muutoksia tyylitaulukoihin:

$ git add. $ git commit -n -m "Renaming and moving stylesheets into a dev directory."
$ git push

Nyt js – hakemistosta…

$ mkdir dev
$ mv *.js dev

Koska meidän ei tarvitse muuttaa liittyvien tiedostojen tiedostotyyppiä, voimme yksinkertaisesti siirtää ne uuteen hakemistoon.

Tehdään lopuksi sama asia ja katsotaan, onko olemassa muutoksia, joita voimme nostaa nopean git-tilan tarkistuksen kautta (jonka pitäisi olla). Tässä on luettelo komennoista, joita suoritin tehdäkseni muutokset ja työntäväni muutokset:

$ git add. $ git commit -n -m "Adding a JavaScript dev directory and moving the development files."
$ git push

Olemme melkein valmiita. Sinun tarvitsee vain siirtää tietyt hakemistot arkiston juureen ja nimetä ydinhakemisto uudelleen nimellä src. Joten tehdään se nyt.

Siirrä hakemistot juureen

Pohjimmiltaan meidän on siirrettävä kaikki paitsi plugin-tiedosto ja Views – hakemisto pois widget-boilerplate- hakemistosta, ja meidän on nimettävä widget-boilerplate uudelleen muotoon src.

Kuulostaa yksinkertaiselta, eikö? Se on melko suoraviivaista. Widget-boilerplate- hakemistosta :

$ mv assets .. && mv languages ..
$ cd ..
$ mv widget-boilerplate src

Sitten teen muutoksen GitHubiin seuraavasti:

$ git add. $ git commit -n -m "Reorganizing the directory structure."
$ git push

Nyt meillä on paljon nykyaikaisempi hakemistorakenne. Voit nähdä sen täällä kehityshaarassani.

Sana OOP:sta

Ja nyt, kun meillä on kaikki tämä, voimme aloittaa koodin kirjoittamisen. Mutta älä erehdy: Osa olio-ohjelmoinnista on myös olio-analyysiä ja olio-suunnittelua.

Tässä viestissä olemme pohjimmiltaan soveltaneet oliosuuntautunutta arkkitehtonista suunnittelua, joka perustuu laajennuksen yhteensopivuuden analysointiin.

Seuraava osa on kuitenkin koodin päivittäminen päästäksemme eroon kaikesta punaisuudesta, jonka olemme nähneet haistaessamme koodiamme.

Seuraavassa postauksessa

Seuraavan postauksen ensisijainen tavoite on jatkaa koodausstandardien päivittämistä, jotta olemme ratkaisseet kaikki IDE:n tai komentorivillä käyttämiemme koodinlaatutyökalujen aiheuttamat ongelmat.

Meillä pitäisi myös olla paljon puhtaampi, organisoidumpi arkisto ja olla sellaisessa asemassa, että olemme valmiita yhdistämään työmme takaisin päähaaraan.

Varmista kuitenkin toistaiseksi, että sinulla on hyvä käsitys kaikesta yllä olevasta, ennen kuin jatkat, sillä se on välttämätöntä ymmärtää jäljellä olevaa työtä varten.

Tämä verkkosivusto käyttää evästeitä parantaakseen käyttökokemustasi. Oletamme, että olet kunnossa, mutta voit halutessasi kieltäytyä. Hyväksyä Lisätietoja