Programowanie to coś więcej niż pisanie kodu
Niedawno spędziłam pół dnia, wdrażając pewną funkcję i zmieniłam wiele rzeczy w bazie kodu. Przy testach zdarzyło się coś, do czego potrzebowałam pomocy moich współpracowników. Odkryłam w tamtym momencie, że większość logiki była całkowicie niepotrzebna, ponieważ moje założenia w oparciu o moją interpretację funkcji były błędne. Gdybym tylko poświęciła czas na sprawdzenie, czy wszystko dobrze rozumiem, mogłabym zaoszczędzić kilka godzin pracy.
Nasze założenia trafiają na produkcję
Ten incydent przypomniał mi się podczas przemówienia Alberto Brandoliniego w Domain-Driven Design Europe 2020, kiedy powiedział:
Nasze założenia trafiają na produkcję
Dało mi to do myślenia.
Powinniśmy nie tylko umieć programować, ale także mieć wystarczającą wiedzę na temat domeny, aby zaprogramować właściwą rzecz. Ostatecznie, to jak pewne rzeczy rozumiemy, znajduje odzwierciedlenie w pisanym przez nas kodzie. Przyznaję się bez bicia, że czasami czytam tylko tytuł zadania i od razu dokonuję zmian i tworzę pull request. Działa to czasami w przypadku małych funkcji i ticketów o błędach, ale jeśli chodzi o wdrażanie większych funkcji, to takie podejście nie zadziała.
Jeśli masz szczęście, to błędne założenia zostaną wychwycone, zanim trafią do głównej gałęzi, a jeśli masz pecha, to stanie się to podczas QA lub, co gorsza, przy sprawdzaniu apki. Na tym etapie, nie chodzi tutaj tylko o poprawienie swoich założeń, ale o utworzenie nowego ticketu i nowego pull request — co wiąże się ze zmarnowaniem czasu wszystkich naokoło i pisaniu całej funkcji od nowa.
Wszystko z powodu założenia opartego na tytule ticketu i dyskusji sprzed miesiąca podczas refinementu. Podczas gdy czytanie kryteriów akceptacji może pomóc w uniknięciu powyższego scenariusza, to product ownerzy oraz interesariusze to też ludzie, którzy popełniają błędy lub uważają, że niektóre rzeczy są oczywiste. Kryteria akceptacji mogą być niekompletne.
Powinniśmy zatem o tym pamiętać i zadawać pytania, ilekroć zapuszczamy się na nieznane terytorium, nawet jeśli wydaje się ono znajome.
Nie chodź na łatwiznę
Skoncentrowanie się na rozwiązaniu technicznym jest najprostsze, ponieważ jest to coś, co znamy i rozumiemy. Stworzenie mikroserwisów ze wszystkimi super ficzerami to fajna sprawa. Wywoływanie wszystkich mikroserwisów, aby cokolwiek zrobić, już nie jest takie fajne.
Tak więc nawet jeśli rozwiązanie jest dziełem sztuki z technicznego punktu widzenia, to może ono polec w osiąganiu założonego celu. Kiedyś pomagałam w nadzorowaniu egzaminu ze znajomości Pythona. Egzamin był cyfrowy, a sposób, w jaki można się było na niego zgłaszać, był bardzo wymyślny. Aplikacja miała wbudowaną powłokę, automatyczne ocenianie i została wdrożona w klastrze Kubernetes.
To było piękne... do momentu, w którym 400 studentów musiało się zalogować i korzystać z niej jednocześnie.
Minęło trzydzieści minut, zanim wszyscy uczniowie się zalogowali. Odpowiedzi nie były zapisywane i pojawiały się problemy z sesjami. To był koszmar. System, który miał zaoszczędzić czas, spowodował opóźnienie wystawiania ocen o całe tygodnie. Złożoność aplikacji sprawiła, że jest ona całkowicie nieprzewidywalna przy tak dużym obciążeniu i ostatecznie nie spełnia wymagań głównego zadania — zapisywania egzaminu i oceniania go.
Poświęcenie czasu na upewnienie się, czy faktycznie spełniasz potrzeby użytkownika, może być kluczowe w tworzeniu apki, która będzie dobrze działać.
Podsumowanie
Znajomość domeny może brzmieć jak zadanie product ownera lub każdego, kto wymyśla wymagania. Ale nie jesteś tylko kodującą małpą. Nie konsumujesz wymagań i nie zwracasz kodu. Twoim obowiązkiem jest upewnić się, że kod, który piszesz, jest tak poprawny, jak to tylko możliwe.
Choć może nigdy nie będziesz mieć wiedzy eksperckiej, jeśli chodzi o domenę, to możesz wiedzieć wystarczająco dużo, aby dostrzec błędne założenia w pull requestach lub być w stanie podejmować decyzje, które przełożą się potem na łatwiejsze utrzymanie systemu.
Porozmawiaj więc z ekspertami od domeny, gdy natkniesz się na coś, co nie ma dla ciebie sensu. Zapytaj, dlaczego kryteria akceptacji muszą być spełniane w taki, a nie inny sposób. Kto wie, co uda Ci się odkryć.
Pamiętaj, że tworzenie oprogramowania to coś więcej niż pisanie kodu.
Oryginał tekstu w języku angielskim możesz przeczytać tutaj.