Kiedy uczyłam się kodowania, moje wyobrażenie o pracy programisty bardzo odbiegało od rzeczywistości: mit mizantropa siedzącego w piwnicy przy komputerze nadal żyje i ma się nieźle. Przede wszystkim wydawało mi się, że głównym zajęciem programisty w ciągu dnia jest klepanie w klawiaturę i produkowanie kodu. Jak wielkie było moje zdziwienie, kiedy w pierwszej pracy widziałam kolegów, którzy z ołówkami w ręce rozpisywali i rozrysowywali swoje zadania. Z czasem okazało się, że to całkiem powszechna praktyka.
Flow pracy z historyjką
Schemat wykonania każdego z zadań wygląda z grubsza tak samo, niezależnie czy jest to błąd do naprawienia czy nowa funkcjonalność do zaimplementowania. Na początku czytam treść zadania oraz zastanawiam się czy zadanie obejmuje wyłącznie warstwę front-endową aplikacji. Jeżeli nie, kontaktuję się z którymś z kolegów back-endowców i pracujemy nad zadaniem symultanicznie lub ustalamy kto wprowadzi zmiany w pierwszej kolejności.
Jeżeli zmiany nie obejmują back-endu, przechodzę do analizowania – póki co bez zaglądania w kod – tego co muszę zmienić i w jakich miejscach. Następnie wyszukuję te miejsca w kodzie aplikacji i sprawdzam co dokładnie w jakiej klasie powinnam zmienić/dołożyć/wywalić. W międzyczasie notuję sobie to co ustaliłam, żeby potem łatwiej zmienić w kod to co przeanalizowałam.
Oczywiście po pisaniu kodu przychodzi czas na code review a potem na testowanie aplikacji. O tym co robię przed samym pull requestem napiszę w osobnym wpisie. Dzisiaj skupię na tym jak wygląda mój proces analizowania historyjki.
Praca nie jest specjalnie problematyczna jeżeli zadanie do wykonania jest proste i nieskomplikowane. Gorzej jeśli zmiany dotyczą wielu miejsc i wymagają przedtem gruntownego przemyślenia całej koncepcji modyfikowanych fragmentów aplikacji.
Kilka razy czytam treść
To w zasadzie podstawa: jeżeli nie zrozumiem dokładnie o co chodzi w zadaniu to nie ma szans, żebym wykonała je poprawnie. Z reguły czytam treść kilkukrotnie przed rozpoczęciem analizy zadania, wracam też do niego w trakcie realizacji oraz przed samym wysłaniem kodu do code review. Opis zadania powinien zawierać kryteria akceptacji, co znacznie ułatwia samodzielne testowanie aplikacji po zakończeniu pracy. Kryteria akceptacji to zestaw warunków, które aplikacja musi spełniać aby historyjka, którą wykonuję mogła zostać uznana za ukończoną z biznesowego punktu widzenia. Jeżeli coś w opisie jest coś niejasnego, to wtedy…
Dopytuję analityków
Nierzadko zdarza się, że opis zadania nie uwzględnia pewnych zależności, które wynikają z wprowadzanych na bieżąco zmian i poprawek. W takich sytuacjach konsultuję te zależności z analitykami. Dopytuję też o niejasne kwestie związane z wyglądem aplikacji po planowanych zmianach.
Zaglądam do modeli analitycznych
Modele analityczne prezentują w formie diagramów zawiłe procesy biznesowe. Bardzo często to właśnie tam mogę znaleźć odpowiedzi na najbardziej nurtujące pytanie, np. jaki typ danych przychodzi do mnie z back-endu i jakim typem powinnam się posługiwać w danym obiekcie.
Rysuję schematy i rozpisuję warunki
W swoim procesie analizy zawsze notuję najważniejsze zależności. Z reguły rozpisuję warunki za pomocą diagramów i rysuję schematy z zależnościami. Notatki służą mi potem w procesie wprowadzania zmian.
Analizuję kod
Po analizie strony biznesowej przechodzę do szukania w kodzie miejsc, które muszę zmienić. Dopisuję w notatkach konkretne pliki i klasy, gdzie powinnam nanieść wyszczególnione modyfikacje. W ten sposób tworzę sobie listę, która krok po kroku prowadzi mnie przez rozpracowywany task.
Wyobrażenia kontra rzeczywistość
Jak to zwykle w życiu bywa plan idealny nie istnieje. W rzeczywistości często zdarzają mi się pomyłki i przeoczenia, tak samo jak niedoskonałe bywają opisy, kryteria akceptacji czy testy. Staram się jednak stale minimalizować ilość błędów wynikających z mojego niedopatrzenia czy zaniedbania.