Pamiętam, jak założyłem swój pierwszy blog WordPress. Spędziłem godziny śledząc przewodniki online, aby pobrać WordPress, próbując go przesłać ponownie, a następnie zastanawiając się, jak skonfigurować bazę danych.


Po prostu prześledziłem każdą zmianę aż do serwera na żywo i miałem nadzieję, że blog nie zgasł, jeśli źle wpisałem znak zapytania.

W międzyczasie WordPress wyrósł. Masowe firmy medialne wykorzystują WordPress jako główny sposób komunikowania się ze światem. Przejdź do Tech Crunch lub New Yorker i zobacz źródłowy HTML. Przekonasz się, że witryna została zbudowana przy użyciu WordPress. Beyonce? Tak. Kopie WordPress.

Jednocześnie WordPress ma tę okropną reputację wśród programistów. Stereotyp polega na tym, że dzieciaki skryptów przesyłają pliki przez FTP, bez kontroli wersji i ogólnie porzucają każdą rozsądną zasadę rozwoju oprogramowania znaną ludzkości.

Oczywiście nie jest to uczciwy zarzut. WordPress wyrósł. Robi się pełnoprawny Interfejs API REST W tym roku. Możesz teraz zainstalować WordPress i zależności z wiersza poleceń, używając WP-CLI.

Dorastają twórcy WordPress i projektanci motywów. Roots.io jest przykładem traktowania projektów WordPress jak każdego poważnego projektu rozwoju oprogramowania. Nie zawracają sobie głowy przesyłaniem FTP metodą przeciągania i upuszczania. Zamiast tego używają git do kontroli wersji i capistrano do wdrożeń.

Joel z Fog Creek Software, o której słynie napisał 12 kroków do lepszego oprogramowania, a jednym z nich był moduł do śledzenia problemów lub błędów. On ma rację. Trudno zapamiętać wszystkie różne żądania funkcji i błędy w twojej głowie. Jeszcze trudniej jest zapamiętać wszystkie etapy odtwarzania błędów, czego oczekiwał użytkownik i co faktycznie otrzymał.

Na biurku jest też tak wiele notatek samoprzylepnych. Sam WordPress używa Trac jako narzędzie do śledzenia problemów. Współpracowałem z Redmine, innym narzędziem do śledzenia problemów i zarządzania projektami typu open source, ponieważ pracuję w Planio, która oferuje hostowane usługi Redmine i git hosting.

Typowy przypadek użycia modułu do śledzenia problemów

Wyobraź sobie, że tworzysz nową wtyczkę do WordPress. Masz mały zespół w pracy – programistę lub dwóch, projektant i biznesmen.

Nie jesteś już zespołem tylko jednej osoby. Nie wszyscy pracują w jednym miejscu, ponieważ, cóż, praca zdalna jest niesamowita, a północna półkula nie sprawia tyle radości w zimie.

Użytkownik wysyła wiadomość e-mail z informacją, że wtyczka „nie działa”. Jeśli masz szczęście, otrzymasz zrzut ekranu z komunikatem o błędzie „nie działa”.

Prześlij dalej wiadomość e-mail. Ktoś odsyła e-maila z pytaniem o używaną przeglądarkę i nagle masz wątek Gmaila zawierający 12 e-maili. Jest tutaj kilka problemów, a moduły do ​​śledzenia problemów pomagają je rozwiązać.

Trzy krytyczne elementy każdego możliwego do naprawienia błędu

Po pierwsze, do każdego zgłoszenia błędu potrzebne są trzy rzeczy:

  1. Jakie kroki podjął użytkownik, które spowodowały błąd?
  2. Czego spodziewał się użytkownik?
  3. Co faktycznie zobaczył użytkownik?

Musisz być w stanie odtworzyć błąd, ponieważ naprawienie błędu, którego nie widać w akcji, jest naprawdę trudny. Po drugie, musisz upewnić się, że błąd jest w rzeczywistości błędem lub czy użytkownik oczekiwał czegoś, czego nie zapewnia twoje oprogramowanie.

Oto inny sposób ujęcia:

I nie można odrzucić osoby zgłaszającej błąd za pomocą klasycznej linii: „To nie jest błąd. To jest funkcja!”, Jeśli nie wiesz, czego dana osoba się spodziewała.

Korzystanie z narzędzia do śledzenia problemów, takiego jak Redmine oznacza, że ​​masz ustandaryzowany sposób otrzymywania tych informacji.

Jest jeden sposób, aby upewnić się, że zadanie nigdy nie zostanie wykonane: niejasno zasugerował, że zespół powinien coś z tym zrobić. Jeśli nie zostanie przypisany do jednego „właściciela”, po prostu się nie da.

Śledzące problemy zmuszają cię do przypisania problemu, no cóż, jednej osobie w danym momencie, dzięki czemu zawsze wiesz, kto jest obecnie właścicielem błędu lub zadania. Jednocześnie problemy przechodzą przez przepływ różnych statusów, takich jak „W toku”, „Kontrola jakości / Testowanie” lub „Gotowy do wdrożenia”.

Większość modułów śledzących przekazuje Ci raporty na podstawie aktualnego stanu problemu, dzięki czemu możesz zobaczyć bieżącą ilość prac w toku i ile pozostało do zrobienia. Możesz nawet tworzyć wykresy wypalenia, które są spopularyzowane w zwinnych metodologiach.

Ściśle zintegruj Git z obiegiem zarządzania projektami

Jak wspomniano powyżej, użycie git w procesie rozwoju WordPress znacznie ułatwi ci życie, gdy coś pójdzie nie tak. Git daje ci przycisk przewijania do tyłu w kodzie i możesz utworzyć wiele równoległych wersji swojej witryny.

Za każdym razem, gdy „zatwierdzasz” nowy kod do swojego repozytorium git, tworzysz naturalny punkt, aby omówić zmianę w bazie kodu. Ponadto uważam, że łatwiej jest omawiać problemy na podstawie faktycznie popełnionego kodu, a nie tylko niejasnych pomysłów.

Właśnie tam świecą moduły do ​​śledzenia problemów, ponieważ na przykład Redmine jest ściśle zintegrowany z git lub svn. Możesz szybko zobaczyć, kto popełnił błąd, a następnie omówić te problemy.

Utwórz system do rozwoju WordPress

Narzędzie do śledzenia problemów pomoże Ci skalować się nie tylko ty. Będziesz mieć pewność, że problemy nie prześlizgują się przez pęknięcia.

W Planio większość naszych klientów korzysta z naszego hostowanego Redmine w celu śledzenia projektów rozwoju oprogramowania, w tym projektów WordPress. Śledzą błędy, nowe funkcje i sprinty związane z kontrolą wersji.

Redmine, podobnie jak WordPress, jest oprogramowaniem typu open source, więc masz tę zaletę, że nie jesteś zamknięty w oprogramowaniu zastrzeżonym. Podobnie jak WordPress, możesz zlecić hosting komuś takiemu jak my w Planio, lub możesz zainstalować go sam, jeśli wolisz Redmine.org.

Do Ciebie

Więc – jak zarządzać przepływem pracy? Czy próbowałeś Redmine? Chcielibyśmy usłyszeć twoje przemyślenia i komentarze poniżej!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me