Zapewne już nie raz mieliście okazję przeczytać stwierdzenie, że bardzo istotne jest to, aby w kodzie do nazywania klas domenowych wykorzystywać, te (nazwy) których używa nasz klient.
Wielu z Was uznaje to za oczywistość, wielu dodaje jakieś "ale", są tacy, którzy twierdzą, że przecież klient i tak nie wie czego chce, to po ci się przejmować. Oczywiście są też tacy, którzy sami się takimi "pierdołami" nie mają czasu przejmować, bo przecież "kod jest do napisania".
Nie powiem, że się nie da i Wasz projekt bez takiego odwzorowania nie ma szans na powodzenie, bo to nie jest prawda. Przynajmniej nie w każdym przypadku. Są jednak projekty odpowiednio duże bądź skomplikowane, gdzie ten brak spójności potrafi zauważalnie wpłynąć na tempo produkcji kodu oraz na jego jakość. Niestety, jeżeli się "nie dogadamy", to nawet mimo naszych najszczerszych chęci i przy wykorzystaniu najlepszych technik i praktyk nie unikniemy błędów.
Każdy z nas zaczynał od czegoś małego (aplikacje w pierwszej pracy, staże, projekty na studiach, itp.), co bez problemu można było zrozumieć. Jednak wraz ze zdobywaniem doświadczenia chcecie pracować nad czymś większym, chcecie uczyć się ciekawych rzeczy i rozwiązywać problemy, które będą prawdziwym wyzwaniem. A za tym idą coraz większe projekty, z logiką, która jest coraz bardziej skomplikowana i niekiedy "egzotyczna" (tzn. taka, której w codziennym życiu nie spotykacie/nie znacie).
A szczytem złożoności nie jest fakturowanie wraz z pełną obsługą cyklu życia faktur.
Wyobraźcie sobie, że trafiacie do zespołu składającego się z kilkunastu deweloperów, którzy nie uważali nigdy, że "odrobinę inne" nazwy klas domenowych rodzą jakiś problem. Zaczynacie pracę i dostajecie garść linków z informacjami, które mają Wam pomóc odnaleźć się w temacie. Ba, macie nawet analityka, który chętnie wyjaśnia zawiłości logiki.
Po jakimś czasie już to macie, z zadowoleniem stwierdzacie, że mniej więcej już rozumiecie o co w tym wszystkim chodzi i z uśmiechem na twarzy zabieracie się za upragniony kod i... okazuje się, że nie wszystko to, o czym czytaliście jest w kodzie, niektóre nazwy co prawda są podobne, ale czy podobieństwo wystarczy?
Ok, runda druga. Udajecie się teraz do programistów, którzy cierpliwie Wam tłumaczą, że w "biznesie" nie wszystko ma sens i dlatego wprowadzili kilka "ulepszeń" w celu ułatwienia zrozumienia logiki. Tu coś rozbili, tutaj podzielili, to jest to no chyba, że stan się zmieni, itp., itd. No dobrze, ok, po jakimś czasie i to przestaje być dla Was tajemnicą.
Kilka zadań później trafiacie na problem którego nijak nie umiecie ugryźć, a ludzie z zespołu odsyłają Was do analityka w celu uzyskania niezbędnych informacji.
I tu się zaczyna prawdziwa zabawa i Wasze próby przełożenia kodu na logikę biznesową. Dodatkowo dowiadujecie się, że w celu "usprawnienia" komunikacji pomiędzy IT, a biznesem powstały kolejne terminy opisujące to samo.
Dostrzegacie problem?
Stąd też moja drobna rada. Jeżeli zaistnieje potrzeba uproszczeń logiki, bądź inny powód jej zmiany, to porozmawiajcie z klientem, z analitykiem, czy kogo tam macie jeszcze pod ręką. Brak informacji od nich może najzwyczajniej świadczyć o tym, że komuś się zapomniało, że ktoś coś uznał za oczywiste, itp.
Naprawdę warto jest poświęcić jeszcze trochę czasu na doprecyzowanie wszystkiego, niż męczyć się później. A decyzje tego typu niestety ciężko później zmienić i wprowadzić w kod.
Brak komentarzy:
Prześlij komentarz