Wielu z Was - programistów Front-end - na pewno słyszało o UML-u. Część, która miała już tą przyjemność korzystania z możliwości zamodelowania dowolnego scenariusza pewnie ma już wyrobione zdanie na temat tego języka. W tym artykule przedstawię Ci, czym dla mnie jest UML.
Jest to pierwszy post z serii o UML. Mam w planach napisanie kilku artykułów na temat konkretnych diagramów UML, które wykorzystuję w codziennej pracy.
- - Diagram Sekwencji w UML (przykłady w JavaScript)
- - Diagram Klas w UML (przykłady w JavaScript)
- - Po co mi UML?
Co to jest UML?
Drogi czytelniku, jeśli jeszcze nie wiesz co to jest UML, to pozwól, że w telegraficznym skrócie Ci wytłumaczę.
Czy czasami, kiedy masz problem ze zrozumiem czegoś, jakiegoś problemu, czy nie korzystasz wtedy z długopisu i kartki? Jeśli tak to na pewno starasz się narysować na kartce papieru pewne elementy, takie jak np. użytkownik, serwer, przycisk albo okno przeglądarki.
Każdy kto rysuje na kartce papieru tworzy coś na swój sposób. Co jeśli wystąpi konflikt? W mojej głowie użytkownika będzie reprezentował kwadrat, a u Ciebie to będzie okrąg? Co wtedy No właśnie. UML to umowny zapis jak powinno się rysować elementy ze świata inżynierii oprogramowania.
Po co?
-
Przedstawienie innemu programiście implementacji za pomocą obrazka.
Ile razy słyszałeś “a weź mi to narysuj”? Jeśli masz komuś coś wytłumaczyć, to bardzo często lepiej jest to po prostu narysować.
Przedstawienie czegoś na obrazku lepiej obrazuje omawiane zagadnienie. Ilu programistów tyle różnych rysunków. Dlaczego więc nie rysować zgodnie z jakimiś zasadami?
Diagram Klas mojego autorstwa. Temat - Szkoła. 2012 rok. -
Świetne na spotkania z biznesem, aby pokazać jak wygląda implementacja.
Za poprawną implementację odpowiedzialni są programiści. Tylko oni znają się na programowaniu. Biznes nie rozumie o co chodzi w tych krzaczkach, które wyświetlają się całymi dniami na komputerach developerów.
Przykład diagramu czynności. To, że biznes nie potrafi programować, to nie znaczy, że nie potrafi myśleć. Dlatego też, jeśli chciałbyś - developerze - pokazać np. jak wygląda flow, które zaimplementowałeś to pokaż biznesowi diagram czynności, na którym będzie rozrysowane krok po kroku jak wygląda np. rejestracja użytkownika w projekcie opartym na React-cie 😄
Stoisz na spotkaniu i nikt Cię nie rozumie gdy tłumaczysz implementację?
NARYSUJ JĄ! -
Planowanie implementacji.
Ważna zasada
Najważniejszą rzeczą poprzedzającą implementację jest analiza!
Ile razy drogi programisto gryzłeś się w język, że napisałeś kod bez wcześniejszego namysłu i teraz niestety musisz go się pozbyć, bo ktoś zwrócił Ci uwagę, że brniesz w złą stronę. Najbardziej boli, kiedy to Ty sam zauważasz, że po kilku godzinach zabrnąłeś zupełnie nie tam gdzie powinieneś. No właśnie!
Analiza (z angielskiego “design”) to projektowanie rozwiązania.
W tym przypadku problemem jest brak etapu projektowania. Wszystkie szkoły wytwórców oprogramowania mówią, że pierwszą fazą (w modelu kaskadowym) jest specyfikacja, czyli określenie wymagań projektu, ale tuż za nim jest faza projektowania systemu na którą powinno poświęcić się do 30-40% całości trwania projektu (źródło 1, źródło 2).
Poprzez “projekt” mam też na myśli dowolne “zadanie”.
Nuda?
Wiele osób może uważać, że tworzenie diagramów to nuda. Dlatego też, nie chce się im ich rysować. Nie rozumiem dlaczego w głowach developerów pojawia się takie myślenie. Jestem w stanie zrozumieć, że Ci młodzi “zapaleńcy”, którzy by tylko klepali w klawiaturę - nie ważne co, ważne że klepią - mogą nie zakochać się w diagramach, bo tutaj nie ma kodowania.
Jednak kiedy młody developer staje się coraz bardziej odpowiedzialny za system, to zastawia się jak tutaj sobie pomóc i nie pisząc kodu, móc określić jego potencjalne działanie.
Architekci, czyli tacy developerzy, którzy na pewnym etapie swojej kariery postanowili zająć się na dobre projektowaniem, wiedzą, że bez odpowiednich modeli (czytaj diagramów) ich praca nie byłaby efektywna. Zaprezentowanie swojego pomysłu dla zespołu projektowego wiąże się z tym, że jeśli zostanie on źle zrozumiany to ponosi za to konsekwencje.
Diagramy to dokumentacja
Pliki z diagramami to typowa, zaraz po słownej, dokumentacja. Wszyscy wiemy, że nieaktualizowana dokumentacja nadaje się tylko do śmietnika. Trzeba aktualizować dokumentację słowną, ale też i rysunkową.
Moja prośba
Mam do Ciebie drogi developerze serdeczną prośbę.
Dbaj o dokumentację. Uratuje Ci ona kiedyś skórę. Mówię Ci ze swojego doświadczenia.
Teza: diagramy są trudne!
W świecie front-endu jest wiele frameworków, narzędzi, systemów. Utarło się, że osoby bez znajomości dowolnego z nich stwierdzają, że jest on “trudny”. Nie mam pojęcia dlaczego pojawia się takie myślenie.
Złota myśl
Wychodzę z założenia, że nie ma rzeczy trudnych, są rzeczy których po prostu jeszcze się nie poznało.
Drogi czytelniku, jeśli nie znasz jeszcze UML to poczytaj o dowolnym diagramie i rysuj go. Naucz się wszystkiego, co z nim związane i rysuj tyle tych diagramów ile wlezie. Taką praktyką dojdziesz do momentu, że już nawet nie poczujesz, że musisz narysować diagram. Stanie się to po prostu łatwe i przyjemne. Dlaczego? Bo już poznałeś na wylot zasady jakie w nim panują.
Ze swojej strony proponują naukę dowolnego z poniższych:
- Diagram Klas
- Diagram Sekwencji
- Diagram Czynności
Teza obalona 🎉
Kto go używa?
-
Programiści back-end
Ci programiści wykorzystują diagramy do modelowania swoich usług wystawionych w świat.
-
DevOps, czyli administratorzy systemów
Ci, natomiast mogą prezentować swoją architekturę serwerową, wszelkie sieci szkieletowe i inne.
-
Programiści front-end
Ci mają bardzo łatwo, bo liczba procesów które mogą zostać narysowane w diagramach jest przeogromna, zaczynając od komunikacji sieciowej z back-endem, skończywszy na definicji zachowania kontrolek po interakcji użytkownika.
-
Inni
Istnieje wiele stanowisk, które również wykorzystują takie diagramy i nie sposób jest ich tutaj wszystkich wymienić.
Kto powinien znać UML?
Każdy developer sieciowy.
Kto jest takim developerem? Każdy kto wytwarza oprogramowanie, do którego dostęp możliwy jest za pomocą sieci, czy to wewnętrznej (intranet) czy to zewnętrznej (internet).
Jak mi “jako programiście” pomagają diagramy?
Z mojego doświadczenie najlepszym diagramem dla programistów front-end jest Diagram Sekwencji, który obrazuje jak wygląda ich kod w stosunku do innych systemów, np. back-endu lub też inter-obiektowy w aplikacji.
Inter-obiektowy, to taki który określa połączenia między obiektami, klasami w
architekturze aplikacji. Np. jak wygląda komunikacja między DataService a
modelem UserModel.
Jak mi “jako kierownikowi” pomagają diagramy?
-
Nie muszę patrzeć na implementację aby zweryfikować poprawną architekturę.
Code Review to świetna sprawa - uwielbiam to robić. Jednak jest pewien case, kiedy robienie CR to droga przez męką. Zastanów się kiedy tak jest?
W moim przypadku, ciężko mi się przegląda Pull Request, który zawiera ogromną liczbą zmian. Kiedy w PR liczba dodanych linijek przekracza ponad 1000 (1 tysiąc) linijek kodu, to jest kiepsko.
Gdybym miał diagram opisujący jak wygląda implementacja, to nie musiałbym mocno zwracać uwagę na zmienione linijki, ponieważ niektóre błędy mógłbym z niego wyczytać.
-
Oszczędność czasu.
Jako kierownik wieloosobowego zespołu nie mam za dużo czasu, aby weryfikować każdą implementację. Każda godzina jest ważna, dlatego staram się najefektywniej je wykorzystywać. A ślęczenie nad czyimś kodem aby zapoznać się co zrobił developer nie jest mega efektywnym zajęciem.
-
Prezentacja implementacji mojego zespołu przed biznesem.
Często jest tak, że biznes wyraża chęć poznania w jaki sposób została zrealizowana dana funkcjonalność. Ma do tego pełne prawo. Posiadając odpowiednie typy diagramów jest w stanie bardzo szybko udzielić odpowiedzi nie produkując się za każdym razem gdy takie pytanie będzie miało miejsce.
Przykład (z życia wzięty)
Jestem przekonany, że gdy tworzysz stronę, czy to budując API RESTowe, czy UI myślisz o użytkowniku, który będzie korzystał z tego co zrobisz.
W UML istnieje taki diagram, na którym możesz rysować to, co użytkownik może zrobić z Twoim “systemem”1. Taki diagram nazywa się Diagram Przypadków Użycia (en. Use Case Diagram).
Niech przykładem będzie sytuacja z użytkownikiem portalu wideo. Na takim diagramie możemy zapisać, jakie możliwości posiada użytkownik.
•