Pisanie lepszego kodu WordPress: PHPStan
W najnowszym poście z tej serii (który jest co prawda jakiś czas temu) pisałem obszernie o Composerze i jego pliku blokującym.
Polecam przeczytanie dwóch poprzednich artykułów, ponieważ Composer w końcu odegra rolę w tym materiale, którym udostępnimy ten i przyszłe posty. Ale jeśli zdecydujesz się ich nie dogonić (lub znasz już Composer), to sedno poprzednich postów jest odpowiednio następujące:
Nie polecam sprawdzania katalogu dostawców w swoim repozytorium. Może to stać się później ogromnym katalogiem i może podważyć cały cel Composera.
Celem jest upewnienie się, że każdy z nich korzysta z tej samej wersji zależności projektu – nie starsze wersje, nie nowsze wersje – ale ta sama wersja.
Mając to na uwadze, istnieje wiele zależności lub pakietów, które możemy zainstalować, które pomogą nam upewnić się, że piszemy kod najwyższej możliwej jakości.
Jasne, niektóre z nich mogą mieć formę czegoś w rodzaju standardów kodowania, ale tak naprawdę są to bardziej zasady niż elementy pisania wysokiej jakości kodu (choć nie sądzę, aby były pomijane w dyskusji – po prostu pominięte w tej chwili 🙃).
Wróć do narzędzi, o których mowa: Jakie są narzędzia, które pomagają pisać wysokiej jakości kod WordPress? Podzielę się kilkoma z moich ulubionych i opowiem o tym, jak możemy je wszystkie wykorzystać w oparciu o kod.
Najpierw spójrzmy na analizę statyczną za pomocą PHPStan.
Lepszy kod WordPress z PHPStan
Czym właściwie jest analiza statyczna?
Najpierw kilka słów o analizie statycznej. Mianowicie, co to jest? Po pierwsze, to kęs:
Statyczna analiza kodu (znana również jako analiza kodu źródłowego) jest zwykle wykonywana jako część przeglądu kodu (znanego również jako testowanie białoskrzynkowe) i jest przeprowadzana na etapie wdrażania cyklu rozwoju zabezpieczeń (SDL).
Statyczna analiza kodu zwykle odnosi się do uruchamiania narzędzi statycznej analizy kodu, które próbują wskazać możliwe luki w „statycznym" (nieuruchamiającym się) kodzie źródłowym za pomocą technik, takich jak analiza defektów i analiza przepływu danych.
Pomyśl o tym w ten sposób: jest to sposób na analizę programu pod kątem potencjalnych błędów, których możesz nie zauważyć podczas pracy z bazą kodu.
Oznacza to, że istnieją problemy, błędy, problemy z bezpieczeństwem, które mogą występować, ale nie można ich wykryć z wielu powodów (z których najmniejszym jest to, że jesteś zbyt blisko kodu).
Jednak z biegiem czasu społeczność programistów nauczyła się analizować kod, generować zestawy reguł i budować narzędzia, które pomagają znaleźć dokładnie wszystkie powyższe elementy.
Analiza statyczna kodu zorientowanego na WordPress
I tu właśnie pojawia się PHPStan.
Jak wspomniano, celem pakietu jest identyfikacja błędów lub błędów, które istnieją w twoim kodzie, zanim twój kod zostanie użyty przez kogoś innego niż programiści, podświetlenie ich i umożliwienie ich naprawienia.
Ponieważ narzędzia takie jak to sprawdzają bazę kodu (w przeciwieństwie do uruchamiania kodu), nie zawsze jest możliwe uzyskanie jasnego obrazu. Oznacza to, że możemy uzyskać fałszywe alarmy.
Więcej o tym za chwilę.
Jeśli interesuje Cię rozpoczęcie pracy z PHPStan w oparciu o Twój kod, jest to łatwe. Po zainstalowaniu pamiętaj tylko, aby skonfigurować go tak, aby nie wyglądał w vendorkatalogu lub, powiedzmy, rdzeniu WordPressa.
Zamiast tego poproś go o sprawdzenie kodu.
Instalowanie PHPStan
Najpierw w swoim composer.jsonpliku dodaj następujący wiersz w require-devsekcji:
"phpstan/phpstan": "^0.11.12"
Następnie uruchom composer updatew swoim terminalu.
Po zainstalowaniu możesz go uruchomić na pojedynczym pliku, katalogu lub zestawie katalogów. Jeśli czytałeś moje poprzednie posty na temat organizacji kodu, wiesz, że jestem fanem trzymania większości kodu źródłowego projektu pod ręką src, możesz uruchomić coś takiego:
$ vendor/bin/phpstan analyse src
Spowoduje to wygenerowanie danych wyjściowych na podstawie tego, co znajdzie narzędzie.
Pamiętasz, kiedy powiedziałem, że może znaleźć takie rzeczy, jak fałszywe alarmy? Oto bardziej szczegółowe zestawienie tego, co możesz zobaczyć:
- Dodatkowe argumenty przekazywane do funkcji (np. funkcja wymaga dwóch argumentów, kod przekazuje trzy)
- Dodatkowe argumenty przekazywane do funkcji print/sprintf (np. ciąg formatujący zawiera jeden symbol zastępczy, kod przekazuje dwie wartości do zastąpienia)
- Oczywiste błędy w martwym kodzie
- Magiczne zachowanie, które należy zdefiniować.
Wszystkie powyższe prosto z repozytorium.
W tym miejscu poziomy reguł mogą mieć znaczenie, chociaż może wymagać trochę poprawek, aby uzyskać poziom odpowiedni dla twojego zespołu lub projektu.
A co z analizą dla WordPressa?
Viktor Szépe podzielił się ze mną tym zasobem (a właściwie czymś, co jest jego autorem) i myślę, że jest to coś istotnego i użytecznego. Idea pakietu jest prosta:
Rozwiązuje wszystkie problemy, które miałem podczas analizy kodu dla WordPressa.
Nieźle, prawda?
Przeanalizuj swój kod
Niezależnie od Twojego projektu, organizacji kodu, czy poziomu, na którym uruchamiasz to konkretne narzędzie, zawsze chodzi o poprawę jakości pisania kodu WordPress.
Zainstalowanie tego jako pakietu Composer, a następnie uruchomienie go w swoim srckatalogu to krok we właściwym kierunku.
Jak wcześniej wspomniano, podzielę się kilkoma innymi narzędziami, a następnie podzielę się tym, jak je wszystkie uruchomić w bazie kodu przed zatwierdzeniem kodu w repozytorium.
Notatka
Jeśli masz problem z konfiguracją pakietu, Dave Mackey skontaktował się ze mną z podobnym problemem i jego rozwiązaniem.