W artykule:
Pamiętam, że założyłem swojego pierwszego bloga WordPress. Spędziłem godziny podążając za przewodnikami online, aby pobrać WordPress, próbując przesłać go ponownie, a następnie dowiedzieć się, jak skonfigurować bazę danych.
Po prostu FTP ’ em każdą zmianę aż do serwera na żywo, i nadzieję, że blog nie ściemni, jeśli źle wpisałem znak zapytania.
WordPress wyrósł w międzyczasie. Ogromne firmy medialne używają WordPress jako głównego sposobu komunikowania się ze światem. Przejdź do Tech Crunch lub New Yorker i zobacz kod źródłowy html. Przekonasz się, że strona jest zbudowana przy użyciu WordPress. Beyonce? Tak. Lubi WordPressa.
W tym samym czasie WordPress ma tę straszną reputację wśród programistów. Stereotyp to script kiddies przesyłające pliki przez FTP, nie używające kontroli wersji i generalnie porzucające wszelkie rozsądne zasady tworzenia oprogramowania znane ludzkości.
Oczywiście, to nie jest uczciwe oskarżenie. WordPress wyrósł. W tym roku otrzyma pełnoprawne API REST. Możesz teraz zainstalować WordPress i zależności z wiersza poleceń za pomocą WP-CLI.
Programiści WordPress i projektanci motywów dorastają. Roots.io jest przykładem traktowania projektów WordPress jak każdego poważnego projektu programistycznego. Nie zadzierają z przesyłaniem FTP metodą przeciągnij i upuść. Zamiast tego używają git do kontroli wersji i capistrano do wdrożeń.
Joel z Fog Creek Software słynnie napisał o 12 krokach do lepszego oprogramowania, a jednym z nich był problem lub śledzenie błędów. Ma rację. Trudno zapamiętać wszystkie różne prośby o różne funkcje i błędy w głowie. Jeszcze trudniej jest zapamiętać wszystkie kroki w celu odtworzenia błędów, czego oczekiwał użytkownik i co faktycznie otrzymał.
Na biurku jest tylko tyle notatek. Sam WordPress używa Trac jako swojego trackera problemów. Pracowałem z Redmine, innym narzędziem do śledzenia problemów i zarządzania projektami open-source, ponieważ jestem w Planio, który oferuje hostowany Hosting Redmine i GIT.
Typowy przypadek użycia trackera problemów
Wyobraź sobie, że budujesz nową wtyczkę do WordPress. Masz mały zespół w pracy-programista lub dwóch, projektant i biznesmen.
Nie jesteście już zespołem tylko jednej osoby. Nie wszyscy pracują w jednym miejscu, ponieważ, cóż, praca zdalna jest świetna, a półkula północna nie jest tak fajna w zimie.
Użytkownik wysyła wiadomość e-mail z informacją, że wtyczka „nie działa”. Jeśli masz naprawdę szczęście, otrzymasz zrzut ekranu pokazujący komunikat o błędzie „nie działa”.
Prześlij e-mail dookoła. Ktoś odpisuje z pytaniem, jakiej przeglądarki używał, i nagle masz wątek Gmaila z 12 e-mailami. Jest tu kilka problemów, a śledzenie problemów pomaga rozwiązać te problemy.
Trzy krytyczne części każdego naprawialnego błędu
Po pierwsze, potrzebujesz trzech rzeczy do każdego zgłoszenia błędu:
- Jakie kroki podjął użytkownik, który spowodował błąd?
- Co użytkownik spodziewał się zobaczyć?
- Co tak naprawdę zobaczył użytkownik?
Musisz być w stanie odtworzyć błąd, ponieważ naprawdę trudno jest naprawić błąd, którego nie widać w akcji. 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 tego:
Zasady zgłaszania błędów przez rodzica:
– Co chciałeś, żeby program ci dał?
– Co zrobiłeś z programem?
– Jakie to dla ciebie znaczyło?– Steve Purcell (@sanityinc) 29 października 2015
I nie można odczepić osoby zgłaszającej błąd klasyczną linią:”To nie robak. To cecha!„jeśli nie wiesz, czego oczekuje osoba zamiast.
Korzystanie z trackera problemów, takiego jak Redmine, oznacza 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ć. Chyba, że jest przypisany do jednego „właściciela”, to po prostu nie zostanie zrobione.
Śledzenie problemów zmusza cię do przypisania problemu do, cóż, jednej osoby w danym momencie, więc zawsze wiesz, kto aktualnie jest właścicielem błędu lub zadania. W tym samym czasie sprawy przechodzą przez przepływ pracy o różnych statusach, takich jak „w toku”, „QA/Testing” lub „Ready for Deployment”.
Większość trackerów wyświetla raporty oparte na aktualnym statusie sprawy, dzięki czemu możesz zobaczyć aktualną ilość prac w toku i ile pozostaje do zrobienia. Możesz nawet tworzyć wykresy wypalenia, które są spopularyzowane w metodykach zwinnych.
Ścisła integracja Git z przepływem pracy zarządzania projektami
Jak wspomnieliśmy powyżej, Korzystanie z git w procesie tworzenia WordPress sprawi, że Twoje życie będzie o wiele łatwiejsze, gdy coś pójdzie nie tak. Git daje Ci przycisk przewijania na swoim kodzie, i można utworzyć wiele, równoległe wersje witryny.
Za każdym razem, gdy „zatwierdzasz” nowy kod do repozytorium git, tworzysz naturalny punkt do omówienia zmiany w bazie kodu. Ponadto uważam, że łatwiej jest omawiać problemy w oparciu o rzeczywisty kod, a nie tylko niejasne pomysły.
To jest, gdzie śledzenie problemów świecą, ponieważ Redmine, na przykład, jest ściśle zintegrowany z git lub svn. Możesz szybko zobaczyć, kto popełnił co przeciwko problemom, a następnie omówić te problemy.
Stwórz System dla swojego rozwoju WordPress
Śledzenie problemów pomoże Ci skalować się poza samym sobą. Będziesz mieć pewność, że problemy nie prześlizgną się przez szczeliny.
W Planio większość naszych klientów korzysta z hostowanego Redmine w celu śledzenia projektów rozwoju oprogramowania, w tym projektów WordPress. Śledzą błędy, nowe funkcje i sprinty w związku z kontrolą wersji.
Redmine, podobnie jak WordPress, jest open source, więc masz tę zaletę, że nie jesteś zablokowany w zastrzeżonym oprogramowaniu. I podobnie jak WordPress, możesz zlecić hosting komuś takiemu jak my w Planio, lub możesz zainstalować go samodzielnie, jeśli wolisz od Redmine.org.
Over To You
Więc-jak zarządzać przepływami pracy? Próbowałeś Redmine? Chcielibyśmy usłyszeć twoje myśli i komentarze poniżej!
