Widżety WordPress: Refaktoryzacja, część 1

Ostatni post zawierał wiele informacji na temat konfigurowania narzędzi jakości kodu w środowisku programistycznym WordPress, ale są one niezbędne, jeśli zamierzamy robić dużo refaktoryzacji.

Ale jak wspomniałem na początku tego postu, najpierw stworzenie narzędzi jakości kodu zapewnia nam podstawę, której możemy użyć, gdy dokonamy refaktoryzacji boilerplate’u (co oczywiście musimy zrobić, biorąc pod uwagę ilość czerwieni pokazaną przez GrumPHP).

Szczerze mówiąc, uważam je za konieczne, jeśli zamierzasz robić jakikolwiek rodzaj rozwoju, stąd potrzeba pokazania, jak je skonfigurować.

Niezależnie od tego, poprzedni post pokazuje, ile pracy dla nas wycięliśmy, prawda?

Teraz zaczniemy od refaktoryzacji WordPress Widget Boilerplate.

To nie tylko poprawi jakość kodu, ale także przeprowadzi nas przez niektóre zasady zorientowane obiektowo, które możemy zastosować podczas tworzenia naszych widżetów i możemy zastosować w przyszłych wysiłkach programistycznych WordPress.

WordPress Widget Boilerplate: Refaktoryzacja, część 1

Być może najbardziej ekscytującą rzeczą jest dla mnie dostosowanie tego repozytorium do współczesnych standardów. Jeśli spojrzysz na główną gałąź w GitHubie w czasie tego posta (lub historię repozytorium później), zobaczysz, że ma sześć lat.

Ta rzecz ma sześć lat (w momencie pisania tego posta).

To długi czas w internetowych latach, prawda?

W każdym razie w naszych wysiłkach refaktoryzacji zamierzamy zrobić kilka rzeczy:

• utworzenie gałęzi, z której będzie można pracować przed ponownym połączeniem jej z gałęzią główną,
• wdrożenie bardziej spójnego sposobu organizowania plików,
• aktualizacja standardów kodowania pod kątem tego, co jest bardziej zgodne z PSR,
• i więcej.

Przedstawiam to teraz, ponieważ prawdopodobnie nie omówimy tego wszystkiego w tym poście, ale omówimy dużo tematu. Powiedziawszy to, zacznijmy.

1 Tworzenie Oddziału Deweloperskiego

Zakładając, że masz kopię repozytorium na swoim lokalnym komputerze, którą powinieneś mieć po ostatnim poście, pierwszą rzeczą, którą musimy zrobić, to utworzyć gałąź, na której będziemy wykonywać naszą pracę.

Najlepszą praktyką jest nie pracować na gałęzi master. Zamiast tego należy zawsze używać wzorca do wdrażania najnowszej stabilnej wersji kodu.

W tym celu wpisz w terminalu następujące polecenie:

$ git checkout -b develop

Spowoduje to utworzenie nowego oddziału lokalnego. Nie został jeszcze przekazany do GitHub lub zdalnego repozytorium (gdziekolwiek go przechowujesz).

Następnie wprowadź następujące polecenie:

$ git push --set-upstream origin develop

Spowoduje to wypchnięcie gałęzi deweloperskiej do zdalnego repozytorium. Gdy to zrobisz, powinieneś być w stanie zobaczyć wszystkie zmiany, które wprowadziliśmy w ostatnim poście w twoim zdalnym repozytorium.

Jeśli używasz GitHub, powinno to wyglądać mniej więcej tak:

Jeśli korzystasz z innej usługi, nadal powinna wyglądać podobnie. Oznacza to, że struktura katalogów powinna być taka sama, ale wygląd w przeglądarce będzie się różnić.

Uwaga o oddziale

Pamiętaj, że celem tej gałęzi jest wykonanie całej naszej pracy. W ten sposób nie ingerujemy w gałąź master, z której wiele osób będzie ciągnąć.

Żeby było jasne, może nikt z tego nie wyciągnie. Może to zrobią. Niezależnie od tego, przedstawione tutaj praktyki mają na celu pokazanie, jak uruchomić projekt przy użyciu narzędzi kontroli źródła i jakości kodu, dzięki czemu możesz tworzyć lepsze projekty dla siebie, swojej firmy i nie tylko.

2 Reorganizacja plików

Pierwszą rzeczą, którą powinniśmy zrobić, to zreorganizować pliki, tak aby naśladowały bardziej nowoczesną strukturę. Zrobię co w mojej mocy, aby uzasadnić decyzje, które podejmuję dla projektu, kiedy to robimy; jednak możesz swobodnie wybrać sposób, w jaki chcesz to zrobić.

Decyzje, które podejmę, ostatecznie wpłyną na podstawowy Boilerplate. To, co zdecydujesz się zrobić, wpłynie na to, jak możesz z niego korzystać w swojej codziennej pracy lub jak zdecydujesz się kontynuować projekt jako całość.

Aktualizowanie katalogów

Jedną z rzeczy, które staram się zrobić, jest rozbicie moich katalogów, aby były jak najbardziej przejrzyste. Oznacza to, że staram się wykonać następujące czynności:

• stworzyć katalog assetów dla JavaScript i arkuszy stylów,
• utwórz katalog src dla wszystkich plików PHP,
• utworzyć katalog językowy dla plików internacjonalizacji,
• zachowaj wszystkie inne pliki w katalogu głównym repozytorium, aby inni mogli łatwo śledzić wraz z dostarczonym README.

Aby to zrobić, najpierw usunę i przeniosę kilka rzeczy. Próbowałem to uporządkować w określonej kolejności:

1. Zamierzam usunąć plik README.txt. Ten plik jest używany jako standardowy szablon README, jeśli zamierzasz przesłać kod do repozytorium wtyczek WordPress, ale nie jest to konieczne do tego, co chcę dla Boilerplate.
2. Zmienię nazwę plugin.php na Plugin .php zgodnie z konwencją PSR.
3. Zmienię też nazwę lang na języki.
4. Zamierzam utworzyć katalog asset i przenieść, a następnie przenieść katalogi css i js do tego katalogu. W każdym z tych katalogów stworzę podkatalog dev, w którym będziemy mogli pracować na Sassie i niezminifikowanych plikach JavaScript (oba pojawią się w dalszej części serii).
5. Następnie stworzę katalog src i przeniosę arkusz stylów views do tego katalogu.
6. Zmienię również nazwę widoków na Widoki i będę pisać wielkie litery w plikach w nich zawartych.
7. Na koniec przeniosę wszystko do katalogu głównego. Oznacza to, że widget-boilerplate zniknie, a wszystkie pliki pozostaną w katalogu głównym repozytorium.

To dużo kroków, ale są one małe. Lubię układać je najpierw, aby było jasne, co się stanie w pozostałej części tej sekcji.

Usuń plik README

Aby to zrobić, po prostu wpisz w terminalu następujące polecenie z katalogu głównego widget-boilerplate :

$ rm readme.txt

Spowoduje to usunięcie pliku. Jeśli wpiszesz w terminalu następujące polecenie:

$ git status

Powinieneś zobaczyć coś takiego:

Jestem fanem upewniania się, że różne zmiany, które są wprowadzane, są jasne i zwięzłe, aby łatwiej było je cofać pojedynczo. Więc chodźmy dalej, zatwierdźmy i popchnijmy tę zmianę.

Wpisz następujące informacje:

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

To powie Gitowi, aby usunął plik, dodał pojedynczą zmianę do zbioru zmian, zatwierdził go bez uruchamiania narzędzi jakości kodu (ponieważ nie musimy tego teraz robić; w przeciwnym razie to się nie powiedzie) i wypchnie go do gałęzi deweloperskiej zdalnego repozytorium.

Teraz, gdy już to zrobiliśmy, zmieńmy nazwy niektórych plików.

Zmiana nazw plików

Skoro już przy tym jesteśmy, nie tylko zmienimy nazwę pliku plugin .php, ale także innych plików PHP. Są to pliki, które można logicznie pogrupować w tym samym zestawie zmian, więc warto to zrobić.

Więc ze swojego terminala wprowadź następujące polecenia:

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

Robiąc to, nie wprowadziliśmy jeszcze żadnych zmian w plikach, więc nie ma nic do zatwierdzenia. Przejdźmy dalej ze zmienianiem nazw katalogów.

Utwórz katalogi; Zmień nazwę katalogów

Tak jak zrobiliśmy z plikami, stwórzmy nowy katalog zasobów . W swoim terminalu wpisz następujące polecenie:

$ mkdir assets

Następnie chcemy przenieść katalogi css i js do tego katalogu, więc wprowadź również w terminalu:

$ mv css assets
$ mv js assets

I zmieńmy nazwę katalogu lang na Języki, wpisując następujące polecenie:

$ mv lang Languages

Na koniec zmieńmy nazwę widoku na Widoki:

$ mv views Views

W tym momencie zrobiliśmy wszystko, co w naszej mocy, z plikami znajdującymi się obecnie w głównym katalogu. Jednak nadal musimy przygotować podkatalogi dla naszych wstępnie przetworzonych zasobów.

Jednak zanim to zrobisz, dobrym nawykiem jest szybkie sprawdzenie statusu git, aby zobaczyć, co istnieje, co można dodać do zestawu zmian. Jeśli twoje repozytorium jest podobne do mojego, prawdopodobnie zobaczysz coś takiego:

W tym przypadku myślę, że można dodać wszystko do jednego zestawu zmian z komentarzem wskazującym, że zmieniliśmy nazwy i przenieśliśmy pliki.

Możesz się różnić, a jeśli tak, to w porządku. Twoje polecenia będą się nieco różnić od moich, ale oto, co mam do mojego zatwierdzenia:

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

Teraz przejdźmy do podkatalogów dla naszych wstępnie przetworzonych plików.

Utwórz podkatalogi

W katalogu CSS utwórz podkatalog o nazwie dev i utwórz pusty plik o nazwach admin.scss i widget.scss, ponieważ będziemy pracować z tymi plikami w dalszej części serii.

Następnie dodaj katalog dev do katalogu JavaScript i dodaj do tych plików pusty plik admin.js oraz pliki widget.js. Jeśli masz taką ochotę, możesz przenieść istniejące wcześniej pliki do katalogów deweloperskich, ponieważ są to pliki, których będziemy używać jako podstawy dla naszych plików deweloperskich.

To opcjonalny krok; jednak poszedłem dalej i zrobiłem to, ponieważ tak wolę pracować. Oto zestaw poleceń, które uruchomiłem.

Z katalogu css …

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

Powyżej stworzyłem katalog dev dla moich arkuszy stylów, zmieniłem ich nazwy na pliki Sass i przeniosłem je do katalogu dev.

Zanim przejdziemy dalej, teraz jest dobry moment na sprawdzenie statusu git i zatwierdzenie zmian związanych z arkuszami stylów:

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

Teraz z katalogu js …

$ mkdir dev
$ mv *.js dev

Ponieważ nie musimy zmieniać typu skojarzonych plików, możemy po prostu przenieść je do nowego katalogu.

Na koniec zróbmy to samo i zobaczmy, czy są jakieś zmiany, które możemy wprowadzić poprzez szybkie sprawdzenie statusu git (co powinno być). Oto lista poleceń, które uruchomiłem, aby zatwierdzić i przekazać moje zmiany:

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

Prawie skończyliśmy. Pozostało tylko przenieść określone katalogi do katalogu głównego repozytorium i zmienić nazwę głównego katalogu na src. Więc zróbmy to teraz.

Przenieś katalogi do katalogu głównego

Zasadniczo musimy przenieść wszystko oprócz pliku wtyczki i katalogu Views z katalogu widget-boilerplate i zmienić nazwę widget-boilerplate na src.

Brzmi prosto, prawda? To całkiem proste. Z katalogu widget-boilerplate :

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

Następnie zatwierdzę zmianę na GitHubie, używając:

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

Teraz mamy skonfigurowaną znacznie bardziej nowoczesną strukturę katalogów. Możesz to zobaczyć tutaj w mojej gałęzi programistycznej.

Słowo o OOP

A teraz, gdy mamy to wszystko na miejscu, możemy zająć się pisaniem kodu. Ale nie mylcie się: częścią programowania obiektowego jest również analiza obiektowa i projektowanie zorientowane obiektowo.

To, co zrobiliśmy w tym poście, to zasadniczo zastosowanie projektu architektonicznego zorientowanego obiektowo, opartego na analizie dopasowania wtyczki.

Jednak następną częścią jest aktualizacja kodu, aby pozbyć się całej czerwieni, którą widzieliśmy podczas sniffowania naszego kodu.

W następnym poście

Głównym celem następnego wpisu jest kontynuacja aktualizacji standardów kodowania, dzięki czemu rozwiązaliśmy wszystkie problemy rzucone przez nasze IDE lub przez narzędzia jakości kodu, które uruchamiamy w wierszu poleceń.

Powinniśmy również mieć znacznie czystsze, lepiej zorganizowane repozytorium i być w stanie, w którym jesteśmy gotowi do scalenia naszej pracy z powrotem do gałęzi głównej.

Na razie jednak upewnij się, że dobrze znasz wszystko powyżej, zanim przejdziesz dalej, ponieważ konieczne jest zrozumienie przez pozostałą część pracy, którą mamy przed sobą.