Programiści WordPress: Zacznij tutaj!

Opublikowany: 2017-10-14

Witamy w naszym przewodniku startowym dla programistów WordPress! Niezależnie od tego, czy pracujesz jako freelancer, czy w agencji medialnej. W tym artykule omówimy różne tematy związane z rozwojem WordPressa wraz z niektórymi dostępnymi zasobami i narzędziami.
Tekst jest zorganizowany wokół różnych etapów, które przepływają między generowaniem pomysłów a wysyłką. Porozmawiamy o burzy mózgów, prototypowaniu, rozwoju i wreszcie o wdrożeniu. Wszystko to w kontekście rozwoju produktu. Wierzymy, że pomiędzy pierwszymi przebłyskami pomysłu a jego ostatecznym wykonaniem istnieje wiele subtelnych obszarów. Niektóre pozostają w najlepszym razie nieomówione, a inne w najgorszym przypadku są całkowicie niezbadane w obecnej literaturze WordPress.

Jeśli jesteś klientem Pressidium, możesz od razu zacząć korzystać z narzędzi, które zbudowaliśmy wokół naszej platformy, abyś mógł czerpać korzyści z wysokiego poziomu integracji. Porozmawiamy o tym, jakie są te narzędzia. Proszę pamiętać, że jest to dokument na żywo i tak należy go traktować.

Przede wszystkim naszym celem jest, aby ten dokument był przydatny w Twojej praktyce jako programisty WordPress, a po drugie, aby pokazać Ci kilka fajnych rzeczy, które zbudowaliśmy specjalnie dla Ciebie.

Od pomysłu do wdrożenia

Niezależnie od tego, czy pracujesz nad nowym produktem, czy też zajmujesz się pracą u klienta, proces przejścia od pomysłu do wdrożenia składa się z 4 etapów. Chociaż te etapy są dyskretne, znacznie się pokrywają i nie są liniowe. Omówimy to w dalszej części tekstu:

Burza mózgów i pozyskiwanie wymagań.
Prototypowanie.
Rozwój.
Zastosowanie.

Proces wolnej burzy mózgów asocjacyjnej jest używany, gdy chcesz rozpocząć tworzenie produktu lub projektu i potrzebujesz pomysłów. Zbieranie wymagań ma jednak miejsce, gdy masz za zadanie zbudować projekt dla klienta lub zakończyć pomysł po burzy mózgów. Nadal możesz zorganizować później sesje burzy mózgów, aby rozwiązać określone problemy, ale te sesje będą bardziej ograniczone.

Podstawowe zasady burzy mózgów to dwie. Postaw na ilość i odłóż osąd na później. W przeszłości pisaliśmy o tym, jak możesz ułatwić taką sesję, jak zbudować właściwy sposób myślenia i o kilku odjechanych narzędziach, które pomogą Ci w tym.

Wywoływanie wymagań

Istnieje kilka metodologii służących do pozyskiwania wymagań i tradycyjnie zawsze było to dziełem analityka biznesowego. Chociaż obowiązkiem klienta jest dostarczenie informacji o wymaganiach projektowych, należy ustalić wspólne zrozumienie dla wszystkich interesariuszy. Pozyskiwanie wymagań to inny proces niż zbieranie wymagań. Bardziej chodzi o wydobywanie niezbędnych informacji poprzez aktywne uczestnictwo. I nie chodzi tu o bierne gromadzenie w dokumencie tego, co klient ci mówi, i przekazywanie tego zespołowi programistycznemu.

W zależności od zakresu i charakteru projektu, Use Cases to świetny sposób na uchwycenie funkcjonalności. Przypadki użycia to technika używana w diagramach UML jako sposób opisywania interakcji między interesariuszami systemu a samym systemem. Ponieważ są one zbiorem scenariuszy napisanych prostym, ale ustrukturyzowanym językiem angielskim, nie tylko są mniej skomplikowane, ale także są szybkim i skutecznym sposobem na rozpoczęcie omawiania i szkicowania funkcjonalności systemu.

Prawdopodobnie będziesz musiał zorganizować ustrukturyzowane wywiady ze wszystkimi zainteresowanymi stronami, jeśli chcesz uchwycić wymagania dotyczące złożonych produktów. W tym celu Historie użytkowników są idealnym rozwiązaniem. Są częścią sposobu myślenia Agile i są nieformalnym sposobem na rozpoczęcie rozmowy o wymaganiach w celu budowania wspólnego zrozumienia. Krótkie opisy funkcjonalności są zapisywane na papierowych kartkach, zwykle Post-It Notes, i są przetasowane na tablicy, aby stworzyć narrację podróży użytkownika. Historie użytkowników generowane są na miejscu, poprzez uczestnictwo, dyskusję i manipulowanie kartami na tablicy. Szczegóły są powoli dopracowywane i ostatecznie dodawane jako funkcje w rejestrze produktu. Jeff Patton napisał znakomitą książkę na temat mapowania historii użytkownika, którą gorąco polecamy, jeśli chcesz dowiedzieć się więcej na ten temat i zacząć używać jej w swoich projektach.

Historyjki użytkowników nie są statyczną rzeczą, która raz stworzona jest na zawsze zapomniana. Zamiast tego są dynamiczną mapą, do której zespół ds. rozwoju i produktu może powracać raz za razem, gdy następuje etap prototypowania, a produkt zaczyna nabierać kształtu.

Ważność prototypu polega na odpowiadaniu na pytania. Chociaż istnieje kilka metodologii prototypowania, uważamy, że ta ewolucyjna jest najodpowiedniejsza dla naszych celów i ta, którą można dostosować do nowoczesnych potoków programistycznych Agile. W metodologii ewolucyjnego prototypu proces ma charakter cykliczny, w którym prototyp staje się coraz bardziej udoskonalany w każdym cyklu.

Każda iteracja prototypu przechodzi z fazy projektowania do fazy rozwoju i oceny. Ujawnia problemy na wczesnym etapie projektowania i zapewnia coś namacalnego, na co ludzie mogą wskazać i porozmawiać o tym, co można ulepszyć. Informacje zebrane w fazie oceny są wykorzystywane w kolejnej iteracji prototypu, a cykl powtarza się ponownie. W ten sposób prototyp powoli ewoluuje do końcowego systemu, aż osiągnie dojrzałość jako gotowy produkt.

Prototypowanie zwykle odbywa się w szybkim tempie rozwoju, a korzystanie z systemów szablonowych, takich jak Bedrock, Sage i Bootstrap, może znacznie skrócić czas tworzenia. Systemy takie jak te wymienione powyżej zapewniają kompletny szkielet aplikacji i niezbędny łańcuch narzędzi, dzięki czemu nie będziesz musiał za każdym razem zaczynać od zera. Prototypy ewolucyjne to nie to samo, co prototypy jednorazowe. Te ostatnie to prototypy, które są budowane tylko raz jako dowód koncepcji, a następnie wyrzucane. Jeśli spędzasz dużo czasu na tworzeniu prototypu e-commerce, dlaczego nie wyabstrahować wspólnych funkcjonalności i użyć ich ponownie w przyszłości, zamiast wyrzucać wszystko i zaczynać od zera?

Tutaj przydaje się Pressidium Cloning. Pozwala szybko sklonować witrynę jednym kliknięciem i zacząć się rozwijać. W ten sposób możesz przygotować wiele szablonowych witryn internetowych za pomocą boilerplate’u, wstępnie załadować je z niezbędnymi wtyczkami, motywami i konfiguracją oraz sklonować je za każdym razem, gdy potrzebujesz ich w projekcie. Możesz je również sklonować na inne konto Pressidium, na przykład na konto swojego klienta, w ten sam sposób. Nie martw się, jeśli Twoje prototypy znajdują się u innego zarządzanego dostawcy hostingu WordPress. Po prostu użyj naszego Kreatora migracji i zaimportuj je na swoje konto Pressidium!

Bez względu na to, czy tworzysz projekty WordPress samodzielnie, czy współpracujesz z innymi programistami i projektantami WordPress, dwa najważniejsze punkty, które przyczyniają się do zrównoważonego rozwoju Twojego rzemiosła w dłuższej perspektywie, to:

Ćwiczenie dobrych nawyków związanych z oprogramowaniem.
I wiedząc, czym wszystko jest, gdzie jest i dlaczego tam jest.

Najlepsze praktyki różnią się od konsekwentnego przestrzegania przewodnika po stylu oprogramowania, poprzez ćwiczenie pisania czystego kodu zamiast sprytnego, aż do wyboru oprogramowania wysokiego poziomu i projektowania interfejsu użytkownika. Drugi punkt to po prostu dokumentacja i wiele form, jakie może ona przybrać wewnątrz projektu.

Stosowanie się do przewodnika po stylu oprogramowania jest proste. Zapoznaj się z oficjalnymi zasobami WordPress.org na ten temat, a następnie zdecyduj, które wytyczne mają dla Ciebie sens, aby uwzględnić je w swoim stylu kodowania. Zmiana nawyków to powolny proces i powinieneś zacząć od wprowadzenia małych zmian na początku. Ostatecznie posiadanie zestawu wytycznych, których musi przestrzegać Twój kod, oznacza wprowadzenie w pewnym momencie przeglądu kodu.

Przeglądy kodu to systematyczny sposób czytania i sprawdzania kodu, który ma na celu wyeliminowanie błędów, wyjaśnienie części kodu, które są zawiłe, oraz zapewnienie, że kod jest zgodny ze standardami i konwencjami. Najlepiej też, żeby to zrobił ktoś inny z twojego zespołu, a nie ty.

Preferowanie czystego kodu od sprytnego to programistyczna „perła mądrości”, którą niestety można docenić dopiero po wpadnięciu w pułapki sprytnego kodu. Wniosek jest taki: chociaż w niektórych przypadkach sprytny kod może przynieść ci punkty „hakerskie” i poklepać po plecach, a nawet wzrost wydajności w niektórych przypadkach, ostatecznie tracisz na dłuższą metę. Kod, który jest „hackowy” i trudny do odczytania, stanie się w przyszłości niezrozumiały. I może cię to kosztować, gdy będziesz musiał rozwiązać szczególnie nieuchwytny błąd. Znalezienie równowagi między pisaniem zoptymalizowanego i czystego kodu jest czymś, co musisz odkryć dla siebie, ale zawsze lepiej jest błądzić po czystej stronie.

Ponieważ wydajność witryn WordPress zależy w dużej mierze od prawidłowego korzystania z pamięci podręcznej przeglądarki, ważne jest, aby wiedzieć, w jaki sposób zarządzany dostawca hostingu WordPress korzysta z pamięci podręcznej. Twój kod będzie wtedy działał synergicznie z Twoją platformą hostingową, aby uzyskać najlepszą możliwą wydajność. Pamiętaj jednak, że pomiar szybkości Twojej witryny we właściwy sposób nie jest tak łatwy, jak mogłoby się wydawać, i zawiera kilka wad!

Tak więc, mówiąc o najlepszych praktykach wysokiego poziomu, decyzja, która doprowadziła do oddzielenia przez WordPress swojej podstawowej funkcjonalności i udostępnienia interfejsu API REST, z pewnością może być uważana za przykład takich praktyk. Ta decyzja sygnalizowała przejście w nową erę, w kierunku programistycznych systemów zarządzania treścią i „bezgłowego” rozwoju aplikacji WordPress.

Napisaliśmy zwięzłe wprowadzenie i samouczek do interfejsu API REST WordPressa oraz prosty sposób na rozpoczęcie pracy z nim za pomocą wtyczek przeglądarki, takich jak Postman.

Ta decyzja dotycząca projektowania oprogramowania była zwodniczo prosta, ale potężna. Programista WordPress może teraz używać WordPressa do wdrażania aplikacji i funkcji, które znacznie przewyższają możliwości witryn internetowych lub blogów. Jednym szczególnie trafnym przykładem jest nasz prototyp Kanban.

Wykorzystaliśmy elementy WordPress, takie jak kategorie i posty, aby zamodelować tablicę Kanban z zadaniami, kolumnami i strumieniem wartości. Naszkicowaliśmy interfejs API kolumn i kart Kanban, który łączy wszystko w całość.

Dokumentacja

Można by argumentować, że najlepsze praktyki w zakresie oprogramowania sprzyjają pisaniu lepszej dokumentacji, od prostych komentarzy do kodu, po elementy dostarczane projektu, a kończąc na kopii produktu.

Bez względu na to, jak na to spojrzysz, dokumentacja jest atutem.

Jeśli chodzi o dokumentację techniczną, język używany na piśmie zdecydowanie różni się od tego, którym posługujesz się na co dzień, czy tego, którym posługujesz się w pracy. Ta forma pisania nazywa się pismem technicznym i nie jest używana tylko w komputerach lub inżynierii oprogramowania. W rzeczywistości jest używany we wszystkich zawodach, które muszą przekazywać koncepcje techniczne odbiorcom specjalistycznym, takim jak prawo, medycyna, aeronautyka i tak dalej. To duży temat, a istnieją nawet uczelnie, które oferują certyfikaty z pisania technicznego. Jego raison d'etre jest przekazywanie informacji technicznych jasnym i zwięzłym językiem. Głos czynny jest preferowany od biernego, przy czym ten drugi jest używany w przypadkach, gdy do wyjaśnienia pojęć potrzebny jest tekst opisowy.

Pisarz techniczny musi mieć na uwadze, że czytelnik to ktoś, kto często jest sfrustrowany, szukając określonej informacji. W rezultacie Twoje pisanie nie musi stać na przeszkodzie. Jego celem jest uczynienie tego procesu łatwym, prostym, a nawet przyjemnym!

Chociaż nie musisz mieć stopnia naukowego ani być profesjonalnym pisarzem technicznym, wiedza o tym, jak komunikować koncepcje w zwięzły i prosty sposób, jest bardzo ważna dla Twojej kariery jako programisty WordPress. Dlatego za każdym razem, gdy potrzebujesz napisać dokumentację wtyczki, motywu lub interfejsu API, który zbudowałeś (z którego jesteś dumny!), musisz mieć podstawy. Z tego powodu napisaliśmy krótki przewodnik po dokumentowaniu wtyczek i motywów WordPress, który obejmuje również 5 podstawowych zasad pisania technicznego.

Ale dokumentacja na tym się nie kończy. W przypadku, gdy Twój motyw lub wtyczka jest częścią większego projektu lub gdy same są wystarczająco złożone, należy zacząć myśleć w kategoriach dokumentacji produktu. Dodając do prawdy, że dokumentacja jest atutem, dokumentacja produktu z kolei jest atutem marketingowym. Jest to trafnie ujęte w następującym cytacie Mike'a PuterBaugh, wiceprezesa ds. marketingu w MindTouch, w artykule Mashable o znaczeniu dokumentacji produktu:

Nie jest to seksowne przedsięwzięcie, ale zapewni ci szacunek rówieśników, skuteczniejsze zarządzanie firmą i bardziej współpracujący zespół. Bo nie chodzi o ten kwartał czy ten rok, ale raczej o wpływanie na przewagę konkurencyjną i długoterminowy wzrost.

Jeśli chodzi o produkt, poza najczęstszymi formami pisemnej dokumentacji istnieje kilka innych, takich jak pomoc online, przewodniki stylistyczne, mikrotreść i tak dalej. Dokumentacja produktu jest zwykle tworzona we współpracy wielu różnych osób, co dodaje dodatkową warstwę złożoności. Napisaliśmy obszerny przewodnik, który pomoże Ci również w ten sposób zacząć myśleć i planować.

Na koniec, gdy przechodzimy do ostatniego etapu procesu, którym jest wdrożenie, umieszczamy ostatni element układanki z dokumentacją: Diagramy wdrażania. Pomagają one w uzyskaniu jasnego i sferycznego wyobrażenia o tym, czym wszystko jest i gdzie powinno być.

Chociaż większość ludzi uciekłaby krzycząc z przerażenia słysząc o UML (co jest całkiem zrozumiałe, pełna specyfikacja UML jest fatalna), na swoją obronę UML zawiera podzbiór narzędzi notacyjnych, które mogą dodać wartość do projektu. Diagramy wdrożeniowe to zaskakująco prosta notacja składająca się tylko z węzłów i ścieżek komunikacyjnych, które mogą pokazać w mgnieniu oka różne środowiska istniejące w projekcie oraz miejsca, w których należy wdrożyć każdy komponent.

W przyszłości zagłębimy się bardziej w UML, w szczególności w inną użyteczną notację o nazwie Diagramy Sekwencji, a także w bardziej szczegółowe przykłady diagramów scenariuszy przypadków użycia, aby uszczegółowić wymagania projektu i zbudować prototypy.

Większość, jeśli nie wszystkie współczesne programowanie i wdrażanie, wykorzystuje jakąś formę kontroli wersji, taką jak git i SVN. Repozytoria kodu źródłowego są niezbędne nie tylko dla samych zespołów, ponieważ ich zalety są ogromne, nawet jeśli jesteś samotnym programistą WordPress.

Jeśli jesteś klientem Pressidium, możesz zintegrować swoje repozytorium ze swoim kontem przez SFTP, korzystając z usługi zewnętrznej, takiej jak deploybot. Alternatywnie możesz użyć SFTP do przeniesienia plików na swoje konto, ponieważ jest to najłatwiejsza i najprostsza metoda. Możesz także utworzyć wielu użytkowników SFTP i przypisać ich do określonych witryn i środowisk. Skoro o tym mowa, posiadanie środowiska pomostowego dla Twojej witryny zapewnia, że proces tworzenia i wdrażania jest bardziej uproszczony, a Twoja witryna produkcyjna jest chroniona przed niechcianymi zmianami. Na przykład po włączeniu przemieszczania dla swojej witryny internetowej możesz pobrać kopię z produkcji, a następnie utworzyć konto SFTP dla programisty, które ma dostęp tylko w środowisku przejściowym.

Skonfigurowanie usprawnionego potoku programistycznego przechodzącego przez wiele środowisk to jedna ze zmian, które ruch DevOps wniósł do środowisk IT. Przyjęcie dyscypliny Continuous Delivery i stopniowe i częste wypychanie zmian oprogramowania skutkuje szybszymi cyklami wdrażania i mniejszą liczbą błędów. Nie musisz już utrzymywać archiwów ZIP z różnymi wersjami aplikacji. W ten sposób możesz łatwo stracić orientację i wdrożyć niewłaściwy zestaw zmian, które mogą zaszkodzić Twoim systemom produkcyjnym. Istniało również niebezpieczeństwo wystąpienia problemów z uprawnieniami do plików, które zostały zniekształcone, co w najlepszym przypadku może spowodować nieprawidłowe działanie aplikacji, a w najgorszym może spowodować problemy z bezpieczeństwem.

Epilog

Wiemy, że Twój wolny czas jako programisty WordPressa jest dość ograniczony. Dlatego skonsolidowaliśmy wszystko w jednym dokumencie, ponieważ przeciążenie informacjami jest prawdziwe i wydaje się, że wpływa na wszystkich pracowników wiedzy, a nie tylko programistów WordPressa. Wspomnieliśmy na początku, że naszym celem jest po pierwsze dostarczenie przydatnych informacji, a po drugie zajęcie się tematami, które naszym zdaniem są niedostatecznie reprezentowane w aktualnej literaturze dotyczącej WordPressa. Zostanie programistą WordPressa to jedno, a pozostawanie aktualnym i konkurencyjnym to drugie . Aby to zrobić, musisz mieć wszechstronne spojrzenie na inżynierię oprogramowania jako dyscyplinę i nabyć dobre nawyki, metodologie i techniki, które będą służyć Twojej karierze w dłuższej perspektywie.