Organic Food Boutique Store

Organic Food Boutique Store to zespołowy projekt z bootcampu: witryna sklepu dla serwisu subskrypcji żywności, zbudowana na REST API dostarczonym przez kurs. W dziewięć osób commitowaliśmy do jednego repozytorium, które należy do innej osoby z zespołu, a nie do mnie — dlatego to studium przypadku zaczyna się od rysunku pokazującego, które obszary strony napisałem, zamiast od zrzutu ekranu całości.

Pracę podzieliliśmy według komponentów. Każdy wziął fragment strony — nagłówek, hero, filtry, listę produktów, popularne produkty, produkty z rabatem, okna modalne, koszyk — zbudował go na osobnej gałęzi i otworzył pull request do main; weszło ich w ten sposób pięćdziesiąt osiem, a tytuły mówią, kto zrobił co. Byłem scrum masterem sprintu: co wieczór prowadziłem stand-up i pilnowałem tablicy zadań.

Termin wynosił tydzień. Zrobiło się z niego dziesięć dni.

Żadne z nich nie pochodziło od klienta. To zwykłe warunki budowania jednej podstrony witryny, podczas gdy osiem innych osób buduje resztę — i każdy z nich przesądził o tym, co mogłem skończyć i kiedy.

Dwie z nich podjąłem świadomie. Trzecia rzecz, którą zrobiłem, też była decyzją, ale wtedy jej za taką nie uznałem, więc jest w ostatniej sekcji, a nie tutaj.

Koszyk jest węzłem tej witryny. Wszystko inne na stronie to liść — filtr, karta, okno modalne — a koszyk jest jedynym miejscem, w którym API, zapisany stan, cudzy markup i cudzy licznik w nagłówku muszą się ze sobą zgadzać w tej samej chwili.

Co czyta. Produkty i ilości przychodzą przez serwis API i wrapper na storage; oba istniały, zanim otworzyłem plik. Nie napisałem transportu i nie napisałem zapisu danych. Napisałem część pomiędzy, która zamienia to, co zapisane, w to, co widać na ekranie.

Co zapisuje. Zmiana ilości, usunięcie pozycji i opróżnienie koszyka wracają do storage, a stamtąd czytają zarówno suma zamówienia, jak i znaczek w nagłówku. Dwie z trzech rzeczy czytających tę liczbę należały do innych osób, dlatego licznik jest na tej stronie wartością najbardziej narażoną na niezgodność między autorami.

Co renderuje. Wiersze są budowane z zapisanych pozycji, a nie wpisane w dokument, więc zmiana ilości renderuje wiersz i sumy na nowo z jednego źródła, zamiast aktualizować trzy miejsca z nadzieją, że będą się zgadzać.

Sekcja hero, na drugim arkuszu. Nagłówek, podtytuł i grafika hero na górze katalogu, z jednym słowem nagłówka zmieniającym kolor w pętli. To jedyna rzecz, jaką napisałem w tej witrynie, którą recenzent może zobaczyć w działaniu bez otwierania pliku.

Gdzie skończyła się moja praca. Koszyk wszedł jednym pull requestem pod koniec sprintu, a tego samego popołudnia przyszły po nim dwa commity właściciela repozytorium — jeden z nich naprawiał aktualizację koszyka przy zmianie ilości. Historia commitów jest uczciwym zapisem tej granicy, a studium przypadku, które przypisałoby mi tę stronę w całości, zostałoby przez nią obalone w mniej więcej minutę.

Witryna działa, a repozytorium jest publiczne. To, co napisałem, jest narysowane powyżej, obszar po obszarze, z plikiem, liczbą commitów albo gałęzią przy każdej notce — więc całe to twierdzenie może sprawdzić w historii commitów każdy, kto zechce poświęcić na to minutę.

Nie ma tu żadnej metryki rezultatu i nie będzie. Zespołowy projekt z bootcampu nie ma klienta, ruchu ani usługi w Search Console: nikt nigdy nie miał robić zakupów w tym sklepie, nic nie miało konwertować i nic nie było mierzone po prezentacji. Studium przypadku obdukcje podaje pozycje i wyświetlenia, bo wytworzyła je prawdziwa strona i mogę je co miesiąc sprawdzać. To podaje, co zostało wdrożone, bo to wszystko, co istnieje.

Co da się sprawdzić, jeśli ktoś ma ochotę: gałąź, na której powstawał koszyk, pull request, który go zmergował, commity każdego pliku wymienionego na rysunku oraz tytuły pull requestów, które przy każdym elemencie witryny wskazują osobę.

Ostatnia rzecz, jaka wydarzyła się w tym projekcie, była moja i była mała — poprawka stylu w formularzu koszyka, otwarta po zakończeniu sprintu i zmergowana ponad dwa tygodnie później.

Wybrałem koszyk, bo zależał od pracy innych bardziej niż cokolwiek innego na tablicy. Przez tę zależność na końcu czekałem.

Samo budowanie poszło dobrze. Ostatnie dni — nie: mieliśmy do przygotowania prezentację, a mojej części nie dało się skończyć, dopóki nie były skończone części, z których korzysta. Byłem scrum masterem. Przez cały czas miałem tablicę przed oczami, widziałem na niej każdą kartę, a i tak na końcu czekałem.

Lekcja nie polega na tym, że wybrałem zły element. Polega na tym, że wybrałem element z największą liczbą zależności, pełniąc jedyną rolę, która mogła ustawić ich kolejność — i traktowałem te dwa fakty tak, jakby nie miały ze sobą nic wspólnego.

Konkretna wersja na następny raz: części, z których korzystała moja strona, były interfejsem, zanim stały się kodem — mogłem spisać ten interfejs pierwszego dnia i zbudować koszyk na jego zaślepce. Wtedy ostatnie dni są integracją, która jest krótka, a nie czekaniem, które nie ma końca.