W tym momencie nie wiem, ile artykułów napisałem o znaczeniu Standardów Kodowania WordPressa (wystarczy link do nich tutaj, tutaj i tutaj, jak sądzę, co się liczy).
Ale po wykonaniu wystarczającej liczby projektów dla klientów i pracy z programistami, którzy są znacznie mądrzejsi i zaznajomieni z zaawansowanymi narzędziami niż ja, jestem w miejscu, w którym decyduję się zacząć używać PSR w rozwoju WordPressa.
O dramat, prawda?
Ale naprawdę. Są ku temu powody i są chwile, w których uważam, że standardy kodowania WordPress nadal powinny być używane, ale szybko nabieram przekonania, że budowanie jakiegokolwiek nowoczesnego projektu na bazie WordPressa powinno korzystać z bardziej nowoczesnych narzędzi PHP (które ja pokrótce wspomnę później).
Korzystanie z PSR w programowaniu WordPress
Posty takie jak ten często wnikają w jakąś debatę lub dramatyczne reakcje w WordPressie, co nie jest moją intencją, ani nie jest to coś, co uważam za konieczne. Szczerze mówiąc, znam wielu innych programistów , z których wszyscy robili to dawno temu, rozmawiali o tym, posuwali się naprzód i nadal odnosili sukcesy zarówno w swoim biznesie, jak i projektach hobbystycznych.
Ale biorąc pod uwagę, że tak dużo rozmawiałem o jednym kontra drugim, pomyślałem, że warto podzielić się moim zdaniem, dlaczego decyduję się na tę zmianę teraz i uzasadnieniem tego.
1 Parzystość ze społecznością PHP
W ciągu ostatniego roku, a właściwie tylko w ciągu ostatnich kilku miesięcy tego roku, przyzwyczaiłem się bardziej do:
- bardziej doświadczeni znajomi programiści zorientowani na PHP, popierający narzędzia, które oczekują przyjęcia PSR,
- użycie //@codingStandardsIgnoreStart i //@codingStandardsIgnoreEnd w moim kodzie,
- niestandardowe zestawy reguł dla moich projektów oparte na środowiskach, w których są wdrożone,
- i więcej.
Ostatecznie chodzi o to, aby zachować parzystość (lub trochę) z większą społecznością PHP, jednocześnie pisząc czytelny, oparty na standardach kod na WordPressie. Chciałbym też skorzystać z kilku innych narzędzi i nowszych wersji istniejących narzędzi (o których omówię w dalszej części tego postu).
2 problemy z nowoczesnymi środowiskami
W chwili pisania tego posta PHP CodeSniffer (wymagany do uruchomienia WordPress Coding Standards) jest w wersji 3.0.2. Istnieją jednak problemy ze zgodnością z PHPCS i standardami kodowania WordPress. W szczególności :
Nowa wersja PHP CodeSniffer ma kilka fajnych funkcji, ale wprowadza przełomowe zmiany, które powodują, że standardy kodowania WordPress nie są kompatybilne.
Aby było jasne (i ze względu na naturę oprogramowania), to kwestia czasu, zanim zostanie to naprawione. Ale jeśli pracujesz na bazie kodu i korzystasz z Composer i WordPress Coding Standards, musisz jawnie ustawić wersję PHP CodeSniffer, a nie najnowszą wersję.
Ponadto doświadczyłem problemów z klientami, w których nie zaadoptowanie PSR w programowaniu WordPress spowodowało dziwne zachowanie podczas wdrażania kodu. Być może można by argumentować, że powinni dostosować środowisko, ale jeśli pracują, aby mieć najnowocześniejsze narzędzia dostępne dla ludzi, którzy ich używają, po co się cofać?
3 Kompatybilność z nowoczesnymi narzędziami
Wreszcie istnieje wiele nowoczesnych narzędzi, których nie mogłem użyć, nie mówiąc już o nauce, z powodu tego, co jest, a co nie jest obsługiwane przez naturę wersjonowania.
Na przykład, używaliśmy GrumPHP w ostatnim projekcie, który obsługuje różne narzędzia, ale nie mogliśmy użyć, powiedzmy, PHPMD z powodu braku przyjęcia PSR. Jeśli o mnie chodzi:
- Chcę stale podnosić swoje umiejętności jako programista (a w tym kontekście programista PHP),
- brak wsparcia dla nowocześniejszych narzędzi stawia mnie w utrzymywaniu, którego inaczej bym nie doświadczył,
- Chcę nadal pracować z WordPressem, ale rób to z bardziej nowoczesnym przepływem pracy
A w tej chwili niekorzystanie z PSR tworzy lukę między tym, co robi reszta społeczności PHP, a tym, co robi WordPress. Dlatego chciałbym iść naprzód, jednocześnie pracując nad projektami na oprogramowaniu, którego nadal lubię używać.
Co ze standardami kodowania WordPress?
Co to oznacza w przypadku standardów kodowania WordPress i poprzednich postów? Nic takiego. Sposób, w jaki to widzę: Standardy kodowania WordPressa powinny być używane za każdym razem, gdy pracujesz nad WordPress Core lub czymś, co będzie z nim ściśle zintegrowane.
Ale jeśli pracujesz nad czymś, co znajduje się na szczycie WordPressa lub czymś, co wykorzystuje WordPress jako podstawę i możesz użyć PSR w rozwoju WordPress wraz z narzędziami, które mogą pomóc w podniesieniu jakości tworzonej bazy kodu.
Tak więc, przynajmniej na razie, taką perspektywę zamierzam przyjąć. Nie mogę się doczekać, jak się rozwinie w ciągu najbliższych kilku miesięcy. A jeśli chodzi o wszystko, czym się podzieliłem, podzielę się aspektami dokonywania tej zmiany.