 Dzień dobry. Tak jak już kolega wspomniał, ona znała się Sebastian Kurzynowski i będę opowiadał dzisiaj o standardach WordPressa i o Coat Sniperze. Tak naprawdę, skąd się bardziej na Coat Sniperze, ponieważ Coat Sniper to naprawdę bardzo ciekawe narzędzie, o którym wielu z nas naprawdę nie wie. Sam go odkryłem, szczerze mówiąc przez przypadek, ale uratował mnie z opresji. Tak więc zaczynamy. Tutaj rzućmy okiem w ogóle o czym dzisiaj opowiem, tak więc jak widzimy kilka podstawowych rzeczy, czym są standardy programowania, standardy z WordPressa, jak przestrzegać tych standardów, ponieważ nie jest to wcale takie łatwe. Oczywiście czym jest Coat Sniper, jak będziemy pracować z Coat Sniperem. Postaram się nie zanudzić was technicznymi stronami, a raczej przekonać do tego, żebyście w domu sami chcieli sobie zainstalować i spróbować, bo to naprawdę oszczędza nam mnóstwo czasu, zresztą o czym jeszcze opowiem. Ogólnie, czym jest standard programowania? Posiliłem się Wikipedia, tak jak każdy w takich wypadkach. Tak więc standard programowania, a tutaj w Wikipedia był termin standard kodowania. I jak widzimy, mamy nasze opisanie kodu źródłowych programów komputerowych, zasady służące do zunifikowania, czyli ujednolicenia, wyglądu i zachowania kodu. Standard kodowania może obejmować wiele aspektów kodu programu. No i między innymi to jest właśnie formatowanie, konwencja nazewnicze, komentowanie kodu, konstrukcje programistyczne. Czyli, czumacząc to na nasz ludzki język, jest to zespół jakiś zasad, który określa to, w jaki sposób będziemy pisać nasz kod. Jeżeli będziemy tego przestrzegać i ludzie faktycznie będą stosować się kilka osób, które będzie stosowało się do tego samego standardu, to kilka osób będzie wiedziało, faktycznie będzie jakby szybciej, będą w stanie szybciej znaleźć w tym kodzie, to, co jest potrzebne, dlatego, że wszyscy przestrzegamy tych samych zasad, tak? Teraz pora na łyg wod, żeby się nie rozpędził za mocno i tak. Tak więc wiemy, że standard programowania to jest jakiś zespół zasad, jak mamy pisać kod. No i pojawia się pytanie, czy WordPress ma was te standardy? Byłem tutaj na wielu świetnych prezentacjach dzisiaj. Oczywiste jest, że WordPress ma swoje standardy programowania. Jedni lubią bardziej, drudzy mniej, ale ma. I żeby wam pokazać standardy, wybrałem się właśnie na stronę WordPressa. Nie są one wcale zatajone, możemy je sobie śmiało przejrzeć i nawet spróbować się do nich stosować. I właśnie gdy wybrałem się na tą stronę WordPressa, zobaczyłem, że WordPress określił, jak powinniśmy pisać kod PHPa, jak powinniśmy tworzyć i upkładać znaczniki HTMLa, jak powinniśmy pisać CSSa oraz JavaScript. Jako, że głównie pisze w PHP, to pokażę wam kilka takich podstawowych rzeczy z właśnie tego standardu programowania WordPressa. No i m.in. właśnie, jak kliknąłem tutaj ten pierwszy link, czyli WordPress PHP, Coding Standards, no i tam, m.in. znalazłem coś takiego. Czyli WordPress w swoich standardach faktycznie, jeżeli piszemy PHPa, nie zaleca pisania SIF oddzielnie, ale zaleca, żeby pisać to razem, tak? To nie jest to jakiś wielki wymóg, ale faktycznie standard obejmuje nawet tego typu detale. Oraz to jest, to jest, to jest dość ciekawe, właśnie Naming Conventions, czyli konwencja nazewnicza, czyli faktycznie, jak powinniśmy nazywać te zmienne. Bardzo często zaglądzając do kodu od moich nawet kolegów z pracy, widzę, że to nazewnictwo, ten sposób nazywania nie jest przestrzegany. I co to powoduje? Na przykład, jeżeli ktoś będzie chciał pisać moduł lub jak jakąś klasę i nazwie ją nie w taki sposób, jak powinien, albo nazwie plik, nie w taki sposób, jak powinien, to mój autolowder już nie będzie w stanie tego obsłużyć. Czyli ja już, czyli automatycznie wyrzuci to błąd i dlatego, że klasy nie może znaleźć. Ale jeżeli ta osoba faktycznie przestrzega tych samych standardów, czyli standardu WordPressowego, jak nazywać nasze klasy i jak nazywać nasze pliki, to dodając ten komponent do mojej wtyczki, nie spowoduje to żadnego błędu, element zostanie znaleziony i faktycznie będzie działał, będzie wykonował swoją pracę. No i nie wiem, czy słyszeliście właśnie o Yodakonditions, czyli we wszystkich if. Najpierw wstawiamy wartość, której oczekujemy i później ją przyrównujemy do czegoś. Czyli jest to trochę logiczne, bo mojej głowy zawsze się układa, że jeżeli moja zmienna będzie wnosiła 10, to wtedy zrobię coś, jednak WordPress zaleca, żeby pomyśleć o tym, jeżeli 10, to będzie moja zmienna, to zrobię to. I dzięki temu, ja zauważyłem po czasie, że faktycznie w tym kodzie to się rzuca w oczy, ta pierwsza wartość rzuca się w oczy i trochę to ułatwia. Oczywiście nie zawsze, ale ma to trochę sensu. No i jak już widzimy, mamy różnego rodzaju standardy, mamy te zasady tworzenia naszego programowania, pisania tego kodu. No i ktoś powie, super, chciałbym tego przestrzegać. I jak to teraz zrobić? Otwieramy tą stronę PHP, standardem PHP WordPressa, a tam widzimy, to może skrolować dwie minuty i tego jest dużo. No i pojawia się pytanie, no ale jak? Mam nauczyć się wszystkich zasad na pamięć. Doskonale wiecie, tak samo jak ja, tak samo każdy z was, uczymy się tysiąca rzeczy każdego dnia, no co musimy się rozwijać i jeszcze teraz wgrać do głowy całą wielką stronę wszystkich standardów jest absurdalne, a co jeżeli ktoś powie jakiś inny standard, nie Wordpressowski, nie wiem, PSR4, PSR0, mamy się wszystkiego uczyć, no oczywiście, że nie. Programyści są lenivi, wszyscy to wiemy i z tego właśnie powodu mamy narzędzia, które nam w tym pomogą. I tak, to kluchę specjalnie umieściłem na tym slajdzie, bo chciałbym poruszyć kilka tematów jednocześnie, czyli zautomatyzowana kontrolę jakości wewnętrznej przy użyciu code sniffer. Tak, zautomatyzowana, dlatego że nie będziemy sprawdzać każdej linijki kodu i szukać tego w standardzie, czyli będzie działo się to automatycznie, kontrolę jakości wewnętrznej, czyli tak, mamy ogólnie dwa rodzaje jakości, nie chodzi mi o dobrą i złą, bo to jest zupełnie inna podziałka, mamy dwa rodzaje właśnie tej jakości, wytwarzając oprogramowanie, mamy jakość wewnętrzną i jakość zewnętrzną. Jakością zewnętrzną jest wszystko co, co czyni naszego klienta zadowolonego z naszego produktu, czyli to wszystko, że te wszystkie hovery nad batonami zmieniają te klasy, że tam to świeci, że fireworki, naprawdę wszystko to co uczyni go szczęśliwym, tak? Ale i co jest właśnie jakość zewnętrzna? Zewnętrzna, bo wychodzi z naszej firmy do klienta i teraz pojawia się pytanie, czym jest jakość wewnętrzna? Jakość wewnętrzna to wszystko to, co sprawi, że gdy my zachorujemy i siedzimy w domu, a nasz kolega musi coś naprawić w projekcie, to on będzie szczęśliwy. On będzie szczęśliwy dlatego, że dbamy o jakość wewnętrzną, czyli wcześniej też dzisiaj widziałam prezentację, była bardzo ciekawa o tym, jak chłopaki optymalizowali procedury wytwarzania programowania i właśnie oni zaczęli koncentrować się na jakości wewnętrznej, bo to jest bardzo ważne. Dlatego, że te projekty nie może być tak, że pracuje 10 osób w software house'ie i 10 osób jest niezastąpionych, bo każdy ma swój projekt. To jest odrobinę absurdalne, jednak w firmie, w której ja pracuję, faktycznie zdarzało się tak, że trzeba było dzwonić, ściągać ludzi, tylko i włącznie dlatego, że ten projekt był postawiony w jakiś dziwny sposób przez jedną osobę. A następna nie była w stanie zrozumieć tak naprawdę, w jaki sposób ma w ogóle wystartować to środowisko. Dlatego jakość wewnętrzna to jest ustalenie jakichś standardów, które ułatwiają nam, pracę nad jednym projektem na przykład dla kilku osób, przekazywanie projektu, wszystko właśnie między innymi code sniffer, pomoże nam to utrzymać. A code sniffer jest statycznym analizatorem code'u. Czyli wyobraźmy sobie, że piszemy ten code przy komputerze, ale przyszedł ktoś i posadził nam takiego małego pierdliwego gościa z naszym ramieniem. I ten gościu z nudów w życiu nauczył się wszystkich zasad właściwego programowania według WordPressa. I za każdym razem, gdy zostawiamy jakąkolwiek linijkę, w której jest jakiś błąd, jakiś odstępstwo tego code'u, to on nas puka w ramie po raz 1743 i mówi, ej, kolego, według standardu numer to i to, zrobiłeś coś źle, popraw to. I to jest właśnie code sniffer. To jest ktoś, kto pilnuje nas, żebyśmy przestrzegali tych standardów i dzięki temu podnosili jakoś wewnętrzne oprogramowania, które wytwarza i znowu przerwa na wodę. Czyli tak jak już powiedziałem, czym jest code sniffer? Czyli statyczny analizator code'u analizuje code statycznie, czyli nie przepusza go przez interpreter, czyli po prostu tak jakby człowiek czytał faktycznie linia po linii sobie, przegląda i porównuje według regexów i innych zasad ze swoimi standardami, które ma zarejestrowane. I pytanie, dlaczego ja zacząłem używać w ogóle code snifera? Otóż odpowiedź to PHP 5.3 oraz ministerzysta. Tak, stworzyliśmy produk w tym roku i miałem już około 3-4 tysięcy aktywnych instalacji, zaczęły pojawiać się tikety, że jest syntax error. Mówię, no jak to jest możliwe, że jest syntax error? Skoro u mnie wszystko działa? Standardowy problem, przecież to kiełakarz co miał, nie? Tak i okazuje się, że no ja piszę PHP 7.3 praktycznie większość code'u. Ja tylko, że większość klientów faktycznie namówiliśmy na to, żeby dbać o to wiadomo dwa razy, więcej requestsu obsługujemy i tysiąc innych rzeczy. I okazało się, że ci klienci, którzy zgłaszali te błędy, te tikety, które dostaliśmy, one właśnie dotyczyły serwerów, które były na 5.3. No i teraz ja sobie spojrzałem do mojego edytora i widzę, że mam tutaj około 5 tysięcy linii code'u. Nie mam zielonego pojęcia czym się różni, znaczy wiem jakie są przewagi 7, ale nie pamiętam czego nie było w 5.3, a teraz mam kilka tysięcy linii code'u i muszę tak zrobić, żeby to działało, bo dziwne jest to, że jeżeli tego błędu nie rozwiąże, to z nieladzieniem tych tiketów będzie coraz więcej, coraz więcej. Jakby marketing w tyczki może też paść przez coś takiego, dlatego, że z nieladzieniem coraz większa frustracja klientów spowoduje po prostu, że przesadłam z tego korzystać i przesadłam to instalować. Tak, a i właśnie wtedy odkryłem pewne standardy do code'u cnifera, o których jeszcze opowiem. Mój stażysta to jest druga rzecz. Otóż mój stażysta, który przyszedł miał naprawdę szczere, dobre serce do pracy i naprawdę każdy z nas tak przychodzi, chce zacząć, chce się naprawdę jak najbardziej przyłożyć do tej pracy, jak najmniej chce się nauczyć. No ale niestety każdy z nas popełnia takie błędy, które utrudniają pracę innym i ja zdecydowałem po mojej jakby którejś pracy z kolejną osobą, którą szkole, że pierwszy dzień pracy ja poświęcam tylko na pomoc w ustawieniu całego środowiska programistycznego dla mojego stażysty. Zainstalowałem mu code quality tool, o którym zresztą później wspomnę, zainstalowałem mu standardy WordPressa i tak pomogłem mu ustawić ten jego edytor, żeby nie był w stanie wypknąć złego code'u na repozytorium. Pierwsze dni to była dla mnie naprawdę udręka, bo co 10 minut, nie no co 10 minut, ale co pół godziny miałem telefon na slaku, że słuchaj nie mogę tego wypknąć. No i tłumaczyłem po mało, po mało, ale te efekty, które ten sposób code'u jaki on, znaczy ten code, który on teraz tworzy po dwóch, bo został u nas w pracy i teraz już pracuje, jest zatrudniony, po dwóch czy tam trzech miesiącach pracy jest niesamowity. Naprawdę to jest człowiek, który uczył się praktycznie od zera i na dzień dzisiejszy jego wtyczki bardzo często są nieporównywalnie lepsze z tymi, które ja np. pisałem po roku pracy. Tylko i włącznie dlatego, że ten, posadziłem mu tego gościa tu z jednej strony i go pukał za każdym razem, jak on jedną linię code'u chciał zepsuć, tak? A tutaj chciałem wam pokazać możliwe, że nie będzie to dobrze widoczne w każdym razie. To jest coś, co spowodowało, że musiałem szukać tego code snifera, bo to myślałem się, że nie wolno tak robić i na razie tam po śpiechu faktycznie odwołałem się, po lewej stronie widzimy, że to w 5.3 powoduje błąd, a w 7.0. Po lewej stronie odwołałem się od razu do rezultatu explode'a do elementu tablicy i to nie jest możliwe w wersji 5.3 i przez to właśnie dostałem te tikety w GDPR, znaczy w tej wtyczce, którą robiłem do GDPR, czyli do RODO. I tak, tak więc już wiemy, że jest code snifer. Mam nadzieję, że was odrobinę przekonałem do tego, że faktycznie może być potrzebny. Zresztą też bardzo dużo się nauczyłem dzięki code sniferowi, bo zobaczyłem, że ten code snifer faktycznie nam pokazuje bardzo często. Nawet takie rzeczy, które, byśmy, które działają, które są w porządku, ale bardzo często mówisz, że nie, WordPress sobie życzy, żebyś tej funkcji raczej nie używał, chociaż jest w WordPressie, jest natywną funkcją, ale żeby się ten problem rozwiązywał w zupełnie inny sposób, między innymi w sposób porozmawiania z bazami danych. No i tak, no i zainstalujemy tego code snifera. Jak widzicie w Google, jak zacznę wpisywać code snifer, zobaczymy, że jest w PHP Stormie, jest w NetBeansie, możemy ściągać już różnego rodzaju standardy, nie jest to nic komplikowanego. Ja akurat używam bru, PHP Storma i skorzystałem z Repozytorium GitHub'a, na którym właśnie znajdowało się ten code snifer. Prawde, każdy z nas jest w stanie to chwilę mamy zainstalować, możemy użyć również kompozera, nie ma z nim żadnego problemu. No i pojawia się pytanie, jak już zainstalujemy go, to jak z niego korzystać? Możemy korzystać na przykład w terminalu. Nie jest to nic komplikowanego, właśnie widziałem, wcześniej rozmawiałem z Marcinem Piotrzakiem, którego zresztą pozdrawiam, nie ma go do niestety, on właśnie w terminalu w ten sposób używa swojego code snifera i jak widzimy, no tak się stało, że teraz bardzo dużo rozmawiamy o Gutenberg'u, to pozwoliłem sobie wrzucić główny plik Gutenberg'a do code snifera, jakby nic nie było, ten drugi napis był bezpośrednio pod tym pierwszym, jednak okazało się, że kilka błędów nam wyrzuciło. Są jakieś odstępstwa, niektóre rzeczy, jak widać, wymagają takiego ręcznego sprawdzenia, a to był tylko jeden plik, wrzucałem też inne i było ich dużo więcej, jakoś tak rozmawiałem codziennie o Gutenberg'u, myślałem, że też coś dodał na ten temat, tak? Tak, tu miało być w PHP Storm'ie, ale nie będę włączyć od tego filmu, bo czuję, że mi nie stać się czasu, ale opowiem wam, że w PHP Storm'ie, jak ja używam tego code snifera. Otóż w PHP Storm robicie coś takiego, jak właśnie na bieżąco sprawdza na szkody. Czyli to, co ja muszę zrobić, żeby mój PHP Storm zaczął obsługiwać to, to ściągam, instaluję sobie na moim komputerze, tak jak w moim przypadku, na przykład globalnie, instaluję sobie codziennie snifera. Zainstalowałem tego codziennie snifera, teraz pora, żeby mojemu editorowi, a dokładnie mojemu IDE powiedzieć, gdzie jest codziennie snifera. I to właśnie robię, wybieram się do ustawienia PHP Storm'ie, mówię, tutaj jest plik, który właśnie jest tym codziennie sniferem. PHP Storm przewidział to, że ludzie będą chcieli w nim używać właśnie codziennie snifera i jak już powiemy mu, gdzie jest ten codziennie snifera, i on zwaliduje to i powie, że faktycznie codziennie snifera jest i działa, to wtedy wybieramy się w drugie miejsce w ustawienia naszego PHP Storma i tam wybieramy standard, w którym byśmy chcieli, w którym byśmy chcieli faktycznie dokonywać tej inspekcji, ponieważ nasz PHP Storm, że prowadza mnóstwo inspekcji w trakcie, gdy my piszemy nowy codziennie. I możemy tam dodać właśnie jeszcze jeden mały ptaszek i, ej, codziennie snifera też proszę użyj. Użyj, wybież i sobie z dropdowna wybierzemy standard, którego chcemy przestrzegać. Ogólnie te wszystkie standardy WordPressa są też jakby dodane w tych tzw. rule setach do naszego codziennie snifera, więc możemy je sobie z GitHub'a bez problemu pobrać i dorzucić do plików, w którym znajduje się faktycznie nasz codziennie snifera i będziemy wszystkie standardy widzieli w naszym PHP Stormie. No tak, tak więc zainstowaliśmy sobie tego codziennie snifera i teraz chcielibyśmy dodać jakiś standard, bo wiadomo PHP nasz codziennie snifera ma te standardowe, ma te podstawowe standardy do sprawdzania właśnie tych starych standardów, ale też możemy dodać swoje customowe, możemy je ściągnąć. Ktoś, ludzie przygotowują już standardy, m.in. WordPressa i jakby umożliwiają ich ściągnięcie i rozszerzenie możliwości naszego narzędzia. Ja wam teraz pokażę, jak to zrobić z PHP Compatibility. Najpierw powiem, czym w ogóle jest to PHP Compatibility. Jest to standard, który pozwala nam sprawdzać kompatybilność z wersją PHPa, bo to jest coś, co było mi potrzebne. To jest coś, co właśnie rozwiązało te wszystkie moje problemy z tymi tyketami, o których powiedziałem. Otóż, ja właśnie borykając się z tym problemem, znalazłem to, ściągnąłem, wrzuciłem do... inaczej, od początku. Znalazłem na GitHub'ie, ściągnąłem, wrzuciłem do standardów mojego codziennie snifera, a dokładnie powiedziałem mojemu codziennie sniferowi, gdzie to jest, gdzie on może to znaleźć i zacząłem z tego korzystać. Ustaliłem zaklę, z jakim ma sprawdzać, powiedziałem od 5,3 masz lecieć do 7 i on mi powiedział, ej, zobacz, tak jak pokazywałem wcześniej na tym slajdzie, powiedział, ej, zobacz, tutaj odwołałem się do tego elementu tablicy, a tak nie powinienem się robić. I tak jak mówiłem, ściągamy z repozytorium, rejestrujemy ściągnięty standard codziennie snifera. Czyli jedna linii kodu. Tylko zastrzegam, tam jak widzimy paftu PHP compatibility, to faktycznie musi być, musi być ścieżka absolutna. Dlatego, że ja nie doczytałem tego i mi nie działało. Jak doczytałem, okazało się, że działało. I jak już dodamy to, no to sprawdzamy sobie, mamy PHP CS, to jest właśnie odwołanie do naszego programu codziennie snifera, minus i i to nam listuje wszystkie standardy, które mieliśmy zarejestrowane w naszym codziennie snifera. I jak widzimy, pojawiło się nasze PHP compatibility. Wyobraźcie sobie, że teraz tu instalujemy właśnie po to, żeby sprawdzić, czy nasz codzienny jest kompatybilny z wersją PHP 5.3. No i faktycznie, pojawiło się, jest. No i jak już mamy to zainstalowane, teraz musimy powiedzieć, dla tego standardu PHP compatibility, w jakim zakresie chcemy sprawdzać? No i ja, tak jak mówiłem, chciałem sprawdzić od 5.3. Akurat tutaj na przykładzie jest 5.5, chciałem sprawdzić, czy nie będziecie spać. Ja tak naprawdę źle to wkleję, a później się okazało, że już nie zdążyłem zmienić. Tak więc tam sobie wpisuję, gdzie jest to 5.5, zmieniłem na 5.3 i wybrałem się do mojego PHP Storma, w moim PHP Stormie, przy codziennie snifera powiedziałem, wiesz co, teraz zmieniam na standard PHP compatibility. I zobaczcie, co się dzieje w moim PHP Stormie. Ja pisząc tego rodzaju kod, którego normalnie nie powinienem pisać, pokazuje mi się informacja, że nie powinienem tego robić, bo tego nie ma w wersji 5.3. I to jest dla mnie informacja, że jeżeli ja teraz to wypnę, to znowu zostanę bilety. I tak jak mówiłem, ja ściągnąłem w tym momencie PHP compatibility, moim zdaniem to jest niesamowite narzędzie, polecam je każdemu, ale możemy również ściągnąć sobie standardy WordPressa i możemy przy każdej linii cekodu sprawdzać, czy przestrzegamy danych standardów. Tak jak tutaj widać, jeżeli ściągniemy z GitHub'a ten, to cały repos z tymi standardami, to jest ich więcej niż jeden. Mamy Core, Docs, Extra i Vip. One się w pewien sposób o siebie różnią, nie będę teraz tego omawiał, jednak mniej więcej widać na tej rozpisce, że jedne zawierają się w drugie, jedne są bardziej restrykcyjne w drugie, mniej jeden jest na przykład o dokumentacji, tak? Wszystko naprawdę jest fajnie opisane na GitHub'ie, dlatego zachęcam do wybrania się tam, obejrzenia tego i jest naprawdę bardzo użyteczny. Tak jak mówiłem, zamieniło mojego stażyste w naprawdę ogarniętego człowieka, który wie, co pisze i dlaczego. A mnie to, że miał coś do stażystów oczywiście, bo nie. I tak, i pojawia się pytanie własny standard. Moja odpowiedź to czemu nie. Oczywiście na razie nie chodzi mi o pisanie własnych klas do CodeSyfera, bo to też możemy robić, ale chciałem wam pokazać, że możemy sobie powiedzieć, że słuchaj, chciałbym mieć standard, który łączy kilka innych standardów i dzięki temu na przykład za jednym razem sprawdza dużo więcej niż normalnie. I żeby w ogóle mieć swój własny standard, na pierwszym obrazku widzimy, że stworzyłem pliki XML, muszę go umieścić w folderze z innymi standardami i faktycznie wystarczy tyle kodu, żeby już mieć swój własny standard. To, co ja zrobiłem w tym napisie REF, na tym pierwszym obrazku, WordPress VIP, po prostu chciałem, stworzyłem referencję do innego standardu, wciągnąłem cały standard. I jak widzicie, jak sprawdziłem, okazało się, że jest. I jak sprawdziłem w moim PHP Stormie, okazuje się, że pojawił się wspaniała nazwa SEBA standard. No i jest tak, że możemy zaciągnąć całość, a może cały standard do naszego standardu, a możemy zaciągnąć jakieś sniwy lub ogólnie reguły. No i jak widzicie, ja sobie przejrzałem dokumentację na GitHub'ie i powiedziałem, chciałbym ten global keyword zaciągnąć. Chciałbym wrzucić do swojego super standardu, dlatego że będzie mi to potrzebne. I faktycznie, biorę, dodaję kolejny ruch i piszę najpierw, który standard, potem jakiego języka dotyczy, one są ładnie pogrupowane w folderach i potem piszę global keyword. Błąd, który mi się pojawił, gdy faktycznie to konfigurowałem, był taki, że ja przekleiłem global keyword sniw.php i nie działało. Ale jak skapnałem się po tych 5-10 minutach dlaczego, to naprawiłem i okazało się, że działało, chociaż wiadomo rzadko, kiedy winimy siebie o błąd, a raczej szukamy tego oprogramowania. I tak, możemy oczywiście, zachęcam też odwiedzić dokumentację z CodeSnifer'a. Możemy tam faktycznie znaleźć raz, że dużo takich właśnie metod sprawdzania tego kodu, ale z drugiej strony mamy też możliwość dopasowywania tych metod. To, co ja tutaj zrobiłem, to znalazłem właśnie tego sniwa, czyli ten zespół metod sprawdzania do zakazanych funkcji i zmieniłem sobie, żeby mój ten wspaniały starzysta, gdy za każdym razem, gdy napisz Wardampa, żeby mu ten PHP storm podkreślił, że zamienił to na delete this. Tak, na wszelki wypadek, tak, żeby przypominało mu się, że będzie widział te zygzaki, to się zastanowi dwa razy, czy na pewno to było usunięte, czy nie. No i oczywiście, może jak pokazałem, możemy zaciągać całe, całe standardy, a możemy również zaciągać, możemy również zaciągać pojedyncze sniwy, i te rusety. Możemy sobie stworzyć naprawdę fajny standard, trzymać na jednym repo i poprosić wszystkich współpracowników z firmy, żeby faktycznie też używali tego code snifera. I, tak jak mówiłem, zachęcam do czytania tej dokumentacji, bo jest naprawdę bardzo prosta i można znaleźć dużo fajnych parametrów, które fajnie dopasujemy w jednym pliku i będziemy mieli takie narzędzia, jakie jest nam potrzebne. I tutaj jest właśnie coś, co mi się też bardzo przydało, to jest code quality2 i ogólnie działa w to tak, że możemy właśnie do grumpa HP, nie wiem, czy ktoś słysza o grumpa HP, ktoś używa tego? Nikt nie używa grumpa HP? Okej. Tak, więc to, to jest takie narzędzie, które odpala nam różnego rodzaju zadania tuż przed, tuż przed komitem, i jeżeli który jest tych zadań faktycznie nie przejdzie w taki sposób, jak miało przejść, to ten komit będzie zablokowany. I właśnie do tego możemy podnieść naszego, naszego code sniffera, ten code sniffer określamy, jakie są standardy i określamy ważność błędów i na przykład jaki język ma być i wtedy faktycznie w momencie, w którym odbiegamy od tych standardów, nawet nie jesteśmy w stanie zrobić komita. I dzięki temu, i dzięki temu jesteśmy zobligowani do poprawienia tego. Ale oczywiście czasami musimy zignorować część pliku i tutaj pokazuję, jak zignorować część pliku. Dodajemy po prostu w komentarzu i code sniffer czytając, analizując, widzi dobra, na to nie zwracam uwagi, pójdzie sobie dalej. I podsumowując polecam wszystkim różnego rodzaju narzędzia, które poprawiają jakoś kodu, ale działają też automatycznie. Nie mamy dużo czasu na to, żeby myśleć nad tym, jak piszemy, ale warto jest poświęcić ten jeden dzień, żeby znaleźć narzędzie, które będzie pracowało na naszym komputerze przez następny 10 lat i będzie za każdym razem robiło to samo dobrą pracę. Będzie sprawdzało, bo my jako ludzie popełniamy błędy, komputer oczywiście też, ale komputery popełniają ich znacznie mniej niż ludzie. Nie oszukujmy się, tak jest. I to w sumie wszystko, co chciałem wam dzisiaj pokazać.