Jak prawidłowo podchodzić do problemów

Oto Peter. Peter jest programistą, który jest w stanie rozwiązać każdy problem. Może tworzyć oprogramowanie tak dobre, jak każdy inny. Istnieje jednak różnica między programistą, który już swoje przeszedł, a programistą, który ma wszystko przed sobą, mimo że w teorii posiadają oni te same umiejętności techniczne. Jak to możliwe? Posłuchajcie pewnej historii.

Peter zbudował świetny system rezerwacji online dla pewnego warsztatu. Użytkownik może wybrać termin w polu "Available Time". Mary, operator systemu, używa kodu napisanego przez Petera i jest odpowiedzialna za przyjęcie kolejnej osoby w kolejce i świadczenie usług wewnątrz warsztatu.

Na diagramie widzimy przeglądarkę, która inicjuje rezerwację w polu Available Time Service. Usługa ta przekazuje rezerwację do Booking Service, w celu potwierdzenia i finalizacji. Booking Service powiadamia operatora, kiedy rezerwacja jest zakończona.

System rezerwacji ma jednak pewien problem. Chociaż stan systemu aktualizuje się natychmiast na serwerze, użytkownik musi odświeżyć stronę lub ponownie wejść na witrynę internetową, aby zobaczyć aktualizacje dostępnych terminów. W ten sposób, jeśli dwie osoby patrzą jednocześnie na ekran „Available Time”, to mogą utworzyć tę samą rezerwację w tym samym czasie. Jeśli stanie się to w ruchliwy dzień, Mary będzie miała kłopot z rozwiązaniem problemu. Sprawi to, że klienci będą niezadowoleni, a cała sytuacja frustrująca. 

Peter jednak wie, co robi i chce to naprawić. Planuje rozwiązanie w postaci systemu, które natychmiast aktualizuje ekran „Available Time” i wysyła wiadomość typu push do przeglądarki, aby móc aktualizować interfejs w czasie rzeczywistym. Nawet jeśli nie jest to wystarczająco szybkie, kod sprawdza również, czy nie ma duplikacji tuż przed zakończeniem rezerwacji. Jeśli użytkownik spróbuje utworzyć zduplikowaną rezerwację, gdy nie udało się wystarczająco szybko powiadomić o aktualizacji, system wyświetli błąd.

Taki sam diagram, jak poprzednio. Jednak teraz, zamiast Booking Service powiadamiającego operatora o zakończeniu rezerwacji, usługa ta powiadamia również przeglądarkę za pomocą WebSocket.

Mary zaczyna się denerwować. Peter poświęca zbyt wiele czasu, aby to zrealizować. Po 2 miesiącach Peter dowozi poprawkę i po kilku dniach Mary zauważa, że nie ma już duplikatów rezerwacji.

Praca Petera jest skończona, a on przechodzi do następnego projektu.

Dwa miesiące później Mary kontaktuje się z Peterem ponownie. System rezerwacji działa dobrze. Trzech spośród kilku tysięcy użytkowników narzekało jednak, że podczas próby rezerwacji wystąpiły błędy z powodu duplikatów rezerwacji. Peter myślał, że aktualizacja systemu w czasie rzeczywistym w zupełności wystarczy. Nie wystarczyła.

Peter jednak nie może pojąć, co się stało, pomimo kilku godzinach debugowania i wielu dniach analiz wynikających ze złożonego kodu i weryfikacji związanych ze sprawdzaniem zduplikowanych rezerwacji. Nie wie, jak zreprodukować problem, bo jest zbyt wiele stanów, w których system różnie się zachowuje. Oprogramowanie jest zbyt skomplikowane! Postanawia zatem dodać dodatkowe logowanie, które zapewni więcej informacji na temat błędu, gdy wystąpi on ponownie.

Sześć tygodni później ktoś inny zduplikował rezerwację i ominął walidację. Mary zdała sobie z tego sprawę, gdy obaj klienci przybyli o tej samej porze. Na szczęście nie był to ruchliwy dzień. Logi właściwie nie pokazały niczego przydatnego, a jedynie to, co wiemy: ograniczona liczba osób jest w stanie ominąć walidację i powielić rezerwację. Odtworzenie tego problemu jest niestety niemożliwe.

Peterowi wydawało się, że jest zdolny rozwiązać każdy problem, ale niestety tak nie jest. Za późno zdał sobie z tego sprawę. 

Dziesięć lat później zapytałem Petera, jakie wnioski z tego wyciągnął. Oto, co mi powiedział:

Dowiedzieliśmy się moim współpracownikiem, że istnieją pewne ograniczenia techniczne w systemach rozproszonych, na przykład, nie rozwiążesz problemu powielanych rezerwacji bez dużych kosztów. W grę wchodzi wiele komputerów, opóźnienie sieci itp. Kiedy pracujesz z rozproszonym systemem rezerwacji na szerszą skalę, musisz zaakceptować, że dwie osoby będą próbowały zrobić to samo w tym samym momencie. Jeśli istnieje wymóg biznesowy, aby tak się nie działo, musisz pokazać to ograniczenie interesariuszom i zrozumieć jak chcieliby to rozwiązać.

Jeśli zezwolisz programowi na utworzenie duplikatu, ale stworzysz również proces, który umożliwi operatorom systemu samodzielne rozwiązanie problemu, doświadczenie użytkownika będzie lepsze, bo nie wyskoczy mu żaden błąd. Gdy koszt naprawienia nieprawidłowej rezerwacji przez operatorów systemu będzie zbyt wysoki, to dopiero będziecie mieli problem. W międzyczasie możesz się poświęcić ważniejszym projektom. 

Nie ma sensu inwestować, zanim nie będziesz mieć wystarczających dowodów na to, że koszty się zwrócą.

Peter podał jeszcze pewien przykład: 

Serwer może nie wysłać powiadomienia do użytkownika, dopóki operator tego nie potwierdzi. Jeśli operator ma interfejs do powiadamiania o zduplikowanej rezerwacji, może on wtedy porozmawiać z oboma użytkownikami i zmienić termin dla jednego z nich. Dzieje się to na godziny, a nawet dni przed przybyciem do warsztatu.

Gdy koszt zmiany harmonogramu stanie się zbyt duży, to można zautomatyzować proces. Możesz, na przykład, stworzyć system, który przegląda bazę danych i wyświetla listę wszystkich zduplikowanych rezerwacji. Następnie piszesz kod, aby wysłać powiadomienie do zainteresowanych stron, które są w stanie rozwiązać problem. Jeśli koszt manualnego rozwiązania duplikacji stanie się zbyt duży, możesz stworzyć system, który automatycznie wysyła do użytkownika SMS lub e-mail z następującą informacją: Przepraszamy, nie możemy Cię obsłużyć o 10 rano, prosimy o wybranie innego terminu. 

Zamieniasz koszt operatora na małą niedogodność dla kienta. Jeżeli niedogodność jest jednak zbyt duża do zaakceptowania, możesz się wtedy zwrócić ku bardziej skomplikowanym sposobom walidacji. W ten sposób spędzasz jedynie czas na pisaniu oprogramowania, które rozwiązuje właściwy problem i nie marnujesz czasu na rozwiązywanie problemu, który nie istnieje. 

Peter nauczył się, że lepiej jest przenieść pewne ograniczenia techniczne na biznes i stopniowo je adresować, zamiast próbować rozwiązywać wszystkie problemy naraz.

Połączenie między wieloma komputerami działa podobnie jak komunikacja we wszechświecie - jest niechlujna, złożona i asynchroniczna, więc rzeczy zdarza się w najmniej spodziewany sposób. Nie działo ona w sposób w synchroniczny, gdzie rzeczy dzieją się jednak po drugiej. Zanim spróbujesz rozwiązać każdy problem, skoncentruj się na tych, które mają znaczenie. Jeśli wymagają zbyt dużego wysiłku, należy je traktować jako scenariusze biznesowe. Gdy zdobędziesz wystarczającą ilość dowodów na to, że warto zainwestować czas i wysiłek, aby je naprawić, to znajdziesz sobie dobry problem do rozwiązania.

Peterowi wydawało się, że jest w stanie rozwiązać każdy problem, jednak mądrość przyszła z doświadczeniem…

… mądry programista to nie taki, który naprawia wszystkie problemy, ale ten, który rozumie, jakie problemy warto naprawić.

Jest to naturalnie zadanie „Product Managera”, ale to Ty wykonujesz pracę. Następnym razem, gdy masz do rozwiązania problem biznesowy, przeanalizuj skrajne przypadki i sprawdź, czy możesz zaadresować te problemy prostym scenariuszem bizesowym. Nasza branża to taka, w której wywiady algorytmiczne i podział ról są czymś normalnym. Potrzebujemy programistów, którzy znają swoją wartość i starają się znaleźć w problemie szansę na obrócenie go w wartość, zamiast naprawiania wszystkiego, jak leci.

Za kilka miesięcy lub lat możesz zdać sobie sprawę, że kod, który piszesz dzisiaj, jest błędny. W tym czasie nauczysz się tego samego, co Peter. Jednak nauka na własnych błędach wymaga ich popełnienia.

Lepiej nie musieć tego robić.

Lepiej jest uczyć się na błędach innych.

Oryginał tekstu w języku angielskim przeczytasz tutaj.