W tym poście kontynuuje temat listy 15 najważniejszych aspektów technicznych, które Scrum Master musi znać, pracując z zespołem w IT. Jestem fanką miniseriali, więc sama stworzyłam miniserię — jest to odcinek 2 z 3. Zapraszam Cię do dalszej lektury ;).
Spoiler alert: Planuję wykorzystać każdy z tych punktów jako inspirację do nowych postów. Będę sukcesywnie je szczegółowo opisywać. Zachęcam Cię do regularnych wizyt na moim blogu :).
6. Jak wygląda proces testowania i jakości kodu w teorii i praktyce
Ile razy używaliście jakiejś aplikacji i coś Wam nie działa? Nic więcej nie mówię, bo każdy z nas miał okazję złapać takiego rodzynka, albo profesjonalnie mówiąc buga na produkcji. Skoro są ogólnie przyjęte procesy, to skąd się one biorą?
Testy wykonuje się na 3 etapach wytwarzania oprogramowania:
gdy programista pisze funkcjonalność i do tego odpowiednie testy
gdy tester oprogramowania pisze testy automatyczne lub wykonuje testy manualne na różnych środowiskach
przy integracji i wdrażania kodu na kolejne środowiska - potocznie nazywane mergem, a następnie buildem kodu i odpalaniem testów na pipeline'ach.
Nie da się wszystkiego przewidzieć i w związku z tym, czasem zdarzają się błędy. Ważne jak zespół podchodzi do ich wyłapywania i późniejszej naprawy — co stanowi odrębny temat. Każda osoba uczestnicząca w procesie SDLC musi rozumieć, jakie są rodzaje testów i czym jest piramida testowania. Nie mylić z piramidą finansową :P, aczkolwiek to też warto wiedzieć ;).
Rodzaje testów, o których najczęściej słyszymy:
jednostkowe [tzw. unit] — sprawdzają działanie małej "jednostki" kodu. Najczęściej pisane przez programistów przy tworzeniu funkcjonalności. Weryfikują działanie kodu pod względem logicznym, włączając w to wiele warunków brzegowych.
integracyjne — oceniają, czy interakcję pomiędzy aplikacją, a jej otoczeniem działa poprawnie. Mają na celu wyłapać błędy techniczne w warstwie komunikacji pomiędzy poszczególnymi komponentami.
e2e [czyli end-to-end] - to testy to zestawy scenariuszy, które weryfikują zachowanie procesów biznesowych w aplikacji [np. zakup produkty w sklepie]. Sprawdzają całe flow, czyli czy wszystkie czynności odbywają się bez przeszkód we wszystkich systemach potrzebnych do wykonania z sukcesem czynności biznesowej.
W obszarze testowania jest znacznie więcej testów, o których mniej się słyszy:
testy bezpieczeństwa, penetracyjne
testy obciążeniowe
testy kontraktowe
wydajnościowe
testy eksploracyjne
Testy to co najmniej temat rzeka, jeśli nie ocean ;). W mojej ocenie ważne jest, by dobrze rozumieć — jak wygląda proces testowania i jakie standardy są używane w zespole i aplikacji, nad którą pracujemy. Warto też rozumieć zakres podstawowy z tego zagadnienia:
po co są testy
jakie są rodzaje testów, po co się je robi i kiedy warto w nie inwestować
czym się różnią testy automatyczne, od manualnych
co to jest shift left w testowaniu
czy tester manualny może pisać testy automatyczne
jakie testy pisze programista, a jakie tester
7. Rodzaje architektury IT — i ich plusy i minusy
Uwielbiam słuchać, że aplikacja jest "beznadziejnie" napisana — jakość kodu, architektura pozostawiają wiele do życzenia. I w sumie najlepszym rozwiązaniem jest wyrzucenie jej do kosza i napisanie od nowa. Oczywiście jak firma ma takie możliwości, to czemu by i nie. Z drugiej strony architektura też ewoluuje wraz z rozwojem aplikacji. Coś, co było dobre na początku, już w dojrzałym produkcie może się nie sprawdzać. Jak z tego wybrnąć?
Tutaj może przyjść z pomocą wiedzą na temat rodzajów architektury oraz korzyści i ryzyka, jakie za sobą niosą.
Rozróżniamy:
monolit
modularny monolit
rozproszony monolit
mikro-serwis
Monolit to aplikacja, której wypuszczenie nowej wersji oznacza zarządzenie całością. Oznacza to, że interfejs użytkownika, logika aplikacji, obsługa danych są jedną całością. Można nim zarządzać z głową i wtedy dąży się do jego modularyzacji. W odpowiednim momencie, kiedy organizacja, produkt i zespół dojrzeją zaczynają się rozmowy idące w stronę wydzielenia jakiejś usługi jako mikroserwisu.
Oczywiście jak wszystko w świecie każdy z tych rodzajów architektury ma swoje plusy i minusy. Aplikacje rozproszone mają dłuższe czasy przesyłu danych pomiędzy jednostkami modułowymi, ale w przypadku ataku typu DoS [Denial of Service] ciężej jest hakerom "zabić" aplikację na produkcji. Dodatkowo przy większych aplikacjach, czy bardziej skomplikowanych środowiskach trzeba doliczyć koszt testów integracyjnych, aby mieć pewność, że komunikacja między jednostkami nie została zaburzona przez najnowsze zmiany w jednym z serwisów. W przypadku monolitu mamy mniejsze ryzyko, że komunikacja będzie utrudniona. Natomiast skalowalność rozwiązania jest na gorszej pozycji.
8. Rodzaje infrastruktury i skalowalność rozwiązań
Rozwiązania infrastrukturalne są najczęściej wybierane na podstawie kilku kryteriów:
koszt maszyn
skalowalność
wewnętrzne polityki i strategie firmowe
unikalne wymagania
Najczęściej sprowadzane jest do wyboru pomiędzy chmurą, on-premisem, a hybrydą obu rozwiązań. Jeśli idziemy w chmurę to jaką? Kto będzie utrzymywał infrę — dedykowany zespół domenowy, czy zespół produktowy?
Chmura oferuje również szereg automatyzacji, reguł, standardów i rozwiązań, które umożliwią wdrożenie CI/CD oraz łatwiejsze skalowanie. Ponadto przy wyborze infrastruktury porusza się też temat dodatkowych narzędzi, chociażby z zakresu monitoringu. Dużo zależy, na co się w zespole zdecydujemy. Warto rozumieć jak te wybory wpływają na pracę i obłożenie zespołu.
9. Praca programisty od kuchni, czyli jak powstaje kod
To druga najważniejsza sprawa do zrozumienia, zaraz po tym, jak działa SDLC. To, że programista, programuje — to chyba nikomu nie trzeba tłumaczyć. Ale co konkretnie to znaczy — to już inna para kaloszy ;). Zacznijmy od tego, jak powstaje kod i czym jest IDE.
IDE [Integrated Development Environment] to oprogramowanie, które jest podstawowym narzędziem dla programistów. Zawiera on w sobie edytor tekstu; w którym tworzony jest kod; kompilator/ interpreter, kontrolę wersji, narzędzia do tworzenia buildów i debugowania. Czy jest niezbędny do kodowania? — pewnie, że nie. Wystarczy zwykły program typu notatnik. Niemniej jednak teraz to ogólnoprzyjęty standard. Nawet Microsoft zapewnia w Windowsie Visual Studio w standardzie ;).
Następnie warto zapoznać się z tematem, jak działa kontrola wersji, potocznie nazywana Gitem [od systemu, który to zapewnia] i czemu ona służy. Często w zespole jest kilku programistów, którzy kontrybuują do jednego repozytorium kodu źródłowego. Aby nie wchodzić sobie w paradę, muszą mieć mechanizm, który nie pozwala ot, tak sobie nadpisywać zmian nawzajem. W przeciwnym razie goniliby własny ogon. W 2005 Linus Torvalds napisał na potrzeby swojego zespołu system wspierający trzymanie kontroli nad kodem. Do dziś z tego programiści na całym świecie korzystają, używając różnych komercyjnych wariacji tego oprogramowania: GitHub, GitLab i Bitbucket. Te są najpopularniejsze.
Kluczowe jest zrozumienie, jakie kroki podejmuje się, gdy trzeba napisać nową funkcjonalność lub zrobić poprawkę do buga. Wraz z pisaniem kodu, nieodzowna jest praktyka Code Review. A następnie trzeba poznać, jakie są dalsze kroki po napisaniu kodu, przejściu CR, aż po samo wdrożenie nowej wersji i ewentualnych poprawek typu hot-fix.
Ostatnim trendem jest trunk-based development. Warto rozumieć różnice pomiędzy tymi 2 podejściami.
10. Progamer craftmanship, czyli o dobrych praktykach programistycznych
Czymże byłby fach, bez dobrych praktyk? Ma je każdy zawód. Jest to nazwa na trend wśród programistów, którzy cenią sobie owocną współpracę, jak i jakościowy wytwarzany kod. Trochę tego jest i nie jest to oficjalny przewodnik, czy metodologia. Jednakże warto wyszukać tę frazę w internet, czy podpytać programistów, z którymi się współpracuje na ten temat.
Dobre słowo na koniec
Mówi się, że diabeł nie taki straszny jak go malują. Trzeba tylko chęci i dobrej lektury, by sukcesywnie zdobywać wiedzę techniczną. A wtedy nie będzie strachu pracować w lub z IT.
Dzięki, że wytrwałeś ze mną :) i do kolejnego postu!
~ Kate
Comments