Czym jest usługa Service Bus i dlaczego Microsoft stawia na komunikaty w chmurze?

Azure Service Bus pozwala oddzielić producentów komunikatów od ich konsumentów. Dzięki temu aplikacje nie muszą znać się nawzajem ani działać w tym samym czasie. Komunikaty mogą być bezpiecznie przechowywane, ponawiane i przetwarzane asynchronicznie, co znacząco poprawia stabilność całego systemu.

Z perspektywy architekta jest to jedno z kluczowych narzędzi do budowy systemów odpornych na przeciążenia i chwilowe awarie.

Azure Service Bus to zarządzana usługa message brokera, oferująca:

• kolejki (Queues),
• tematy i subskrypcje (Topics & Subscriptions),
• transakcje,
• obsługę kolejki utraconych wiadomości (dead-letter queue),

Nowoczesne systemy IT konsekwentnie promują komunikację asynchroniczną za pomocą kolejek z kilku powodów:

• zwiększa skalowalność,
• upraszcza rozwój mikroserwisów,
• pozwala niezależnie wdrażać i rozwijać komponenty niezależnie od użytych technologii do ich wytworzenia,
• pozwala lepiej wykorzystać zasoby chmurowe dostępne np. w środowisku Microsoft Azure.

Kolejki, Topics i subskrypcje oraz sesje – jak działa usługa Azure Service Bus?

Service Bus Queue – kolejki usługi service bus

Kolejki w Azure Service Bus realizują model point-to-point, w którym każdy komunikat trafia do kolejki i jest przetwarzany przez jednego konsumenta. Nadawca i odbiorca są od siebie niezależni – komunikaty mogą być wysyłane i odbierane w różnym czasie, co zwiększa odporność systemu na awarie i chwilowe przeciążenia.

Usługa wykorzystuje mechanizm Peek-Lock, który tymczasowo blokuje komunikat po jego odebraniu. Dopiero po poprawnym przetworzeniu jest on usuwany z kolejki. W przypadku wystąpienia błędu może zostać ponownie udostępniony innemu odbiorcy lub trafić do dead-letter queue, co ułatwia diagnostykę problemów. Mechanizm Peek-Lock pozwala konsumentowi tymczasowo zablokować komunikat w kolejce. W przypadku wygaśnięcia blokady (np. z powodu timeoutu), komunikat staje się dostępny dla innych konsumentów, co może prowadzić do powtórnego odbioru.

Jedna kolejka może być obsługiwana przez wiele instancji konsumentów. Azure Service Bus automatycznie rozdziela komunikaty pomiędzy nich, zapewniając naturalny load balancing bez dodatkowej logiki po stronie aplikacji.

Kolejki sprawdzają się szczególnie dobrze w scenariuszach takich jak:

• przetwarzanie zadań w tle,
• kolejkowanie żądań i ochrona systemów przed przeciążeniem,
• równoważenie obciążenia pomiędzy wieloma instancjami usług,
• asynchroniczna integracja systemów.

Topics i subskrypcje

Topics w Azure Service Bus realizują wzorzec publish/subscribe, w którym jeden komunikat może zostać dostarczony do wielu niezależnych odbiorców. Producent wysyła komunikat do tematu (Topic), nie wiedząc, kto i ile systemów będzie go konsumować. Każda subskrypcja działa jak osobna kolejka, posiadająca własny stan, retry oraz dead-letter queue.

Największą zaletą Topics są subskrypcje z filtrami, które pozwalają określić, jakie komunikaty trafią do danego odbiorcy. Filtry SQL lub reguły oparte o właściwości komunikatu umożliwiają precyzyjne routowanie zdarzeń bez dodatkowej logiki po stronie producenta.

Każda subskrypcja może być obsługiwana przez wiele instancji konsumentów, co, podobnie jak w przypadku kolejek, umożliwia równoległe przetwarzanie i load balancing. Jednocześnie różne subskrypcje mogą przetwarzać ten sam komunikat w zupełnie inny sposób lub w innym tempie.

Topics i subskrypcje sprawdzają się szczególnie dobrze w scenariuszach takich jak:

• architektura event-driven,
• propagacja zdarzeń domenowych,
• integracja wielu systemów reagujących na te same zdarzenia,
• oddzielenie logiki biznesowej od procesów pomocniczych (np. powiadomień, audytu, raportowania).

Dzięki modelowi publish/subscribe Azure Service Bus Topics umożliwiają budowę elastycznych i łatwo rozszerzalnych systemów, w których dodanie nowego odbiorcy nie wymaga zmian po stronie nadawcy.

Sesje

Sesje w Azure Service Bus to mechanizm umożliwiający grupowanie powiązanych komunikatów i przetwarzanie ich w ściśle określonej kolejności. Każdy komunikat posiada SessionId, a wszystkie komunikaty z tym samym identyfikatorem trafiają do tej samej sesji i są obsługiwane sekwencyjnie przez jednego konsumenta.

W praktyce oznacza to, że choć kolejka lub subskrypcja może być przetwarzana równolegle przez wiele instancji odbiorców, to w ramach jednej sesji nigdy nie dochodzi do przetwarzania równoległego. Azure Service Bus blokuje sesję na czas jej obsługi przez konkretnego konsumenta, co eliminuje problemy z kolejnością i współbieżnością.

Sesje są szczególnie przydatne w scenariuszach, gdzie:

• kolejność komunikatów ma znaczenie (np. workflow, procesy krok po kroku),
• komunikaty dotyczą jednego obiektu biznesowego (np. OrderId),
• wymagane jest przetwarzanie stanowe (stateful processing),
• system musi zachować spójność bez skomplikowanej synchronizacji.

Sesje mogą być używane zarówno w Queue, jak i w subskrypcjach Topiców. Dzięki nim Azure Service Bus łączy wysoką skalowalność z kontrolą kolejności, co jest trudne do osiągnięcia w klasycznych systemach kolejkowych bez dodatkowej logiki po stronie aplikacji.

Azure Service Bus Queue vs Topic – kiedy wybrać które rozwiązanie?

Wybór pomiędzy Queue a Topic w Azure Service Bus zależy przede wszystkim od tego, ile systemów ma przetwarzać dany komunikat i w jaki sposób ma on być obsłużony.

Queue najlepiej sprawdzi się w scenariuszach typu point-to-point, gdzie komunikat ma zostać przetworzony dokładnie raz przez jeden komponent. Jest to idealne rozwiązanie dla zadań w tle, kolejkowania żądań czy równoważenia obciążenia pomiędzy wieloma instancjami tej samej usługi. Queue upraszcza architekturę i minimalizuje liczbę zależności pomiędzy komponentami.

Topic warto wybrać wtedy, gdy komunikat reprezentuje zdarzenie, na które powinno zareagować wiele niezależnych systemów. Dzięki subskrypcjom i filtrom możliwe jest selektywne dostarczanie komunikatów do różnych odbiorców bez modyfikowania producenta. Topic naturalnie wspiera architekturę event-driven i ułatwia dalszą rozbudowę systemu.

W praktyce często stosuje się oba mechanizmy jednocześnie:

• Queue do obsługi zadań i procesów technicznych,
• Topic do publikowania zdarzeń domenowych.

Dobrze dobrany model komunikacji upraszcza architekturę i pozwala skalować system bez kosztownych refaktoryzacji w przyszłości.

Azure Service Bus Patterns – wzorce, które warto znać

Azure Service Bus Request-Response pattern

Request–Response Pattern w Azure Service Bus umożliwia realizację komunikacji dwukierunkowej w sposób asynchroniczny, bez konieczności bezpośredniego połączenia pomiędzy nadawcą a odbiorcą. Zamiast klasycznego wywołania synchronicznego (np. HTTP), klient wysyła komunikat z żądaniem do kolejki lub tematu, a odpowiedź otrzymuje jako osobny komunikat.

W praktyce klient wysyła żądanie do Request Queue, dołączając informacje pozwalające na korelację odpowiedzi (np. CorrelationId lub nazwę kolejki odpowiedzi). Usługa odbierająca żądanie przetwarza je w swoim tempie i publikuje wynik do Response Queue, z której klient odbiera odpowiedź.

Takie podejście zapewnia: 

• brak blokowania zasobów po stronie klienta,
• odporność na opóźnienia i chwilową niedostępność usług,
• lepszą skalowalność w porównaniu do komunikacji synchronicznej.

Request–Response Pattern sprawdza się szczególnie w scenariuszach, gdzie odpowiedź jest wymagana, ale nie musi być natychmiastowa – np. w integracjach między mikroserwisami, procesach długotrwałych czy komunikacji pomiędzy systemami o różnej wydajności. W połączeniu z mechanizmami Azure Service Bus, takimi jak retry i dead-letter queue, wzorzec ten pozwala budować niezawodne i elastyczne rozwiązania komunikacyjne.

Outbox Pattern

Outbox Pattern to wzorzec architektoniczny, który rozwiązuje problem spójności pomiędzy zapisem danych a publikacją komunikatu. W systemach opartych na komunikatach często pojawia się ryzyko, że dane zostaną zapisane w bazie, ale zdarzenie nie trafi do brokera (lub odwrotnie). Outbox Pattern eliminuje ten problem.

W praktyce, zamiast wysyłać komunikat bezpośrednio do Azure Service Bus, aplikacja zapisuje go najpierw do tabeli Outbox w tej samej transakcji co dane biznesowe. Dzięki temu zapis danych i „intencja wysłania komunikatu” stają się operacją atomową. Osobny proces (np. background worker) odczytuje wpisy z Outboxa i publikuje je do Azure Service Bus.

Takie podejście zapewnia:

• brak utraty komunikatów,
• odporność na awarie sieci i brokera,
• możliwość bezpiecznego ponowienia wysyłki.

Outbox Pattern jest szczególnie przydatny w architekturze mikroserwisów i systemach event-driven, gdzie zdarzenia domenowe muszą być publikowane w sposób pewny i powtarzalny. W połączeniu z mechanizmami Azure Service Bus, takimi jak ponowienia wysyłki czy deduplikacja, stanowi solidną podstawę do budowy niezawodnej komunikacji między systemami. Outbox Pattern szczególnie dobrze współpracuje z bazami danych wspierającymi transakcje, pozwalając na spójne zapisanie danych biznesowych i komunikatu w jednym kroku.

Inbox Pattern

Inbox Pattern to wzorzec architektoniczny, który rozwiązuje problem wielokrotnego przetwarzania tego samego komunikatu. W systemach opartych na komunikatach – takich jak Azure Service Bus – ponowne dostarczenie komunikatu jest zachowaniem poprawnym (np. po błędzie lub timeoutach), dlatego aplikacja musi być na to przygotowana.

W praktyce każdy odebrany komunikat jest najpierw rejestrowany w Inboxie – najczęściej w postaci zapisu jego unikalnego identyfikatora (MessageId) w bazie danych. Dopiero jeśli komunikat nie był wcześniej przetwarzany, trafia on do logiki biznesowej. Duplikaty są bezpiecznie ignorowane, co zapewnia idempotentność operacji.

Inbox Pattern zapewnia:

• ochronę przed skutkami retry i ponownych dostarczeń,
• spójność danych w przypadku awarii podczas przetwarzania,
• możliwość bezpiecznego skalowania konsumentów.

Monitoring i diagnostyka: Azure Service Bus Alerts i integracja z Application Insights

Skuteczne wykorzystanie Azure Service Bus w środowisku produkcyjnym wymaga odpowiedniego monitoringu i diagnostyki, które pozwalają szybko reagować na problemy z przetwarzaniem komunikatów. Platforma Azure udostępnia w tym zakresie gotowe mechanizmy oparte o Azure Monitor.

Azure Service Bus publikuje szereg metryk, takich jak liczba aktywnych komunikatów, długość dead-letter queue czy czas przetwarzania. Na ich podstawie można konfigurować Alert Rules, które automatycznie powiadomią zespół o potencjalnych problemach, np. rosnącej liczbie komunikatów w kolejce lub błędach po stronie konsumentów.

Dla głębszej diagnostyki Service Bus integruje się z Application Insights, umożliwiając śledzenie komunikatów w kontekście całego przepływu aplikacji. Dzięki korelacji telemetrycznej możliwe jest przeanalizowanie, jak komunikat przechodzi przez kolejne komponenty systemu i gdzie pojawiają się opóźnienia lub błędy.

Połączenie alertów, metryk i telemetryki aplikacyjnej pozwala nie tylko reagować na incydenty, ale także proaktywnie wykrywać problemy, zanim wpłyną one na użytkowników końcowych.

Zabezpieczenia w Azure Service Bus – RBAC, SAS i protokół AMQP

Azure Service Bus oferuje mechanizmy bezpieczeństwa klasy enterprise, które pozwalają precyzyjnie kontrolować dostęp do komunikatów i chronić komunikację pomiędzy komponentami systemu. Usługa wspiera zarówno nowoczesne uwierzytelnianie oparte o Azure Active Directory, jak i tradycyjne mechanizmy kluczy dostępowych.

RBAC (Role-Based Access Control) umożliwia zarządzanie uprawnieniami przy użyciu ról przypisanych do użytkowników, aplikacji i tożsamości zarządzanych. Pozwala to na centralne i spójne zarządzanie dostępem do kolejek, tematów i subskrypcji, bez konieczności przechowywania wrażliwych danych, takich jak hasła czy klucze dostępu, w kodzie aplikacji. W kontekście Azure Service Bus można stosować predefiniowane role – między innymi Data Owner, Data Sender i Data Receiver – które pozwalają na granularne zarządzanie dostępem do wysyłania, odbioru lub pełnego zarządzania zasobami komunikacyjnymi.

Alternatywą lub uzupełnieniem RBAC są SAS (Shared Access Signatures), czyli tokeny dostępu z określonym zakresem uprawnień i czasem ważności. SAS sprawdzają się w scenariuszach integracyjnych, gdzie wymagany jest ograniczony i kontrolowany dostęp do zasobów Service Bus.

Komunikacja z Azure Service Bus odbywa się z wykorzystaniem protokołu AMQP 1.0, który zapewnia wysoką wydajność, niezawodność oraz wsparcie dla scenariuszy enterprise. AMQP umożliwia stabilne połączenia, efektywne przesyłanie komunikatów i pełne wykorzystanie zaawansowanych funkcji usługi. Azure Service Bus obsługuje również protokół HTTP jako alternatywę dla AMQP w przypadku aplikacji, które nie wspierają AMQP. Zaleca się jednak korzystanie z AMQP w przypadku systemów wymagających niskiej latencji i trwałych połączeń.

Połączenie RBAC, SAS i AMQP pozwala budować bezpieczne, skalowalne i zgodne z najlepszymi praktykami rozwiązania komunikacyjne w chmurze Azure.

Podsumowanie – co warto zapamiętać?

Azure Service Bus to kluczowe narzędzie komunikacyjne w chmurze Microsoft Azure, pozwalające na tworzenie nowoczesnych aplikacji opartych na architekturze asynchronicznej. Dzięki bogatemu zestawowi funkcji – takich jak kolejki, tematy i subskrypcje, sesje, oraz wsparcie dla wzorców projektowych (Request-Response,
Outbox, Inbox) – usługa umożliwia skalowalność, niezawodność i elastyczność systemów.

Zintegrowane mechanizmy bezpieczeństwa (RBAC, SAS, AMQP) oraz zaawansowane monitorowanie (Application Insights, Azure Monitor) gwarantują pełną kontrolę i stabilność rozwiązania, czyniąc je niezbędnym elementem w ekosystemie
nowoczesnych aplikacji chmurowych.

Jeżeli temat cię zaciekawił i chcesz korzystać z usługi w swoim projekcie, zajrzyj do Microsoft Learn na Azure Portal, by uzyskać więcej informacji.

Często zadawane pytania:

Dowiesz się: 

• kiedy warto optymalizować 
• jak mierzyć wydajność kodu 
• jak dobrać algorytm i struktury danych, aby zwiększyć wydajność aplikacji, 
• a także jak robić to w sposób, który nie zabija całkowicie czytelności kodu. 

Wprowadzenie: od 10 do 3 maszyn: realna historia optymalizacji kodu

Powodem powstania tego tekstu jest chęć podzielenia się doświadczeniem z optymalizacji kodu zdobytym podczas pracy nad prawdziwą aplikacją w chmurze. Dwa lata temu byłem członkiem zespołu, który miał za zadanie programować system hostowany na platformie Microsoft Azure. System, zbudowany w oparciu o Azure Functions i .NET 7, przetwarzał strumień zdarzeń JSON: parsowanie, walidacja, budowa modeli – wszystko w czasie zbliżonym do rzeczywistego. Wymóg biznesowy był prosty, ale wymagający obliczeniowo: wydajność aplikacji na poziomie 2000 zdarzeń na sekundę. 

Pierwsze testy wydajności pokazały brutalną prawdę – przy domyślnej implementacji potrzebowaliśmy aż 10 maszyn w dedykowanym planie Azure. Po serii mikrooptymalizacji i ponownej analizie wydajności okazało się, że ten sam ruch obsłużymy przy pomocy 3 maszyn o identycznych parametrach. To nie była magia czy zasługa intuicji. To był efekt świadomego podejścia do zarządzania pamięcią, doboru algorytmów, pracy na strukturach danych i mierzenia czasu wykonania. 

Kod źródłowy przykładów, benchmarki i wyniki dotyczące wydajności znajdziesz w repozytorium GitHub. 
https://github.com/tomekjanicki/Performance – każdy benchmark w osobnym katalogu projektu Performance. Możesz je samodzielnie uruchomić, aby sprawdzić zachowanie na swojej maszynie, komendą: 

dotnet run -c Release --project .\Performance\Performance.csproj -- --memory true 

Kiedy i jak przeprowadzać optymalizację kodu? 

Istotną kwestią jest to, że optymalizacja kodu pod względem czasu wykonania lub zużycia pamięci ma sens tylko wtedy, gdy jakąś operację wykonujemy znaczącą ilość razy w stosunkowo krótkim czasie i zależy nam na jak najkrótszym czasie wykonania zadania przy jak najmniejszej konsumpcji zasobów.  

Generalnie tylko w tym przypadku należy wykonywać optymalizację, gdyż jednym z ważnych czynników jest to, że kod po takiej optymalizacji jest zazwyczaj dużo mniej czytelny i trudniejszy do zrozumienia.  

Do identyfikacji takich obszarów kodu można użyć narzędzia typu profiler np. https://www.jetbrains.com/dotmemory, https://www.jetbrains.com/profiler lub narzędzi dostarczanych z Visual Studio. Mając zidentyfikowane takie fragmenty kodu, można przystąpić do optymalizacji.  

Optymalizacja polega na próbie napisania kodu realizującego tę samą funkcjonalność w sposób bardziej wydajny i porównaniu obydwu implementacji pod względem czasu wykonania i zużycia pamięci.  

Narzędziem, które staje się de facto standardem, jeśli chodzi o pomiar wydajności kodu przy przeprowadzaniu mikrooptymalizacji na platformie .NET, jest BenchmarkDotNet – jest to narzędzie, którego Microsoft wewnętrznie używa do monitoringu wydajności podczas tworzenia samej platformy .NET. Narzędzie to jest wpięte w proces CI, które monitoruje, czy określone fragmenty kodu nie są mniej wydajne po wprowadzonych zmianach. Jeśli wydajność kodu się pogarsza, wtedy zmiany w takim kodzie są ponownie sprawdzane.  

Idealnie byłoby też, gdyby testy były przeprowadzane na dokładnie takiej samej maszynie, na jakiej uruchamiany jest kod produkcyjnie – tzn. chodzi o model procesora, ilość pamięci i system operacyjny. W przeszłości zdarzało się, że dana optymalizacja poprawiała wydajność na danym środowisku, ale pogarszała na innym – generalnie takie sytuacje są stosunkowo rzadkie.  

W przypadku każdego testu będzie prezentowana tabela z wynikami – w przedstawionych rezultatach testów najbardziej będą istotne kolumny Mean oznaczające czas wykonania i Allocated oznaczające zużycie pamięci.  

Podsumowując – w praktyce warto optymalizować, gdy: 

• ten sam algorytm wykonujesz setki tysięcy lub miliony razy, 
• fragment jest w krytycznym hot-path (np. wewnątrz wąskiej pętli przetwarzania), 
• dotyczy intensywnej komunikacji z bazy danych, API albo serwer musi utrzymać bardzo dużą liczbę zapytań, 
• czujesz, że szybkość i efektywność są kluczowe dla doświadczenia użytkownika (np. czas ładowania ekranu, responsywność panelu). 

W innych przypadkach lepiej skupić się na czytelności kodu i jakości projektu 

Typy optymalizacji 

Jak już wcześniej wspomniałem, artykuł rozpatruje dwa typy optymalizacji. W pierwszym celem jest skrócenie czasu wykonania, a w drugim – zmniejszenie konsumpcji pamięci.  

W wielu przypadkach optymalizacja zużycia pamięci przynosi znacznie bardziej spektakularne rezultaty (pośrednio też wpływając na czas wykonania), gdyż pamięć jest łatwo zaalokować, ale proces zwalniania pamięci ze sterty jest dużo bardziej skomplikowany. Więcej o działaniu mechanizmu Garbage Collector można znaleźć pod tym adresem https://www.youtube.com/watch?v=BeuNvhd1L_g. 

B01 Logging – kiedy logi zabijają wydajność aplikacji 

Logowanie (logging) może znacząco wpłynąć na konsumpcję zasobów, zwłaszcza gdy jest wykonywane setki tysięcy razy. Szczegółowe wyniki benchmarków dla tego scenariusza zostały opublikowane w raporcie B01 Logging – pełne wyniki benchmarków, do którego będziemy się odnosić w dalszej części sekcji.

Przy porównywaniu wyników widać, że gdy mamy włączony poziom logowania i fizycznie logujemy wiadomości, to zużycie pamięci i czasy wykonania są bardzo podobne (testy zaczynające się od LogInformationLevelEnabled). Największe różnice widać, gdy wywołamy metody logujące, ale poziom logowania nie jest włączony (testy zaczynające się od LogDebugLevelNotEnabled). Wtedy najlepsze wyniki osiągamy, używając trybu generowania kodu (LogDebugLevelNotEnabledSourceGenerated).  

Więcej informacji: https://learn.microsoft.com/en-us/dotnet/core/extensions/logger-message-generator. Najgorsze wyniki otrzymujemy w przypadku wykorzystania mechanizmu string interpolacji (LogDebugLevelNotEnabledStringInterpolation) – ze względu na naturę obiektu string, który jest niezmienny, za każdym razem generujemy nowy string i alokujemy pamięć, nawet gdy w rzeczywistości nic nie logujemy.  

Dodatkowo, gdy mamy na poziomie projektu (Performance.csproj) ustawiony poziom analizy kodu kompilatora na „latest-recommended”, to kompilator generuje ostrzeżenia CA1848: Use the LoggerMessage delegates i CA2254: Template should be a static expression. Więcej o CA2254 można znaleźć pod tym adresem https://www.youtube.com/watch?v=6zoMd_FwSwQ 

B02 Enums i generatory: szybsze TryParse / ToString 

Wywoływanie metod TryParse oraz ToString na obiektach typu wyliczeniowego wiąże się z użyciem refleksji, co ma bezpośredni wpływ na czas wykonania i zużycie pamięci. Zastępując te metody alternatywnymi implementacjami opartymi o generowanie kodu, można znacząco poprawić wydajność — jednym z takich rozwiązań jest biblioteka Supernova.Enum.Generators.

Różnice są wyraźnie widoczne w zestawieniu czasu wykonania oraz alokacji pamięci pomiędzy podejściem standardowym a wersją generowaną (Standard vs SourceGenerated), co zostało szczegółowo pokazane w raporcie B02 Enums – pełne wyniki benchmarków.

Łatwą alternatywą w przypadku metody ToString jest zbudowanie przy starcie aplikacji statycznego słownika i pobieranie wartości tekstowej na postawie wartości enum. 

B03 Closures: ukryty wróg w lambdach 

W przypadku wyrażeń lambda sposobem na poprawę wydajności jest unikanie closures (więcej o closures w artykule C# in Depth) poprzez przekazywanie zewnętrznego stanu do środka funkcji lambda jako parametr.

Na podstawie testu (ExecuteWithoutClosure) widać, że następuje znaczące skrócenie czasu wykonania oraz nie występuje alokacja pamięci.

Szczegółowe wyniki benchmarku zostały opisane w raporcie B03 Closures – pełne wyniki benchmarków.

To dobry przykład na to, jak drobna zmiana stylu pisania kodu może pomóc w optymalizacji kodu bez większej utraty jego czytelności.

B04 Spans <T>: przyspieszenie parserów i praca „na krawędzi” pamięci 

Użycie obiektów typu span (więcej o span w artykule C# – All About Span: Exploring a New .NET Mainstay) znacząco przyśpiesza działanie kodu, redukując potrzebę dodatkowych alokacji pamięci. Jest on szczególnie przydatny we wszelkiego rodzaju parserach, które wyciągają dane z istniejącego obiektu, tworząc wirtualne okno w pamięci w przetwarzanym obiekcie, zapobiegając tym samym nowym alokacjom.

Obydwa testy realizują identyczną funkcjonalność, przetwarzając tekst na listę z wartościami typu liczbowego. Jak widać, test GetResultSpan jest znacząco szybszy i alokuje mniej pamięci w porównaniu do testu GetResultClassic.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B04 Spans – pełne wyniki benchmarków.

Jeśli twoja aplikacja intensywnie parsuje tekst (np. logi, CSV, payloady z API), to użycie spanów może znacząco wpłynąć na poprawę wydajności.

W benchmarkach: 

• klasyczna implementacja alokuje nowe tablice/stringi, 
• implementacja ze spanami jest znacząco szybsza i zużywa mniej pamięci. 

To już dotyczy zaawansowanych technik, ale w parserach, systemach na edge (np. IoT, funkcje serverless) i usługach API różnica bywa kolosalna. 

B05 Static – pola statyczne zamiast ciągłego tworzenia kolekcji 

Kolejnym przykładem jest kod, który np. sprawdza bieżącą wartość na podstawie niezmiennej listy wartości. Gdy ta lista jest niezmienna, warto zadeklarować ją na poziomie klasy jako pole statyczne i zamiast za każdym razem tworzyć nową listę, przekazywać tę zadeklarowaną instancję do wywołania funkcji sprawdzającej.

Jak widać, test GetValidValuesStatic znacząco obniża czas wykonania i zużycie pamięci w porównaniu do GetValidValuesNotStatic.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B05 Static – pełne wyniki benchmarków.

B06 Capacity – jak jedna linijka może znacznie poprawić szybkość listy 

Przy dodawaniu elementów do obiektu typu generyczna lista dobrym zaleceniem jest ustawienie docelowego rozmiaru listy (jeśli znamy albo w przybliżeniu jesteśmy w stanie określić docelowy rozmiar listy). Ustawienie to wpływa na to, że wewnętrznie tablica, która przechowuje elementy, nie jest wielokrotnie realokowana i kod działa zauważalnie szybciej (ProcessWithCapacity vs ProcessWithoutCapacity).

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B06 Capacity – pełne wyniki benchmarków.

To jedna z tych drobnych zmian, które w intensywnych strukturach danych (np. listy obiektów DTO) robią dużą różnicę.

B07 Linq vs Dictionary i FrozenDictionary

Następnym przykładem jest sytuacja, w której wyszukujemy elementy po określonych unikalnych kluczach. Jeśli dane, na których wyszukujemy, są niezmienne lub wielokrotnie przeprowadzamy wyszukiwanie na tych samych danych, to opłaca się zamiast używać LINQ (GetUsersByIdsLinq) zbudować słownik i przeprowadzać wyszukiwanie w tym słowniku (GetUsersByIdsAlreadyBuiltDictionary).

Natomiast w sytuacji, gdy słownik musi zostać najpierw utworzony (GetUsersByIdsBuildDictionary), operacja ta jest znacznie bardziej czasochłonna i alokuje więcej pamięci. Dodatkowo do porównania został dołączony niedawno wprowadzony typ Frozen Dictionary (więcej informacji w dokumentacji FrozenDictionary – Microsoft Learn), który — jak widać — konsumuje jeszcze więcej zasobów podczas budowy (GetUsersByIdsBuildFrozenDictionary), ale jest minimalnie szybszy przy odczycie (GetUsersByIdsAlreadyBuiltFrozenDictionary).

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B07 LINQ vs Dictionary – pełne wyniki benchmarków.

Jeżeli dane, np. z bazy danych, są ładowane rzadko, a odczyty są bardzo częste, to jest to idealny kandydat na zoptymalizowany kod z wykorzystaniem słownika.

B08 Interface vs Implementation 

W pewnych przypadkach sposobem na optymalizację jest implementacja kodu za pomocą obiektu typu wartościowego zamiast obiektu referencyjnego (GetStructResultDirectly) – dzięki temu zabiegowi możemy w pewnych sytuacjach zminimalizować dodatkowe alokacje pamięci. Jednak należy zwrócić uwagę, że nie należy tego obiektu przekazywać jako interfejs (GetStructResultAsInterface) (gdyż wymusza to operację boxing). W przypadku klasy nie ma to praktycznie żadnego znaczenia. 

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B08 Interface vs Implementation – pełne wyniki benchmarków.

Czasem zastosowanie record struct zamiast klasy pozwala eliminować część alokacji. Warunek: 

• nie przekazujesz struktury jako interfejsu (boxing zwiększa koszt), 
• struktura jest używana w algorytmie intensywnie przeliczającym dane. 

W przeciwnym razie przeciążenie mentalne i ryzyko napisania błędnych konstrukcji jest większe niż korzyści. 

B09 List Manipulations zakresy zamiast pojedynczych operacji 

Kolejną istotną rzeczą w przypadku pracy z klasą typu generyczna lista jest efektywność dodawania lub usuwania elementów z listy.

Jest to szczególnie ważne, gdy programista dodaje lub usuwa zbiór elementów na początku listy. Widać wyraźnie, że dodawanie (InsertItemsAtTheBeginningOneByOne) lub usuwanie (RemoveItemsAtTheBeginningOneByOne) elementów pojedynczo jest najmniej efektywne — związane jest to z wielokrotną realokacją wewnętrznej tablicy obiektu typu list. Warto wtedy skorzystać z metod operujących na zakresach (InsertItemsAtTheBeginningByRange, RemoveItemsAtTheBeginningByRange) lub zbudować całkowicie nową listę, korzystając z LINQ (RemoveItemsAtTheBeginningByLinq).

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B09 List Manipulations – pełne wyniki benchmarków.

B10 Stack Alloc Array Pool – zarządzanie pamięcią dla wymagających 

Tworząc kod, który intensywnie operuje na małych tablicach, warto rozważyć alokowanie elementów tej tablicy na stosie zamiast na stercie.

Warto użyć wyrażenia stackalloc (więcej informacji w dokumentacji stackalloc – Microsoft Learn), mając na uwadze ograniczenia stosu. W przypadku gdy potrzebujemy użyć tablicy o większym rozmiarze, można skorzystać z obiektu ArrayPool (zob. ArrayPool<T> – Microsoft Learn), który minimalizuje nowe alokacje pamięci, reużywając już zaalokowaną pamięć.

W tym konkretnym przykładzie została dwukrotnie zaimplementowana metoda wyliczająca hash z zawartości obiektu — osobno dla małego i dużego obiektu. Pierwsza implementacja jest klasyczna (ExecuteHashCalculatorWithClassicSmallData, ExecuteHashCalculatorWithClassicLargeData), a druga wykorzystuje stackalloc i array pool (ExecuteHashCalculatorWithStackAllocOrArrayPoolSmallData, ExecuteHashCalculatorWithStackAllocOrArrayPoolLargeData). Jak widać, zoptymalizowane metody konsumują dużo mniej pamięci i działają szybciej lub porównywalnie z klasyczną implementacją.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B10 StackAlloc & ArrayPool – pełne wyniki benchmarków.

W przykładach: 

• klasyczny kod – alokuje nowe tablice przy każdym wywołaniu, 
• wersja ze stackalloc i ArrayPool – znacząco redukuje zużycia pamięci przy zachowaniu wysokiej szybkości działania. 

To świetny przykład, jak świadome zarządzanie tablicami może odciążyć zarówno CPU, jak i GC. 

B11 Throwing Exceptions 

Jeżeli chodzi o kod, który przeprowadza np. walidację danych wprowadzanych przez użytkownika, mamy dwa sposoby przekazywania użytkownikowi informacji, że wprowadzone dane nie są zgodne z określonymi regułami. Pierwszym sposobem jest rzucanie wyjątków, a drugim zastosowanie wzorca result, w którym przekazujemy informację o potencjalnych problemach. Porównując test CreateUserWithResult z CreateUserWithException, widać spory narzut czasowy oraz alokacji pamięci w przypadku tego drugiego.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B11 Throwing Exceptions – pełne wyniki benchmarków.

B12 Serialization JSON: UTF8, nie string 

W przypadku serializacji i deserializacji JSON przy użyciu System.Text.Json warto bazować bezpośrednio na danych binarnych kodowanych do formatu UTF8, na którym opiera się komunikacja sieciowa (SerializeDirectlyToUtf8, DeserializeDirectlyFromUtf8), z pominięciem transkodowania do obiektu typu string (SerializeToStringToUtf8, DeserializeFromUtf8FromString), który przechowuje dane w formacie UTF16. Porównując poniższe testy, widać znaczące różnice w zużyciu pamięci.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B12 Serialization – pełne wyniki benchmarków.

B13 Dictionary Alternate Lookup 

W przypadku wyszukiwania w słowniku można skorzystać z mechanizmu Dictionary alternate lookup, umożliwiającego przeszukiwanie słownika przy użyciu klucza innego typu niż ten, z którym został on pierwotnie utworzony. Jest to możliwe dzięki strukturze AlternateLookup, która używa klasy IAlternateEqualityComparer do porównywania różnych typów kluczy, co pozwala na poprawę wydajności — na przykład wyszukiwanie danych za pomocą klasy ReadOnlySpan<char> (CountWords2) zamiast przydzielania nowego ciągu znaków (CountWords1). W tym przykładzie widać ogromne różnice w konsumpcji pamięci.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B13 Dictionary Alternate Lookup – pełne wyniki benchmarków.

B14 Structs 

W przypadku definiowania nowych obiektów typu wartościowego zalecanym sposobem definiowania tego typu obiektów jest korzystanie z konstrukcji record struct zamiast struct. Ten pierwszy ma generowane przez kompilator metody GetHashCode i ToString. Standardowy struct używa refleksji do implementacji tych metod, która jest dużo mniej efektywna. Jest to szczególnie ważne, jeżeli tak zdefiniowanej struktury używamy jako klucza w słowniku lub korzystamy z obiektu typu HashSet. Metoda GetDictionaryKeyAsRecordStruct działa dużo efektywniej niż GetDictionaryKeyAsStruct.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B14 Structs – pełne wyniki benchmarków.

B15 Streams 

W przypadku przetwarzania dużych zbiorów danych zamiast klasycznego przetwarzania wszystkich danych w pamięci warto rozważyć zastosowanie obiektów typu stream oraz I(Async)Enumerable. Zaprezentowany przykład realizuje funkcjonalność czytania z pliku każdego wiersza, zamiany go na obiekt, wyliczenia wartości średniej i zapisania wyliczonej wartości średniej wraz z oryginalnymi wartościami w pliku wynikowym.

W pierwszej implementacji (AsyncProcessingGetRowsWriteRows) wszystkie wiersze źródłowe są wczytywane do pamięci, a następnie cała kolekcja wiersz po wierszu zapisywana jest w pliku wynikowym. W drugiej implementacji (AsyncStreamProcessingReWrite) naraz pobierany jest tylko jeden wiersz, wykonywane są obliczenia na tym wierszu, a wynik zapisywany jest bezpośrednio w pliku wynikowym. Z porównania wyników widać, że pierwsza implementacja jest minimalnie szybsza, ale zużywa dużo więcej pamięci.

Szczegółowe wyniki benchmarku zostały przedstawione w raporcie B15 Streams – pełne wyniki benchmarków.

Jeśli twój system pracuje na dużych plikach, logach lub danych z bazy danych, strumieniowe przetwarzanie pozwoli utrzymać stabilną wydajność twoich aplikacji, nawet gdy wolumen danych rośnie.

Ogólne zasady – jak pisać wydajny kod, który nadal da się utrzymać 

Na koniec kilka zasad, które warto zapamiętać, jeśli chcesz zwiększyć wydajność aplikacji, ale nadal spać spokojnie: 

• Zaczynaj od algorytmu. Dobry algorytm i odpowiednie struktury danych często dają więcej niż lokalne mikrooptymalizacje. 
• Mierz, nie zgaduj. Używaj narzędzi – Visual Studio, BenchmarkDotNet, logów – aby mierzyć realne problemy. 
• Myśl o całości – od bazy po UI. To, jak kod „rozmawia” z bazą danych, jak obsługuje API, jak działa po stronie serwera i jak zarządza pamięcią, ma wpływ na całe doświadczenie użytkownika. 
• Korzystaj z pomocy społeczności i dokumentacji. Dokumentacja Microsoft, kursy Microsoft Learn, repozytoria GitHub i przykłady kodu innych zespołów to świetne dodatkowe zasoby, które mogą pokazać ci gotowe techniki optymalizacji. 
• Pamiętaj o użytkowniku. Dla biznesu liczy się krótszy czas odpowiedzi, mniejsze koszty utrzymania, mniej maszyn, stabilność działania. Techniczne detale służą temu, by dowieźć lepszą wydajność i realne korzyści. 

Dobrze zaprojektowany, wydajny i efektywny kod C# nie musi być „magiczny” i niezrozumiały. Można łączyć pragmatyzm z jakością – tak, aby zwiększyć wydajność aplikacji tam, gdzie to naprawdę ma znaczenie, a jednocześnie zachować sensowną czytelność dla kolejnych osób, które będą ten kod rozwijać i programować w nim nowe funkcje. 

FAQ 

Go to:

1. 1. Wprowadzenie do Claude Code: twój agent AI
2. 2. Jak zacząć z narzędziem Claude Code?
3. 3. Case study: System rezerwacji sal konferencyjnych
4. 4. Krok 1: AI dekoduje chaos: analiza wymagań
5. 5. Krok 2: Od wymagań do architektury w 5 minut
6. 6. Krok 3: Meta-prompting. Twój plan implementacji
7. 7. Krok 4: Implementacja
8. 8. Jak kodować? 3 praktyczne porady na start
9. 9. Sztuczna inteligencja w programowaniu: podsumowanie

Szukając odpowiedzi na pytanie, jakiego asystenta AI używać, by programować wydajniej i lepiej, warto przyjrzeć się narzędziu Claude od firmy Anthropic. W artykule znajdziesz informacje o tym, czym jest Claude Code, jak zacząć i korzystać z Claude, oraz przegląd najlepszych praktyk programistycznych.  

Wprowadzenie do Claude Code: twój agent AI

Wyobraź sobie, że patrzysz na brief od klienta i zamiast spędzać kolejne godziny na pisaniu boilerplate’u, wpisujesz w terminal: „stwórz kompletne REST API na podstawie tych wymagań”. Po chwili masz gotowy, działający kod z obsługą błędów, walidacją i testami. To jest właśnie Claude Code.

Przeczytaj także: Najlepsze AI for coding w 2025 roku

Czym właściwie jest Claude Code firmy Anthropic?

Claude Code to narzędzie CLI (Command Line Interface) stworzone przez Anthropic. To tak, jakby mieć doświadczonego pair programming partnera, który pomaga w każdym zadaniu: od analizy i dokumentacji legacy code po implementację nowych funkcjonalności. Claude Code przy każdym zadaniu pomaga trzymać się zasad czystego programowania i stosuje wzorce projektowe.

Przykładowe prompty mogą wyglądać tak:u

Zamiast godzin analizy, wpisujemy:

„Przeanalizuj projekt i stwórz do niego szczegółową dokumentację”

Zamiast ręcznego refactoringu:

„Przekształć klasy w tym module zgodnie z SOLID”

Zamiast pisania testów:

„Wygeneruj testy jednostkowe dla klasy PaymentService”

Za chwilę pokażę ci na realnym przykładzie, jak wykorzystam Claude Code do przekształcenia chaotycznych wymagań klienta w działający system. Ale najpierw – szybki start.

Jak zacząć z narzędziem Claude Code?

Zanim przejdę do case study, pokażę ci, jak rozpocząć pracę z Claude Code.

Instalacja w 3 krokach:

1. Sprawdzam wymagania – potrzebuję zainstalowanego Node.js 18+ oraz dostępu do API Anthropic (minimum w wersji Pro).
2. Instaluję Claude Code za pomocą komendy “npm install -g @anthropic-ai/claude-code”.
   

1. Wywołuję Claude Code poleceniem “claude”. Następnie wybieram opcję z kontem Claude

Finalnie Claude Code jest gotowy do działania:

Pierwszy prompt – pokaż, co potrafisz, Claude

Zacznijmy od czegoś prostego. Załóżmy, że chcę napisać grę w kółko i krzyżyk w HTML. Sprawdźmy, czy Claude sobie z tym poradzi

Claude przystępuje do pracy:

Następnie prosi mnie o pozwolenie zapisania pliku, który stworzył:

Sprawdźmy, jak wygląda strona, którą stworzył:

W mniej niż 30 sekund otrzymałem grę w kółko i krzyżyk zaimplementowaną w HTML, JS i CSS.

Integracja z istniejącym projektem

Claude Code idealnie spisuje się w pracy na istniejących już projektach. Na potrzeby artykułu stworzyłem podstawową aplikację Spring Boot.

Aby poprawnie rozpocząć pracę na istniejącym projekcie, pomocna będzie komenda /init.

Komenda /init to polecenie, które:

• Skanuje całą strukturę projektu
• Tworzy mapę zależności między modułami
• Identyfikuje użyte technologie i frameworki
• Buduje kontekst, którego Claude będzie używał we wszystkich kolejnych interakcjach

Po wykonaniu /init w głównym katalogu projektu zostanie utworzony plik CLAUDE.md. To „instrukcja obsługi” projektu dla agenta AI.

Sprawdźmy, jak to działa w praktyce

Claude tworzy listę z czynności, jakie musi wykonać, aby poprawnie przygotować plik CLAUDE.md.

Po chwili mogę sprawdzić, co znajduje się w tym pliku:

Ten plik mogę edytować, dodając własne wytyczne, standardy kodowania czy konkretne wymagania projektu. Claude będzie je respektował w każdej interakcji.

Teraz, gdy mam już działające narzędzie, czas sprawdzić jego prawdziwą moc. Przejdźmy do realnego przypadku: systemu, który muszę dostarczyć klientowi w rekordowo krótkim czasie.

Case study: System rezerwacji sal konferencyjnych

Wyobraźmy sobie sytuację:

Do mojego zespołu trafia zlecenie od klienta, dużej firmy farmaceutycznej z Warszawy. Potrzebują systemu rezerwacji sal konferencyjnych „na wczoraj”. Termin? 4 tygodnie. Budżet? Napięty. Oczekiwania? Wysokie.

Przykładowy brief:

“Potrzebujemy systemu do zarządzania naszymi salami konferencyjnymi.
Mamy 15 sal na 3 piętrach, pracownicy ciągle się kłócą o rezerwacje.
Co ma robić:
– Pokazywać, które sale są wolne

– Rezerwować sale (z góry na cały dzień albo na godziny)

– Anulować rezerwacje

– Sale mają różne wyposażenie (projektor, flipchart, videokonferencja) – trzeba to jakoś oznaczyć

– Ma działać na komórkach!!! To ważne

– Szef chce raporty – która sala jest najpopularniejsza, wykorzystanie, itp.

Aha, zapomniałem – niektóre sale można łączyć (np. 201 + 202 = duża sala).

I jeszcze jedno – tylko niektórzy mogą rezerwować sale premium (10. piętro).”

Wyzwania, które można zauważyć

1. Niejasne wymagania: „jakoś oznaczyć”, „raporty” – każde z tych wyrażeń może oznaczać coś zupełnie innego.
2. Ukryte złożoności:
3. Łączenie sal: Czy rezerwacja jednej blokuje możliwość rezerwacji drugiej?
4. Uprawnienia: Kto decyduje o dostępie do sal premium?
5. „Na godziny”: Czy są jakieś minimalne/maksymalne czasy?
6. System raportowania: Jak szczegółowy? Dla kogo?
7. Sprzeczne priorytety: „na wczoraj” vs „zraporty i zaawansowane funkcje”
8. Techniczne wyzwania:
9. Responsywność (różne urządzenia mobilne)
10. Dostępność w czasie rzeczywistym (dwóch użytkowników nie może zarezerwować tej samej sali)
11. Logika łączenia sal (skomplikowane zależności)
12. System uprawnień (różne poziomy dostępu)

Klasyczne podejście vs Claude Code

Bez AI pierwszy tydzień spędzilibyśmy na:

• Tworzeniu obszernej dokumentacji wymagań
• Projektowaniu architektury
• Długich sesjach szacowania zadań w zespole

Zamiast tego wykorzystam Claude Code do natychmiastowej analizy i dekompozycji “chaosu”. Za chwilę pokażę ci, jak w 15 minut przekształcę ten chaotyczny email w uporządkowany plan projektu z konkretnymi zadaniami i harmonogramem.

Krok 1: AI dekoduje chaos: analiza wymagań

Wprowadzę w Claude Code poniższy prompt:

„Przeanalizuj poniższe wymagania biznesowe od klienta i:
1. Wyodrębnij wszystkie funkcjonalności (jawne i ukryte)
2. Uporządkuj je metodą MoSCoW
3. Zidentyfikuj niejasności i potencjalne problemy

[wklejony brief od klienta]
Wynik zapisz w pliku .md”

Claude przystępuje do pracy, tworząc listę zadań. Po 15 sekundach otrzymuję kompletną analizę:

Must have (MVP):

• Przeglądanie dostępności sal w czasie rzeczywistym
• Rezerwacja sali na konkretny dzień/godziny
• Anulowanie własnych rezerwacji
• Wyświetlanie wyposażenia sal
• Responsywny interfejs (mobile-first)
• Podstawowa autoryzacja użytkowników
• Podstawowe zapobieganie konfliktom (brak podwójnych rezerwacji)

Should have:

• System uprawnień dla sal premium
• Łączenie sal (z blokowaniem zależności)
• Podstawowe raporty wykorzystania
• Walidacja minimalnego czasu rezerwacji (np. 30 min)
• Historia rezerwacji użytkownika

Could have:

• Rezerwacje cykliczne
• Wyszukiwanie sal po wyposażeniu
• Eksport raportów do Excela
• Powiadomienia o zbliżających się rezerwacjach

Won’t have (w MVP):

• Zaawansowana analityka predykcyjna
• Integracja z systemami budynku (klimatyzacja, światło)

Pierwsze zaskoczenie: Claude wyłapał ukryte wymagania

Co mnie zaskoczyło? Claude zauważył rzeczy, o których klient nie wspomniał, ale które są oczywiste:

1. Konflikt rezerwacji: Co, jeśli dwóch użytkowników próbuje zarezerwować tę samą salę równocześnie?
2. Anulowanie z wyprzedzeniem: Czy można anulować rezerwację 5 minut przed czasem?
3. Łączenie sal = problem dostępności: Jeśli ktoś rezerwuje salę 201+202 jako połączoną, system musi automatycznie blokować je pojedynczo.
4. Widoczność rezerwacji: Czy wszyscy widzą, kto zarezerwował salę, czy tylko dostępny jest fakt rezerwacji?

Claude Code w kilka chwil wykonał solidną pracę. Po omówieniu z klientem niejasności, mogę przejść do następnego kroku: zaprojektowania architektury systemu.

Krok 2: Od wymagań do architektury w 5 minut

Mając uporządkowane wymagania, klasycznie zorganizowalibyśmy sesję spotkań architektonicznych. Zamiast tego, wykorzystam Claude Code do wygenerowania propozycji architektury.

Prompt do generowania architektury:

“Na podstawie tych wymagań zaprojektuj architekturę systemu:
1. Zaproponuj stack technologiczny (uzasadnij wybór)
2. Opisz strukturę modułów/serwisów
3. Zaplanuj model danych
4. Stwórz harmonogram implementacji dla 3 developerów na 4 tygodnie
5. Zidentyfikuj ryzyka techniczne
Kontekst: zespół zna React, Spring Boot i PostgreSQL
Zapisz ten plan w pliku .md”

Claude ponownie przystępuje do pracy:

Wynik? Kompletny plan techniczny

Stack technologiczny z uzasadnieniem:

Frontend: React + TypeScript + Tailwind CSS

• React: zespół zna tę technologię
• TypeScript: złożona logika biznesowa wymaga typowania
• Tailwind: szybkie tworzenie responsywnych interfejsów

Backend: Spring Boot + Spring Data JPA

• Spring Boot: zespół ma doświadczenie w tej technologii
• Spring Security: gotowe rozwiązania dla autoryzacji
• Spring Data JPA: praca z relacjami (sale łączone)

Baza: PostgreSQL

• Relacje między salami, rezerwacjami, użytkownikami
• Transakcje dla rezerwacji (ACID)
• Wydajne zapytania dla raportów

Struktura modułów frontend:

Modele danych (wybrane):

Przykładowy plan implementacji (pierwsze dwa tygodnie)

Plan jest gotowy, dzięki czemu jestem gotowy do działania. Ale jest jeszcze jedna rzecz do zrobienia: czas na meta-prompting.

Krok 3: Meta-prompting. Twój plan implementacji

Tu zaczyna się prawdziwa magia Claude Code. Zamiast ręcznie tworzyć zadania w Jirze, poproszę AI o wygenerowanie kompletnego zestawu promptów, które przeprowadzą nas przez całą implementację.

Czym jest meta-prompting?

Meta-prompting to technika, w której używamy AI do generowania promptów dla… AI. Brzmi trochę jak incepcja – w praktyce to świetne narzędzie. Claude Code analizuje plan implementacyjny i następnie tworzy serię instrukcji, które później mogę wykonywać krok po kroku.

Mój prompt:

„Przeanalizuj architekturę systemu rezerwacji sal z pliku system_architecture_plan.md i wygeneruj kompletną listę promptów do implementacji MVP.

Dla każdego promptu podaj:

– Co dokładnie ma zostać zaimplementowane

– Jakie edge case’y uwzględnić

– Z czym się integruje

Grupuj prompty według modułów. Zacznij od podstaw (model danych),

skończ na funkcjach biznesowych. Wynik zapisz w pliku .md”

Claude wygenerował komplet promptów dla MVP. Oto przykładowe z nich:

Moduł: Model danych

Prompt 1: „Stwórz encje JPA dla systemu rezerwacji sal: Room, Booking, User.

Room musi obsługiwać relację many-to-many dla sal łączonych.

Dodaj indeksy dla room.floor i booking.startTime.

Equipment przechowuj jako JSON (PostgreSQL jsonb).”

Prompt 2: „Napisz Liquibase migration dla modelu danych.

Dodaj constraint: booking.endTime > booking.startTime.

Stwórz trigger blokujący nakładające się rezerwacje.”

Moduł: REST API

Prompt 7: „Stwórz RoomController z endpointami:

GET /rooms – z filtrowaniem po floor, capacity, equipment

GET /rooms/available?start=&end= – dostępne w czasie

GET /rooms/{id}/schedule – kalendarz sali

Dodaj @Cacheable dla GET /rooms.”

Prompt 8: „Zaimplementuj BookingController:

POST /bookings – nowa rezerwacja (dto validation)

DELETE /bookings/{id} – anulowanie

GET /bookings/my – rezerwacje użytkownika

Obsłuż @ExceptionHandler dla custom wyjątków.”

Od teraz mogę rozpocząć implementację MVP. W kolejnym kroku pokażę ci, jak wykorzystam te prompty w praktyce – z rzeczywistym kodem, który Claude wygeneruje.

Krok 4: Implementacja

Mając gotowe prompty, przyszedł czas na prawdziwy test – implementację. Pokażę ci trzy przykłady, w jaki sposób Claude Code przekształcił moje prompty w działający kod.

Przykład 1: Model danych z obsługą sal łączonych

Prompt:

„Stwórz encje JPA dla systemu rezerwacji sal: Room, Booking, User. Room musi obsługiwać relację many-to-many dla sal łączonych. Dodaj indeksy dla room.floor i booking.startTime. Equipment przechowuj jako JSON (PostgreSQL jsonb).”

Claude Code wygenerował:

@Entity

@Table(name = "rooms", indexes = {

    @Index(name = "idx_room_floor", columnList = "floor")

})

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class Room {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;

    @Column(nullable = false, unique = true)

    private String name;

    @Column(nullable = false)

    private Integer floor;

    private Integer capacity;

    @Type(type = "jsonb")

    @Column(columnDefinition = "jsonb")

    private Map<String, Object> equipment;

    private Boolean isPremium = false;

    @ManyToMany

    @JoinTable(

        name = "mergeable_rooms",

        joinColumns = @JoinColumn(name = "room_id"),

        inverseJoinColumns = @JoinColumn(name = "mergeable_with_id")

    )

    @JsonIgnore

    private Set<Room> mergeableWith = new HashSet<>();

    // Helper method - Claude dodał to sam!

    public boolean canBeMergedWith(Room other) {

        return mergeableWith.contains(other) ||

               other.getMergeableWith().contains(this);

    }

}

@Entity

@Table(name = "bookings", indexes = {

    @Index(name = "idx_booking_start_time", columnList = "startTime"),

    @Index(name = "idx_booking_room_time", columnList = "room_id,startTime,endTime")

})

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class Booking {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)

    @JoinColumn(nullable = false)

    private Room room;

    @ManyToOne(fetch = FetchType.LAZY)

    @JoinColumn(nullable = false)

    private User user;

    @Column(nullable = false)

    private LocalDateTime startTime;

    @Column(nullable = false)

    private LocalDateTime endTime;

    @Enumerated(EnumType.STRING)

    private BookingStatus status = BookingStatus.ACTIVE;

    @ManyToMany

    @JoinTable(name = "booking_merged_rooms")

    private Set<Room> mergedRooms = new HashSet<>();

    @PrePersist

    @PreUpdate

    private void validateTimes() {

        if (endTime.isBefore(startTime) || endTime.equals(startTime)) {

            throw new IllegalArgumentException("End time must be after start time");

        }

    }

}

Przykład 2: Serwis z logiką konfliktów

Prompt:

„Zaimplementuj BookingService.createBooking() z logiką: – Sprawdź konflikty (również dla sal łączonych) – Waliduj uprawnienia premium – Transakcja obejmuje wszystkie sale (jeśli łączone) – Rzuć custom exceptions”

Claude Code wygenerował:

@Service

@Transactional

@RequiredArgsConstructor

@Slf4j

public class BookingService {

    private final BookingRepository bookingRepository;

    private final RoomRepository roomRepository;

    @Transactional(isolation = Isolation.SERIALIZABLE)

    public Booking createBooking(BookingCreateDto dto, User currentUser) {

        log.info("Creating booking for user {} from {} to {}",

                 currentUser.getEmail(), dto.getStartTime(), dto.getEndTime());

        // Pobierz główną salę

        Room mainRoom = roomRepository.findById(dto.getRoomId())

            .orElseThrow(() -> new RoomNotFoundException(dto.getRoomId()));

        // Sprawdź uprawnienia premium

        if (mainRoom.getIsPremium() && !currentUser.getCanBookPremium()) {

            throw new InsufficientPermissionsException(

                "User " + currentUser.getEmail() + " cannot book premium rooms"

            );

        }

        // Zbierz wszystkie sale do rezerwacji

        Set<Room> roomsToBook = new HashSet<>();

        roomsToBook.add(mainRoom);

        if (dto.getMergedRoomIds() != null && !dto.getMergedRoomIds().isEmpty()) {

            Set<Room> mergedRooms = new HashSet<>(

                roomRepository.findAllById(dto.getMergedRoomIds())

            );

            // Waliduj czy sale mogą być połączone

            for (Room mergedRoom : mergedRooms) {

                if (!mainRoom.canBeMergedWith(mergedRoom)) {

                    throw new RoomsCannotBeMergedException(

                        mainRoom.getName(), mergedRoom.getName()

                    );

                }

                if (mergedRoom.getIsPremium() && !currentUser.getCanBookPremium()) {

                    throw new InsufficientPermissionsException(

                        "Cannot book premium room: " + mergedRoom.getName()

                    );

                }

            }

            roomsToBook.addAll(mergedRooms);

        }

        // Sprawdź konflikty dla wszystkich sal

        for (Room room : roomsToBook) {

            List<Booking> conflicts = bookingRepository

                .findConflictingBookings(

                    room.getId(),

                    dto.getStartTime(),

                    dto.getEndTime()

                );

            if (!conflicts.isEmpty()) {

                throw new RoomNotAvailableException(

                    room.getName(),

                    dto.getStartTime(),

                    dto.getEndTime()

                );

            }

        }

        // Twórz rezerwację

        Booking booking = Booking.builder()

            .room(mainRoom)

            .user(currentUser)

            .startTime(dto.getStartTime())

            .endTime(dto.getEndTime())

            .status(BookingStatus.ACTIVE)

            .mergedRooms(roomsToBook.stream()

                .filter(r -> !r.equals(mainRoom))

                .collect(Collectors.toSet()))

            .build();

        return bookingRepository.save(booking);

    }

}

Przykład 3: Endpoint z cache’owaniem

„Stwórz RoomController z endpointami: GET /rooms – z filtrowaniem po floor, capacity, equipment GET /rooms/available?start=&end= – dostępne w czasie Dodaj @Cacheable dla GET /rooms.”

Claude Code wygenerował:

@RestController

@RequestMapping("/api/rooms")

@RequiredArgsConstructor

@Slf4j

public class RoomController {

    private final RoomService roomService;

    private final RoomAvailabilityService availabilityService;

    @GetMapping

    @Cacheable(value = "rooms", key = "#floor + '_' + #minCapacity + '_' + #equipment")

    public ResponseEntity<List<RoomDto>> getRooms(

            @RequestParam(required = false) Integer floor,

            @RequestParam(required = false) Integer minCapacity,

            @RequestParam(required = false) String equipment) {

        log.debug("Fetching rooms with filters - floor: {}, capacity: {}, equipment: {}",

                  floor, minCapacity, equipment);

        List<Room> rooms = roomService.findRooms(floor, minCapacity, equipment);

        return ResponseEntity.ok(

            rooms.stream()

                .map(RoomMapper::toDto)

                .collect(Collectors.toList())

        );

    }

    @GetMapping("/available")

    public ResponseEntity<List<AvailableRoomDto>> getAvailableRooms(

            @RequestParam @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME) LocalDateTime start,

            @RequestParam @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME) LocalDateTime end,

            @RequestParam(required = false) Integer minCapacity,

            @RequestParam(required = false) Boolean includeMergeable) {

        if (end.isBefore(start)) {

            throw new ValidationException("End time must be after start time");

        }

        if (Duration.between(start, end).toHours() > 24) {

            throw new ValidationException("Cannot check availability for more than 24 hours");

        }

        List<AvailableRoomDto> availableRooms = availabilityService

            .findAvailableRooms(start, end, minCapacity, includeMergeable);

        return ResponseEntity.ok(availableRooms);

    }

}

Demo modułu frontend przygotowane przez AI

Podsumowanie implementacji

Ogromna ilość czasu została zaoszczędzona przy zaledwie trzech zadaniach. Przy 23 zadaniach dla całego MVP, oszczędności mogą sięgać dni. Co warto dodać: kod był spójny, przetestowany i zawierał obsługę przypadków brzegowych.

Jak kodować? 3 praktyczne porady na start

Po miesiącu pracy z Claude Code, zebrałem kilka porad, które mogą pomóc efektywnie pracować z tym narzędziem.

1. Zacznij od małych, dobrze zdefiniowanych zadań

Nie powinniśmy rozwiązywać złożonych problemów pojedynczym promptem. Claude Code działa świetnie, gdy dajemy mu konkretne zadania.

Źle:

„stwórz cały system logowania z rejestracją i resetowaniem hasła”

Dobrze:

„stwórz model User z bcrypt hashowaniem hasła”

„dodaj endpoint POST /auth/register z walidacją email”

„zaimplementuj JWT token generation w Spring Security”

Mniejsze zadania = bardziej przewidywalny i testowalny kod. Łatwiej też zlokalizować ewentualne problemy i zrozumieć, co dokładnie robi wygenerowany kod.

2. Zawsze sprawdzaj kod, który stworzy AI

Claude Code generuje imponujący kod, ale to wciąż twoja odpowiedzialność jako dewelopera, aby sprawdzić poprawność tego kodu.

Co powinieneś sprawdzić:

• Czy kod kompiluje się bez błędów?
• Czy nazewnictwo jest zgodne z konwencjami projektu?
• Czy obsłużone są podstawowe edge case’y?
• Czy nie ma wartości na stałe zapisanych w kodzie?
• Czy logi są na odpowiednim poziomie (debug/info/error)?

Pro tip: Skonfiguruj swoje IDE, żeby automatycznie formatowało kod według twoich standardów.

Wykorzystuj kontekst projektu: Claude Code zna twój kod

Ogromną przewagą nad innymi narzędziami AI w Claude Code jest to, że rozumie kontekst projektu.

Zamiast takiego prompta:

„napisz metodę do obliczania ceny z VAT używając BigDecimal”

Możesz bezpośrednio odnieść się do projektu:

„dodaj metodę calculatePriceWithVat do PriceService, która używa tej samej logiki co calculateDiscount”

Claude Code automatycznie:

• Sprawdzi, jak wygląda PriceService
• Użyje tych samych konwencji nazewnictwa
• Zastosuje podobny styl obsługi błędów
• Doda odpowiednie importy

Pro tip: po wykonaniu komendy /init możesz odwoływać się do dowolnych plików i klas w projekcie. Claude Code „pamięta” strukturę i może naśladować istniejące wzorce.

Pamiętaj, Claude Code to narzędzie, nie zamiennik dla myślenia. Im lepiej zdefiniujesz problem, tym lepsze dostaniesz rozwiązanie.

Przeczytaj także:

• Zod AI

Sztuczna inteligencja w programowaniu: podsumowanie

Mam nadzieję, że ten wpis pokazał możliwości, jakie oferuje Claude Code w codziennej pracy developera. Ale to, co opisałem, to zaledwie ułamek potencjału tego narzędzia.

Zaawansowane możliwości Claude Code, które warto eksplorować

Claude Code to potężne narzędzie, które skrywa znacznie więcej zaawansowanych funkcjimogących  mogą zrewolucjonizować Twój workflow:

Sub-agenci: możliwość delegowania zadań do wyspecjalizowanych „pod-agentów”. Na przykład: jeden agent analizuje wymagania, drugi projektuje architekturę, trzeci implementuje kod. Każdy z nich może mieć własny kontekst i specjalizację.

Model Context Protocol (MCP): otwarty protokół pozwalający Claude Code integrować się z zewnętrznymi narzędziami i źródłami danych. Możesz podłączyć własne API, bazy danych czy systemy firmowe, dając AI dostęp do aktualnych danych projektu.

Autonomiczne debugowanie: Claude Code może samodzielnie analizować błędy, testować hipotezy i proponować poprawki. Wystarczy wskazać mu niedziałający test lub stack trace. Claude samodzielnie uruchomi test i przeanalizuje, co jest nie tak.

Chcesz wypróbować Claude Code?

Jeśli zainteresował cię ten wpis, możesz rozpocząć swoją przygodę z Claude Code już dziś. Narzędzie jest obecnie dostępne w wersji research preview – więcej informacji znajdziesz na blogu Anthropic.

Na zakończenie

Claude Code to dopiero początek rewolucji w sposobie, w jaki tworzymy oprogramowanie. To narzędzie, które już dziś pozwala ogromnie przyspieszyć development, zachowując przy tym wysoką jakość kodu.

Pamiętaj jednak: to wciąż narzędzie, nie zamiennik dla dewelopera. Największą wartość uzyskasz, łącząc możliwości AI z ludzką kreatywnością, zrozumieniem kontekstu biznesowego i umiejętnością podejmowania strategicznych decyzji.

Czy za kilka lat będziemy programować zupełnie inaczej? Wszystko na to wskazuje. Pytanie brzmi: czy będziesz wśród tych, którzy wykorzystają tę zmianę, czy tych, którzy są wobec niej sceptyczni?

AI w programowaniu | bezpłatny e-book Zautomatyzuj kodowanie z AI! Pobierz darmowy e-book i odkryj nowe możliwości Pobierz teraz!

Przejdź do:

1. 1. Biblioteka Zod
2. 2. Czym jest walidacja danych Zod i dlaczego jest tak ważna?  
3. 3. Jak używać Zod w aplikacjach opartych na AI?
4. 4. Zastosowanie Zod w preprocessingu danych  
5. 5. Jak Zod usprawnia deployment modeli AI?  
6. 6. Kluczowe cechy Zod w JavaScript  
7. 7. Jak zaimplementować walidację formularza z użyciem Zod?  

Biblioteka Zod 

I właśnie tutaj dobrym rozwiązaniem jest Zod: lekka, szybka biblioteka do walidacji danych dla TypeScript, która pozwala jasno określić, jakich struktur oczekujemy od inputu. Zamiast zgadywać, czy odpowiedź będzie zgodna z oczekiwaniami, po prostu ją walidujemy. Jeśli coś się nie zgadza – dostajemy informację o błędzie i jasny komunikat. Jeśli wszystko gra – możemy bezpiecznie przetwarzać dane dalej. Mamy nad wszystkim kontrolę, jeszcze zanim przekażemy dalej dane do naszej logiki biznesowej.  

Zod działa jak filtr bezpieczeństwa – pozwala odrzucić błędne odpowiedzi, zanim trafią do logiki aplikacji. Dzięki temu zyskujemy nie tylko większą kontrolę, ale też spokój ducha: nawet jeśli AI trochę „zbłądzi”, warstwa frontend to odpowiednio obsłuży i tego nie odczuje.  

Czym jest walidacja danych Zod i dlaczego jest tak ważna?  

Zod to biblioteka TypeScript / JavaScript, która umożliwia tworzenie schematów danych (schemas), wykorzystywanych zarówno do walidacji danych w czasie rzeczywistym, jak i do generowania typów w czasie kompilacji. Dzięki niej możemy opisać strukturę danych, której aplikacja oczekuje, i automatycznie sprawdzić, czy rzeczywiste dane, które przekazaliśmy do inputu spełniają wszystkie nasze założenia.  

W kontekście AI – gdzie dane zwracane przez modele bywają nieprzewidywalne i często nie trzymają się jednej struktury, walidacja staje się wręcz obowiązkowa. Nawet drobna zmiana w odpowiedzi modelu może wywołać błąd w aplikacji, jeśli nasz kod zakłada konkretną strukturę danych. Zod pozwala temu zapobiec, sprawdzając zgodność danych, zanim trafią dalej do logiki biznesowej.  

Przeczytaj także:

• Najlepsze AI for coding
• AI w programowaniu: Github Copilot

Jak używać Zod w aplikacjach opartych na AI? (validation in AI with Zod) 

Zod można zintegrować z dowolną aplikacją JavaScript, zarówno po stronie frontendu, jak i backendu. W kontekście AI najczęściej wykorzystywany jest do:  

• walidacji odpowiedzi z API (np. OpenAI),  
• generowania interfejsów dynamicznych,  
• utrzymywania spójnych kontraktów danych między frontendem a modelem.  

Dzięki helperowi zodResponseFormat w SDK OpenAI możemy łatwo powiązać schemat Zod z odpowiedzią modelu:  

const MathResponse = z.object({
  steps: z.array(z.object({
    explanation: z.string(),
    output: z.string(),
  })),
  final_answer: z.string(),
});

const completion = await client.beta.chat.completions.parse({
  model: 'gpt-4o',
  messages: [...],
  response_format: zodResponseFormat(MathResponse, 'math_response'),
});

Taka integracja sprawia, że odpowiedź modelu jest walidowana automatycznie i możemy bezpiecznie korzystać z jej zawartości w aplikacji.  

Jeśli korzystamy z funkcji narzędzi (tool calls), możemy użyć zodFunction, by automatycznie zmapować argumenty na typy Zod:  

const queryArgs = z.object({ ... });

const completion = await client.beta.chat.completions.parse({
  model: 'gpt-4o',
  messages: [...],
  tools: [zodFunction({ name: 'query', parameters: QueryArgs })],
});

Zod daje nam kontrolę nad strukturą danych – zarówno tych zwracanych przez model, jak i tych przekazywanych do funkcji. Dzięki temu unikamy błędów wynikających z niespójności formatu i mamy większą przewidywalność działania aplikacji.  

Zastosowanie Zod w preprocessingu danych  

Zod sprawdza się nie tylko po stronie odbioru danych z modelu AI, ale również wcześniej – podczas przygotowania danych wejściowych. Preprocessing to moment, w którym możemy upewnić się, że to, co wysyłamy do modelu, jest kompletne, poprawnie sformatowane i zgodne z oczekiwanym typem.  

Typowe zastosowania Zod w preprocessingu:  

• walidacja danych wprowadzanych przez użytkownika przed wysłaniem zapytania do AI,  
• konwersja typów, np. zamiana ciągów znaków (stringa) na daty,  
• czyszczenie i porządkowanie danych z zewnętrznych źródeł, jak API czy formularze.  

const dateSchema = z.string().transform(str => new Date(str));
const parsedDate = dateSchema.parse("2024-08-06"); // => obiekt typu Date

Dzięki funkcji .transform() możemy nie tylko sprawdzić, czy dane mają odpowiedni format, ale też przekształcić wprowadzone dane do postaci, która jest odpowiednio dostosowana do dalszego przetwarzania w aplikacji. To szczególnie przydatne, gdy dane mają służyć jako prompt lub parametr w zapytaniu do modelu AI.  

Preprocessing z użyciem Zod to prosty sposób na zminimalizowanie błędów i zwiększenie kontroli nad danymi, zanim jeszcze trafią do modelu.  

Jak Zod usprawnia deployment modeli AI?  

Zod to nie tylko narzędzie deweloperskie – jego zastosowanie ma realne przełożenie na jakość wdrożeń modeli AI w środowiskach produkcyjnych. Pozwala budować solidny bufor bezpieczeństwa pomiędzy często nieprzewidywalnym modelem AI a wymaganiami naszej aplikacji.  

Biblioteka Zod w procesie deploymentu pomaga:  

• Zwiększyć odporność aplikacji na zmiany – zmiana prompta, wersji modelu czy struktury danych nie musi oznaczać błędów, jeśli dane przechodzą przez schematy walidacyjne tworzone przez Zoda.  
• Szybciej debugować problemy – zamiast domyślać się, co poszło nie tak, dostajemy jasne, czytelne komunikaty o błędach.  
• Pisać testy jednostkowe – schematy Zod mogą pełnić funkcję walidatorów i źródła przykładowych danych wejściowych do testów.  

Zamiast więc opierać się na założeniu, że wszystko w końcowej fazie projektu działa, możemy zbudować system, który rzeczywiście przewiduje błędy i potrafi się przed nimi obronić.  

Z perspektywy wdrożeniowej oznacza to mniej awarii, większą spójność danych i łatwiejsze utrzymanie całego pipeline’u – od prompta po końcowy interfejs użytkownika.  

Kluczowe cechy Zod w JavaScript  

Zod oferuje nowoczesne podejście do walidacji danych w JavaScript i TypeScript. Jego główne zalety to:  

• Deklaratywność – schematy są czytelne, przejrzyste i proste do napisania. Możemy z łatwością tworzyć złożone struktury bez nadmiaru kodu.  

const UserSchema = z.object({
  name: z.string().min(3),
  age: z.number().int().positive(),
  email: z.string().email(),
});

• Bezpośrednia integracja z TypeScriptem – Zod automatycznie wyciąga typy z definicji schematów (z.infer), dzięki czemu nie musimy pisać typów dwa razy.  

type User = z.infer<typeof UserSchema>;

• Walidacja i transformacja w jednym miejscu – możemy nie tylko sprawdzać dane, ale też odpowiednio je przekształcać (np. string → Date, liczba → boolean, itp.).  

const DateSchema = z.string().transform(str => new Date(str));
const parsedDate = DateSchema.parse("2024-08-06");

• Obsługa błędów – metody safeParse i parse pozwalają wygodnie obsługiwać błędy. Pierwsza nie rzuca wyjątku, a druga daje pełną kontrolę nad błędami typu ZodError.  

const result = UserSchema.safeParse(userData);
if (!result.success) {
  console.log(result.error.format());
}

• Czytelne komunikaty walidacyjne – błędy można formatować, w pełni kontrolować, mapować i wyświetlać w aplikacjach frontendowych w sposób przyjazny dla użytkownika.  

function formatZodErrors(error: z.ZodError) {
  return error.errors.reduce((acc, err) => {
    const field = err.path.join(".");
    acc[field] = err.message;
    return acc;
  }, {} as Record<string, string>);
}

• Rozszerzalność – dzięki metodzie .refine() możemy łatwo dodawać własne warunki i logikę walidacyjną.  

const PasswordSchema = z.string()
  .min(8, "Hasło musi mieć min. 8 znaków")
  .refine(val => /\d/.test(val), {
    message: "Hasło musi zawierać cyfrę",
  });

• Chaining – możemy łączyć wiele reguł walidacyjnych w łańcuchach co ułatwia tworzenie złożonych walidacji, np. .min(3).max(20).regex(…),.  

const NameSchema = z.string()
  .min(3, "Za krótkie")
  .max(50, "Za długie")
  .regex(/^[a-zA-Z\s]+$/, "Tylko litery i spacje");

• Użyteczność w całym stacku – Zod sprawdza się zarówno walidacji danych użytkownika w formularzach (React Hook Form), jak i walidacji odpowiedzi API czy typów w bazach danych  

Jak zaimplementować walidację formularza z użyciem Zod?  

Zod doskonale integruje się z popularnymi narzędziami do obsługi formularzy, takimi jak React Hook Form. Dzięki temu możemy w prosty sposób połączyć walidację danych z typowaniem w TypeScript i uzyskać czytelny kod oraz spójne komunikaty błędów.  

Załóżmy, że tworzymy prosty formularz rejestracyjny. Najpierw definiujemy schema:  

const RegisterSchema = z.object({
  name: z.string().min(3, "Imię musi mieć co najmniej 3 znaki"),
  email: z.string().email("Niepoprawny adres e-mail"),
  password: z.string()
    .min(8, "Hasło musi mieć co najmniej 8 znaków")
    .refine(val => /\d/.test(val), {
      message: "Hasło musi zawierać cyfrę",
    }),
});

Następnie łączymy schema z formularzem:  

import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';

const form = useForm({
  resolver: zodResolver(RegisterSchema),
});

const { register, handleSubmit, formState: { errors } } = form;

W JSX podpinamy pola i wyświetlamy błędy:  

<form onSubmit={handleSubmit(formDetails => console.log(formDetails))}>
  <input {...register("name")} placeholder="Imię" />
  {errors.name && <p>{errors.name.message}</p>}

  <input {...register("email")} placeholder="Email" />
  {errors.email && <p>{errors.email.message}</p>}

  <input {...register("password")} placeholder="Hasło" type="password" />
  {errors.password && <p>{errors.password.message}</p>}

  <button type="submit">Zarejestruj się</button>
</form>

Taka integracja daje nam:  

• automatyczną walidację pól,  
• pełne typowanie danych,  
• spójne i konfigurowalne komunikaty błędów,  
• prostą integrację z istniejącym kodem Reacta.  

AI w programowaniu | bezpłatny e-book

Zautomatyzuj kodowanie z AI! Pobierz darmowy e-book i odkryj nowe możliwości

Pobierz teraz!

Podsumowanie  

W świecie, gdzie dane generowane przez AI są dynamiczne i często nieprzewidywalne, warto zadbać o silne fundamenty naszych projektów. Zod może pełnić rolę warstwy ochronnej – zapewniając walidację, transformację i typowanie danych w jednym miejscu. To nie tylko techniczny dodatek, ale kluczowy element architektury, który pozwala budować odporne, stabilne i łatwe w utrzymaniu integrację z modelami AI.  

Zod to solidna biblioteka z rosnącą społecznością i aktywnym wsparciem, którą z powodzeniem można wykorzystać nie tylko w integracjach z wykorzystaniem AI, ale także w codziennych projektach frontendowych – od formularzy po obsługę API.  

I choć treść książki ma pesymistyczne wybrzmienie, może stanowić źródło inspiracji na temat drogi rozwoju sztucznej inteligencji w dalekiej przyszłości i zmusić do refleksji nad kierunkiem podążania przez współczesne algorytmy. Chociaż obecne możliwości AI nie są jeszcze aż tak rozwinięte (w porównaniu do przytoczonego Golema), to już mają istotny wpływ na cyfrową transformację, przekształcając świat na wielu płaszczyznach. 

AI w programowaniu  

Generowanie kodu  

Od jakiegoś czasu narzędzia sztucznej inteligencji rewolucjonizują wiele obszarów, nie pomijając procesu tworzenia oprogramowania. Wprowadzają nowe możliwości zwiększające nie tylko produktywność, ale też dokładność i innowacyjność, przyspieszają również sam proces tworzenia oprogramowania. W tym momencie należy wyróżnić przede wszystkim generatywną sztuczną inteligencję (GenAI – uogólniając, to AI potrafiąca tworzyć nowe treści), która usprawnia cały proces poprzez automatyzację istotnych kroków – generowania pomysłów, gromadzenia wymagań, a także kodowania oraz jego nieodłącznego procesu testowania. 

Wsparcie prac programistycznych 

AI szybko staje się integralną częścią oprogramowania wykorzystywanego w developmencie aplikacji, będąc jednym z elementów cyfrowej transformacji przedsiębiorstw. Zespoły deweloperskie dostosowują swoje środowiska, integrując narzędzia sztucznej inteligencji, zapewniając nie tylko interoperacyjność, ale również stawiają czoła nowym wyzwaniom, jak choćby bezpieczeństwo danych. Rosnąca rola AI w tym obszarze podkreśla jej potencjał do zrewolucjonizowania metod tworzenia oprogramowania. 

Wykorzystanie algorytmów w automatyzacji 

Obecnie mamy do dyspozycji wiele narzędzi, za pomocą których znacząco można przyspieszyć prace nad projektem. Interpretują opisy tworzone w języku naturalnym (prompty) i generują sugestie, kod, zasoby potrzebne do testów i wiele innych, przydatnych rzeczy – zależnie od potrzeb. Zaawansowane algorytmy analizują środowisko, kod, optymalizując rozwiązania i wspomagając zespoły w codziennej pracy. Umożliwiają również analizę ogromnych zbiorów danych, wspierając optymalizację wydajności aplikacji oraz przewidywanie potencjalnych problemów. Ma to znaczący wpływ na szybkość tworzenia kodu, redukcję ludzkich błędów, przyczynia się do poprawy bezpieczeństwa, a przede wszystkim pozwala programistom skupić się na realizowaniu bardziej złożonych i kreatywnych zadań. 

Jakie są korzyści z użycia AI w procesie tworzenia oprogramowania 

Korzyści w ujęciu ogólnym przedstawiłem we wstępie, więc w tej sekcji postaram się zwięźle opisać kilka konkretnych przykładów, które moim zdaniem zasługują na szczególną uwagę: 

• Przewidywanie błędów – poprzez analizę wzorców w repozytoriach projektu narzędzia AI mogą pomóc wykryć potencjalne błędy, luki lub podatności. 

• Testowanie – odpowiednio przygotowane wymagania i kryteria akceptacji mogą posłużyć za bazę do stworzenia scenariuszy testowych, dzięki czemu znacznie skraca się czas, potrzebny zwykle na wymyślanie ich od podstaw. W asyście AI można także pokusić się o refaktoryzację już istniejących przypadków testowych, co może pomóc w ich optymalizacji i zwiększeniu pokrycia testów. 

• Generowanie kodu – dzięki narzędziom AI programiści mają możliwość korzystania z pomocy wirtualnego asystenta, który wspomaga ich w codziennej pracy. Na podstawie danych wejściowych pisanych w języku naturalnym, asystent AI zasugeruje fragment kodu lub wygeneruje całą funkcję, co przyspiesza pracę i może automatyzować rutynowe działania (np. pisanie prostych, schematycznych skryptów).
  
• Optymalizacja i refaktoryzacja – łączy się z powyższym. Z pomocą AI można optymalizować istniejący kod, dzięki czemu aplikacja może być stabilniejsza, bezpieczniejsza, wydajniejsza, a więc i bardziej niezawodna. 

• Bezpieczeństwo – z pomocą narzędzi AI można pokusić się o próbę zidentyfikowania potencjalnych luk bezpieczeństwa, a w przypadku ich znalezienia – AI zasugeruje poprawki. Narzędzia te pozwalają również analizować zachowanie uzytkowników i wykrywać nietypowe działania, wskazujące na przykład na próby ataku lub potencjalne przejęcie konta klienta.  
   
  Tak działa na przykład weryfikacja behawioralna banku ING. Algorytmy AI na bieżąco uczą się zachowania użytkownika poprzez analizowanie jego interakcji z aplikacją banku, co zwiększa prawdopodobieństwo zablokowania dostępu do konta w przypadku przejęcia go przez przestępcę. Innym przykładem niech będzie sytuacja opisana przez Google –  dzięki sztucznej inteligencji udało się znaleźć błąd 0-day (nieznana podatność lub luka, mogąca zostać wykorzystana do przeprowadzenia ataku).  

• Zarządzanie – można i w tym procesie zaprzęgnąć sztuczną inteligencję i wykorzystać ją w celu zautomatyzowania planowania i zarządzania zasobami. Mając historyczne dane, narzędzia AI mogą zasugerować potencjalny czas trwania nowych etapów tworzenia oprogramowania i pomóc w odpowiedniej alokacji zasobów w celu optymalnego ich wykorzystania. 

• Tworzenie dokumentacji – wielu programistów nie przepada za sporządzaniem dokumentacji. Jest to czasochłonny proces, który można by poświęcić między innymi na rozwój i utrzymanie kodu. I w tym aspekcie sztuczna inteligencja wyciąga pomocną dłoń – jest doskonałym narzędziem do prowadzenia dokumentacji projektowej, odciążając programistów. Na podstawie kodu aplikacji tworzy opis i zapewnia stałą aktualizację dokumentacji.  

• Projektowanie UX – można wykorzystać AI do wspomagania projektowania doświadczenia użytkowników. Przykładowo – prowadząc testy A/B i wykorzystując dane z nich zgromadzone, AI może zasugerować odpowiedni interfejs bądź funkcjonalność. Odpowiednie polecenia w  narzędziu AI generującym obrazy pomogą wygenerować szablon UI, mogący stanowić bazę pod ostateczny wygląd aplikacji. 

• Pomoc w tworzeniu bardziej inteligentnych aplikacji – wprowadzając zaawansowane funkcje AI do tworzonego programu (na przykład rozpoznawanie mowy, czat) można podnieść wartość i atrakcyjność aplikacji, dzięki czemu będzie ona wyróżniała się na tle konkurencji i może zwiększyć liczbę jej użytkowników. 

• Analiza danych użytkowników – AI może analizować dane użytkowników w celu poprawy doświadczeń podczas korzystania z aplikacji. Szczególne korzyści może przynieść to branży e-commerce, gdzie AI wspiera  tworzenie algorytmów rekomendacji, dzięki czemu klienci mogą widzieć reklamy i sugestie produktów najbardziej pasujące do ich potrzeb. 

• Wspomaganie DevOps i CI/CD – z pomocą AI można analizować systemowe logi, raporty, historie wdrożeń, aby wykrywać anomalie i przewidywać potencjalne awarie. Narzędzia takie jak Datadog czy Splunk wykorzystują uczenie maszynowe do monitorowania aplikacji i infrastruktury w czasie rzeczywistym. Wdrożenie AI w DevOps i CI/CD pozwala zespołom programistycznym i operacyjnym na bardziej efektywne zarządzanie cyklem życia oprogramowania. 

Jak korzystać z narzędzi AI w praktyce? Tworzymy prompty do testowania 

Poniżej zaprezentuję prosty przykład wykorzystania AI jako asystenta w programowaniu. Bazę stanowi kod Playwright dostępny bezpośrednio po zainstalowaniu narzędzia. Znajduje się w nim plik z przykładowymi testami, w którym utworzę jeden dodatkowy test z wykorzystaniem GitHub Copilot. Test jest prosty: polega na otwarciu strony domowej Playwright, kliknięciu przycisku ‘Get Started’ i asercji przekierowania na stronę ’https://playwright.dev/docs/intro’ poprzez zweryfikowanie poprawności adresu URL i tekstu wyświetlonego na niej nagłówka (Installation). 

1. Prompt opisujący test: 

Write a test that navigates to 'https://playwright.dev/’ page and clicks 'Get started’ button. Then verify that user has landed on 'https://playwright.dev/docs/intro’ page by verifying page header text that should be 'Installation’. 

2. Odpowiedź wygenerowana przez Copilot: 

Here’s the Playwright test that navigates to the 'https://playwright.dev/’ page, clicks the 'Get started’ button, and verifies that the user has landed on the 'https://playwright.dev/docs/intro’ page by checking the page header text: 

import { test, expect } from '@playwright/test'; 

test('navigate to Get Started and verify Installation page', async ({ page }) => { 

  // Navigate to the Playwright homepage 

  await page.goto('https://playwright.dev/'); 

  // Click the 'Get started' button 

  await page.getByRole('link', { name: 'Get started' }).click(); 

  // Verify the URL is correct 

  await expect(page).toHaveURL('https://playwright.dev/docs/intro'); 

  // Verify the page header text is 'Installation' 

  await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible(); 

});

Copilot stworzył test, dodatkowo opatrując komentarzem każdą znajdującą się w nim akcję. Poniżej zamieszczam zrzut ekreanu z VS Code, na którym widać UI z wykorzystaniem czatu AI. 

Następnie poprosiłem Copilota o małą refaktoryzację stworzonego przez niego kodu – aby zaktualizował go poprzez przeniesienie hardkodowanych wartości do zmiennych w celu poprawy czytelności kodu. 

 
1. Prompt:  

Refactor the proposed code by moving hardcoded values to variables, in order to make the code more readable. 

2. Odpowiedź: 

Here’s the refactored code with hardcoded values moved to variables for better readability: 

import { test, expect } from '@playwright/test'; 

test('navigate to Get Started and verify Installation page', async ({ page }) => { 

  // Define reusable variables 

  const baseUrl = 'https://playwright.dev/'; 

  const getStartedLinkName = 'Get started'; 

  const expectedUrl = 'https://playwright.dev/docs/intro'; 

  const expectedHeader = 'Installation'; 

  // Navigate to the Playwright homepage 

  await page.goto(baseUrl); 

  // Click the 'Get started' button 

  await page.getByRole('link', { name: getStartedLinkName }).click(); 

  // Verify the URL is correct 

  await expect(page).toHaveURL(expectedUrl); 

  // Verify the page header text is 'Installation' 

  await expect(page.getByRole('heading', { name: expectedHeader })).toBeVisible(); 

});

Zgodnie z przewidywaniem Copilot poradził sobie z tym zadaniem poprawnie, identyfikując parametry mogące być przypisane do zmiennych i tworząc je. 

Na koniec poprosiłem o stworzenie dokumentacji testu: 

 
1. Prompt: 

Write and apply a description of the test that could be used as documentation. 

2. Odpowiedź: 
 
Test Description: 

Test Name: Navigate to Get Started and Verify Installation Page 

This test verifies the navigation flow on the Playwright documentation website. It performs the following steps: 
 

1. Navigates to the Playwright homepage (https://playwright.dev/). 

2. Clicks the „Get started” link on the homepage. 

3. Verifies that the user is redirected to the „Introduction” page (https://playwright.dev/docs/intro).  

4. Confirms that the page header text is „Installation”. 

Nie tylko programowanie – sztuczna inteligencja w testach 

Testowanie to krytyczny etap w wytwarzaniu oprogramowania. Ma kluczowe znaczenie w gwarantowaniu jakości kodu, niezawodności, wiarygodności i bezpieczeństwa tworzonego systemu. Obecnie testowanie napotyka na swojej drodze różne trudności. Rosnąca złożoność struktur oprogramowania sprawia, że przetestowanie wielu potencjalnych ścieżek mogących zawierać błędy staje się po prostu skomplikowane. Narzędzia technologii AI znajdują zastosowania i tutaj – za ich pomocą tester może zoptymalizować swoją pracę w zakresie: 

• generowania przypadków testowych, które można w dalszym etapie modyfikować, gdy zajdzie taka potrzeba; 

• wspomagania generowania skryptów automatycznych – z wykorzystaniem narzędzi typu Copilot; 

• automatyzacji powtarzalnych zadań – co pozwala zaoszczędzić czas i skupić się na bardziej istotnych lub skomplikowanych zadaniach; 

• analizowania i tworzenia raportów testowych – dzięki asyście przy analizie i tworzeniu raportów można uzyskać bardziej szczegółowe dane na temat wyników testów, co pozwala na uzyskanie jakościowych informacji na temat stanu oprogramowania i ewentualnych błędów; 

• tworzenia danych testowych – AI może analizować wymagania aplikacji oraz specyfikację systemu, aby automatycznie generować odpowiednie dane testowe, które będą używane w różnych scenariuszach testowych. Dane mogą być bardzo różnorodne, co przekłada się na ich lepszą reprezentatywność dla rzeczywistych przypadków użycia aplikacji. Również przypadki brzegowe (edge cases), które bywają trudne do przewidzenia, mogą zostać zidentyfikowanie przez AI i odpowiednio pokryte danymi wejściowymi. Dzięki temu z pozoru rzadkie, ale ważne scenariusze, mogące mieć wpływ na stabilność aplikacji, mogą zostać zidentyfikowane i odpowiednio zaadresowane. Zwiększa to również pokrycie testów, pomagając w wykrywaniu potencjalnych problemów, które mogłyby umknąć tradycyjnym metodom testowania; 

• tworzenie dokumentacji testowej – AI można wykorzystać do tworzenia i utrzymywania dokumentacji testowej. 

Jakie są najlepsze narzędzia AI dla programistów i testerów 

Na rynku istnieją już setki, jeśli nie tysiące narzędzi wykorzystujących sztuczną inteligencję. Możliwości tych innowacyjnych rozwiązań z powodzeniem  mogą być wykorzystywane przez programistów i testerów. Wybór odpowiednich rozwiązań może jednak stanowić wyzwanie, dlatego warto skupić się na tych, które rzeczywiście zwiększają efektywność pracy, automatyzują powtarzalne zadania i pomagają unikać błędów. Wśród dostępnych narzędzi znajdują się zarówno inteligentni asystenci wspomagający pisanie kodu, jak i zaawansowane systemy do testowania, analizy błędów oraz optymalizacji procesów CI/CD.

W tej sekcji krótko omówię kilka narzędzi, których wykorzystanie może usprawnić codzienną pracę w projekcie. 

GitHub Copilot 

To obecnie jedno z najpopularniejszych narzędzi wspomagających pisanie kodu. Za jego pomocą można pisać kod efektywniej i szybciej, dzięki czemu programiści mogą więcej czasu poświęcić na rozwój oprogramowania w szerszym kontekście – współpracy w zespole czy skupieniu się na problemach związanych z logiką w aspekcie całościowym aplikacji. Słowem – zwiększa produktywność i przyspiesza wytwarzanie oprogramowania. 

Narzędzia takie jak GitHub na bieżąco w trakcie pisania kodu sugerują rozwiązania, można też użyć funkcji czatu w celu uzyskania pomocy dotyczącej pisanego kodu. Istnieje też możliwość korzystania z niego przez CLI. 

Dodatkowo w wersji Enterprise oferuje opcję generowania opisu pull requestów oraz tworzenie i zarządzanie dokumentacjami repozytoriów w formie baz wiedzy (knowledge bases), które stanowią kontekst dla czatu Copilot. Dzięki temu Copilot przeszukuje bazę wiedzy pod kątem odpowiednich informacji i zwraca zsyntezowaną odpowiedź.  

Doskonale sprawdza się jako narzędzie do uzupełniania kodu, w szczególności dla przypadków, w których zwykle poszukujemy inspiracji w internecie, np. na StackOverFlow. Często zdarza się, że podobny problem, nad którym pracujemy, został już kiedyś napotkany i opisany, więc analiza danego wątku pozwala na zaimplementowanie rozwiązania w swoim kodzie. Dzięki Copilotowi można pominąć ten etap i za pomocą odpowiedniego prompta sprecyzować, czego potrzebujemy. Z dużym prawdopodobieństwem wygenerowany zostanie odpowiedni kod, nie zawsze idealny, ale wystarczający, żeby po niewielkich modyfikacjach otrzymać działającą funkcję. 

Jego zaletą jest też możliwość zintegrowania go z najpopularniejszymi IDE – Visual Studio, Visual Studio Code, JetBrains. 

Cursor 

Cursor, w przeciwieństwie do GitHub Copilota, nie jest jedynie rozszerzeniem, ale pełnym IDE korzystającym z narzędzi AI. Został zaprojektowany w celu zwiększenia produktywności programistów poprzez integrację zaawansowanych funkcji sztucznej inteligencji bezpośrednio ze środowiskiem kodowania. Warto wiedzieć, że powstał na bazie VS Code (jest jego forkiem), a więc zachowuje interfejs i ekosystem VS Code, co ułatwia ewentualne przejście na ten edytor. 

Posiada opcje takie jak generowanie, przewidywanie i uzupełnianie kodu oraz automatyczne poprawianie. 

Jego kluczową cechą jest sposób “rozumienia” przez niego kodu – analizuje cały kontekst projektu. Oferuje kilka dodatkowych funkcji, dzięki którym asystent AI może działać jeszcze dokładniej. Jest to na przykład indeksowanie bazy kodu (które jest włączone domyślnie), każdy nowo dodany plik zostanie zaindeksowany i włączony do kontekstu aplikacji. Oprócz indeksowania plików, oferuje również tworzenie reguł dostosowujących działanie AI: globalnie oraz z ograniczeniami w ramach konkretnego projektu. 

ChatGPT 

To jedno z najpopularniejszych narzędzi AI dostępne w internecie, może być również z powodzeniem wykorzystane w inżynierii oprogramowania. Jest uniwersalne zarówno dla programistów jak i testerów – za jego pomocą można tworzyć między innymi kod, skrypty, dane testowe, scenariusze – i tak dalej. Dzięki wszechstronności może być wykorzystany jako asystent służący dobrą radą w wielu aspektach. 

Oprócz czata GPT można w tym celu wykorzystać również inne narzędzia ogólnego przeznaczenia bazujące na LLM, jak Gemini czy Microsoft Copilot. 

Applitools 

To narzędzie służące głównie do testowania, monitorowania i zarządzania wizualnym aspektem aplikacji. Wykorzystuje sztuczną inteligencję do wykonywania testów wizualnych, skutecznie identyfikując wizualne błędy w aplikacjach, na przykład przez analizę elementów wyświetlanych w interfejsie – czy nie nakładają się na siebie, są w jakiś sposób niewidoczne, wychodzą poza swój obszar. Swoje testy może wykonywać na wielu przeglądarkach i platformach. Można za jego pomocą sprawdzać również pliki PDF. Applitools można zintegrować z popularnymi narzędziami do automatyzacji testów, takimi jak Selenium, Playwright, Appium, Cypress. 

Amazon CodeGuru 

To narzędzie wspierające przegląd kodu. Dzięki wykorzystaniu uczenia maszynowego i zautomatyzowanego procesu “rozumowania” pomaga zidentyfikować luki w kodzie, dostarcza zalecenia dotyczące sposobu ich naprawienia i śledzi ich status aż do momentu ich zamknięcia. Można je zintegrować na dowolnym etapie wytwarzania oprogramowania, włączając je w proces CI/CD. Twórcy dodatkowo zapewniają, że nie jest konieczne wykorzystywanie dodatkowych maszyn wirtualnych w celu jego uruchomienia – wystarczy zintegrować CodeGuru z wykorzystywanymi już narzędziami, a w zależności od obciążenia będzie samoczynnie skalowany w górę lub w dół. 

Testcraft 

To bezpłatne i otwartoźródłowe rozszerzenie przeglądarki, wykorzystujące sztuczną inteligencję do wspomagania testowania. Jego kluczową cechą jest możliwość generowania pomysłów na testy w oparciu o elementy widoczne na stronie internetowej. Pozwala również na automatyczne generowanie skryptów testowych dla popularnych frameworków automatyzacji – Playwright, Cypress, czy biblioteki Selenium. Skrypty można wygenerować w wielu językach programowania, znajdzie więc miłośników zarówno wśród testerów manualnych, jak i automatyzujących. 

Podsumowanie: Wykorzystanie AI w programowaniu i testowaniu  

Dobrze zaimplementowana sztuczna inteligencja może odegrać kluczową rolę w rozwoju oprogramowania, znacząco przyspieszając i usprawniając procesy na różnych etapach tworzenia oprogramowania. Dzięki AI można automatyzować pisanie kodu, testowanie, debugowanie oraz zarządzanie procesami CI/CD, co prowadzi do zwiększenia efektywności, redukcji kosztów i minimalizacji liczby błędów. 

Jednak należy pamiętać o drugiej stronie medalu. Sztuczna inteligencja, choć pozwala oszczędzać czas i ułatwia wykonywanie powtarzalnych zadań, nie zawsze generuje poprawne lub optymalne rozwiązania. Mając na uwadze fakt, że nowoczesne aplikacje często składają się z wielu modułów, są zintegrowane z wieloma zewnętrznymi usługami i systemami, sztuczna inteligencja, mimo że stanowi potężne wsparcie, nie zawsze jest bezbłędna, zwłaszcza w tak złożonych środowiskach.  

AI dobrze radzi sobie z podstawowymi i średnio zaawansowanymi zadaniami, ale może mieć trudności z bardziej skomplikowanymi zagadnieniami, np. optymalizacją wydajności w dużych systemach, ze specyficznymi wzorcami projektowymi czy zaawansowanym debugowaniem. Nie można pominąć również potencjalnych zagrożeń w kwestii bezpieczeństwa. 

Ostatecznie, AI powinna być traktowana jako wsparcie, a nie całkowite zastępstwo dla ludzkiej wiedzy i doświadczenia. Skuteczność automatyzacji opartej na AI zależy od jej mądrego wykorzystania. W połączeniu z kompetencjami specjalistów może ona stać się potężnym narzędziem wspierającym rozwój i utrzymanie wysokiej jakości oprogramowania.  Jednak wymaga świadomej kontroli i odpowiedzialnego wdrażania w procesy technologiczne.  

Choć obecne systemy AI, w tym narzędzia wspierające programistów i testerów, nie osiągnęły jeszcze poziomu przedstawionego przez Lema w “Golem XIV”, to ich rola w cyfrowej transformacji staje się coraz bardziej widoczna. Sztuczna inteligencja zyskuje na znaczeniu, automatyzując powtarzalne procesy, optymalizując kod oraz wspomagając analizy danych w czasie rzeczywistym. Współczesne algorytmy, choć bardzo zaawansowane, nie są jeszcze pozbawione błędów i ograniczeń, szczególnie w kontekście złożonych aplikacji oraz integracji z innymi systemami. To, co dziś oferuje sztuczna inteligencja, to jedynie przedsmak tego, co może się wydarzyć w przyszłości. 

Według badań firmy McKinsey rozwiązania AI i low-code mogą pozytywnie wpłynąć na produktywność deweloperów, zwiększając ją nawet o 45%. Jednym z cenionych narzędzi bazujących na sztucznej inteligencji jest GitHub Copilot, który zmienia oraz usprawnia proces programowania.

Jak korzystać z GitHub Copilot w codziennym programowaniu? 

Aby rozpocząć korzystanie z GitHub Copilot, musimy spełnić kilka prostych warunków.

Po pierwsze – jeśli nie posiadamy konta na github.com – musimy je założyć. Będzie to niezbędny krok do aktywowania subskrypcji naszego asystenta. Jeśli to mamy już za sobą, logujemy się na swoje konto, wybieramy pakiet, który odpowiada naszym potrzebom. Dostępnych mamy kilka wariantów – od planu darmowego służącego do nauki po plan dla profesjonalistów. 

Kolejnym krokiem, jaki musimy podjąć, jest uruchomienie naszego ulubionego edytora kodu i instalacja wtyczki. Następnie łączymy swoje konto GitHub z IDE i nasz osobisty asystent jest gotowy do pracy. Od tej pory GitHub Copilot analizuje kod w naszych plikach! 

Dzięki analizie Copilot jest w stanie podpowiedzieć nam kolejne linie, metody oraz algorytmy. W chwili, gdy zaczynamy pisać kod, asystent proponuje autouzupełnienie – możemy je zaakceptować, wciskając klawisz Tab, lub odrzucić. 

Różnica pomiędzy autouzupełnianiem kodu, jaką znamy z popularnych IDE (VSC lub JetBrains), jest taka, że edytory udzielają nam podpowiedzi, bazując na wcześniej zadeklarowanych klasach, zmiennych, metodach oraz zasadach składni. 
 
Copilot idzie nieco dalej. Wykorzystuje AI oraz modele językowe do przewidywania całych bloków kodu. Nie jest ograniczony jedynie składnią – sugeruje gotowe metody, a nawet algorytmy; podpowiedzi są dużo bardziej zaawansowane niż w przypadku tradycyjnego autouzupełniania. 

// Create a function to validate an email address 
function isValidEmail(email: string): bBoolean{...}

Skuteczne okazuje się również generowanie kodu na podstawie komentarzy. Przykładowo, gdy chcemy napisać metodę, możemy po prostu opisać ją jako komentarz, a Copilot zaproponuje gotową implementację: 
  

Kolejnym sposobem na skuteczną komunikację z Copilotem jest też funkcja czatu. Wystarczy, że wciśniemy kombinację klawiszy CTRL + I i pojawi się okienko, w którym możemy zadawać pytania naszemu asystentowi. 

Jakie możliwości funkcji GitHub Copilot oferuje programistom? 

Asystent AI może wspierać nas na różnych etapach rozwoju oprogramowania: 

• Generowanie kodu w czasie rzeczywistym – analizuje nasze poczynania i sugeruje zmiany – od pojedynczych sugestii po całe klasy lub funkcje. 

• Tworzenie całych struktur kodu – gdy poprosimy Copilota o wygenerowanie całego komponentu, np. w React / Angularze, modułu w Nest.js lub zapytań SQL – bez problemu zareaguje wygenerowaniem odpowiednich linii kodu. 

// Create a service to connect to the API 
  

• Tworzenie testów jednostkowych – ogromną zaletą Copilota jest możliwość autotworzenia UT. Jest w stanie wygenerować testy, np. w znanych frameworkach, jak Jest czy Jasmine. Na podstawie analizy implementacji funkcji podpowiada nam odpowiednie przypadki testowe. 

// Create a UT for getUsers function. 
  

• Optymalizowanie oraz refaktoring kodu – któż z nas nie widział mnóstwa powtarzających się metod lub niewydajnych rozwiązań? Copilot bierze ten ciężar na siebie i sugeruje alternatywy – bardziej wydajne i zgodne z najlepszymi zasadami. 

• Generowanie dokumentacji kodu – Copilot może pomóc w generowaniu użytecznych komentarzy w formacie JSDoc lub Markdown, dzięki czemu ułatwimy innym programistom pracę nad naszym kodem – nie tracąc czasu na ręczne pisanie komentarzy. 

/** 
* Gets user data based on user ID 
* @param userId – user ID 
* @returns User object or null 
*/ 
  

Jak GitHub Copilot może pomóc w rozwiązywaniu problemów z kodem? 

Poza standardową pomocą w codziennych czynnościach związanych z kodem Copilot zapewnia także wsparcie w debugowaniu i naprawianiu błędów. Jest w stanie przeanalizować kod pod kątem potencjalnych bugów, np.: 

• Nieodpowiednia składnia – brak nawiasu, średnika czy innego elementu składniowego. 

• Naprawa nieprawidłowych typów – np. próba przypisania nieodpowiedniego typu do zmiennej. 

• Błędne / nieistniejące nazwy zmiennych lub funkcji. 

Jeśli mamy problem z działaniem metody – wystarczy, że zakomunikujemy to naszemu pomocnikowi: 

// The following function is not working properly, fix it 
function getUserData(id: number) { 
  return fetch(`/api/user/${id}`).then((res) => res.json()); 
} 
  

Otrzymamy poprawiony kod: 

async function getUserData(id: number) { 
  try { 
    const response = await fetch(`/api/user/${id}`); 
    if (!response.ok) throw new Error("data download error"); 
    return await response.json(); 
  } catch (error) { 
    console.error(error); 
    return null; 
  } 
} 
  

Jakie są najlepsze praktyki podczas korzystania z GitHub Copilot? 

• Zawsze sprawdzaj wygenerowany kod. Copilot generuje kod, który na pierwszy rzut oka wygląda dobrze, ale może zawierać błędy. 

• Stosuj precyzyjne prompty i opisy funkcji. Im dokładniejszy opis, tym lepsze wyniki. 

• Zwracaj uwagę na bezpieczeństwo. Unikaj generowania kodu zawierającego wrażliwe dane. 

• Wykorzystuj Copilota jako narzędzie edukacyjne. Można go używać do nauki nowych wzorców czy technologii. 

Jakie są opinie użytkowników na temat narzędzia GitHub Copilot? (wady i zalety) 

Według ogólnodostępnych badań:   

• Deweloperzy korzystający z Copilota byli w stanie ukończyć zadania nawet o 55% szybciej niż ci, którzy z niego nie korzystali. 

• 70% deweloperów deklarowało znacznie mniejszy wysiłek umysłowy przy wykonywaniu powtarzalnych zadań. 

Tyle statystyki, a jak to wygląda w praktyce? Copilot rodzi bardzo mieszane uczucia wśród użytkowników. Z jednej strony, usłyszymy głosy, że jest to rewolucja w wytwarzaniu oprogramowania, a narzędzie poprawia produktywność i ułatwia rozwiązywanie problemów. Z drugiej zaś strony są też nie do końca pozytywne opinie, które wskazują na przykład na jakość generowanego kodu oraz zagrożenia dotyczące bezpieczeństwa. 
 
Moje doświadczenie potwierdza te obserwacje. W moim środowisku Copilot cieszy się dużym zainteresowaniem – programiści doceniają przede wszystkim to, że mogą zaoszczędzić czas na pisaniu kodu czy testów jednostkowych. Ale z drugiej strony podchodzą do narzędzia sceptycznie, zwracając uwagę na błędy, które popełnia, lub nieefektywne rozwiązania. 

Przeczytaj także: The best AI for coding – czego używać w 2025 roku?

Zalety tworzenia oprogramowania z GitHub Copilot: 

• Zwiększenie produktywności. 

• Wsparcie dla Junior Developerów i osób uczących się nowych technologii. 

• Obsługa wielu języków programowania. 

Wady tworzenia oprogramowania z GitHub Copilot: 

• Możliwość generowania błędnego kodu. 

• Czasem proponuje przestarzałe rozwiązania. 

• Ograniczona wersja darmowa – pełna funkcjonalność wymaga opłaty. 

Gdzie dowiedzieć się więcej o GitHub Copilot? 

Najlepszym miejscem jest oficjalna dokumentacja. Warto też sprawdzić kursy na YouTube: 

• Traversy Media – przegląd Copilota i jego możliwości. 

• Fireship – szybkie wprowadzenie w kilka minut. 

• The Primeagen – krytyczna analiza Copilota w praktyce. 

Poza darmowymi materiałami warto odwiedzić: 

• Udemy – kursy dla różnych języków. 

• Pluralsight – kursy dla profesjonalistów. 

• Coursera – akademickie podejście do AI w programowaniu. 

Podsumowanie: AI w programowaniu 

Narzędzia bazujące na sztucznej inteligencji stają się coraz lepsze i dzięki temu odciążają programistów już chyba w każdym projekcie IT. Możemy programować szybciej, oszczędzając czas na powtarzalnych zadaniach, takich jak pisanie testów jednostkowych czy przeglądanie dokumentacji. Z drugiej jednak strony – wymagają uważności, czujności i świadomości ograniczeń tej technologii. Wykorzystanie takich narzędzi jak GitHub Copilot wymaga od nas ciągłego poszerzania wiedzy w zakresie możliwości AI, do czego was zachęcam! 

Na chwilę obecną posiadamy wiele narzędzi, modeli AI oraz bardzo dużo integracji z oprogramowaniem, z którego korzystamy na co dzień, więc każdy znajdzie coś dla siebie. Nieważne, czy programujesz, zajmujesz się marketingiem, czy grafiką – AI jest obecne wszędzie… Zapraszam was do dalszej części artykułu, gdzie porozmawiamy o tym, jak AI w codziennej pracy pozwala programistom przyspieszyć wydajność oraz poprawić jakość i czytelność naszego kodu. 

AI for coding: najlepsze narzędzia AI do programowania w 2025 r.

Czy wiesz, że już nawet 76% osób zajmujących się programowaniem korzysta lub planuje używać narzędzi związanych z AI w swojej codziennej pracy? Albo że użytkownicy Copilota wykonywali zadania o około 55% szybciej niż bez AI? Tak wynika z przeprowadzonej przez Stack Overflow w 2024 roku ankiety.  

Na chwilę obecną narzędzia AI są już tak zaawansowane, że nie tylko kod generują, ale również wspierają cały cykl tworzenia oprogramowania. 

Jakie są najlepsze AI do generowania kodu?

Część z was pewnie ma już swoje ulubione narzędzia, z których korzysta na co dzień. Obecnie najbardziej popularne narzędzia, o których pewnie słyszała większość osób w branży, to GitHub Copilot, ChatGPT (OpenAI) i Amazon CodeWhisperer. 

Ta wymieniona trójka to pionierzy wśród asystentów i chatbotów AI, ale na rynku są też inne narzędzia, o których opowiem za chwilę. 

• GitHub Copilot 

Zacznijmy od GitHub Copilota – pioniera wśród asystentów AI, który korzysta z modeli OpenAI. Możemy go zintegrować z popularnym VS Code, dzięki czemu podczas pisania kodu będziemy mieli podpowiedzi bezpośrednio w edytorze. 

• ChatGPT 

Kolejnym ciekawym narzędziem, o którym pewnie słyszała większość z was, jest ChatGPT. Chat ten korzysta z modeli OpenAI, czyli tak samo jak Copilot, ale z tą różnicą, że nie jest on zintegrowany z edytorami. Pomoże ci napisać fragmenty kodu albo rozwiązać jakiś problem związany z kodem. 

• CodeWhisperer 

Z topowej trójki zostaje nam jeszcze CodeWhisperer od Amazon. Jest to swojego rodzaju asystent do programowania z użyciem usług takich jak AWS i nie tylko, więc jeśli zajmujesz się tematyką chmurową, to myślę, że warto go sprawdzić! 

• Tabnine 

Poza tymi, które wymieniłem, są jeszcze inne narzędzia. Zacznijmy od Tabnine. Narzędzie to jest oparte na autouzupełnianiu i, co najważniejsze, może działać jako self-hosted, gwarantując, że nasz kod nigdzie nie wypłynie. 

• Codeium 

Możliwe, że część użytkowników słyszała o darmowej alternatywie dla Copilota, a mianowicie Codeium. Użytkownicy bardzo chwalą narzędzie, że działa całkiem przyzwoicie jako alternatywa, zapewnia automatyczne uzupełnianie i sugestie kodu, które wcale nie ustępują komercyjnym rozwiązaniom. 

• Gemini Code Assist 

Ostatnim z popularnych AI, tym razem od Google, jest Gemini Code Assist. Narzędzie to potrafi zrobić nawet code review, więc jeśli szukasz AI, które wstępnie sprawdzi twój kod, to może warto spróbować? 

Jak widzisz, mamy tutaj całkiem sporo narzędzi i ciężko jest jednoznacznie stwierdzić, które narzędzie będzie dla ciebie odpowiednie, a jeszcze trudniej wskazać, które będzie najlepsze z nich wszystkich. Każdy z nas oczekuje czegoś innego. Jedni będą pracować z technologiami AWS i wybiorą CodeWhisperer, a ktoś inny postawi na privacy-first i wybierze Tabnine. Znajdą się też osoby, dla których wystarczy chatbot, i wybiorą ChatGPT. W mojej ocenie każde z tych narzędzi na pewno pomoże ci w codziennej pracy. 

Które narzędzia AI są darmowe?

Z narzędzi wymienionych do generowania kodu mamy dostępnych kilka opcji, ale zawsze trzeba zwracać uwagę na to, czy będziemy z nich korzystać hobbystycznie, czy realizując projekt komercyjny. 

Większość narzędzi jest darmowa dla użytkowników indywidualnych, a za lepsze wersje lub dodatki trzeba po prostu zapłacić. 

• Google Gemini Code Assist – udostępnia darmowy plan z bardzo wysokimi limitami zapytań i, według mnie, jest to najlepsza alternatywa spośród wszystkich wymienionych. 
• Amazon CodeWhisperer – ma plan darmowy, ale tylko dla użytkowników indywidualnych, więc jeśli tworzysz projekt dla siebie w technologiach np. AWS, warto go sprawdzić. 
• Codeium – dla użytkowników indywidualnych jest całkowicie darmowy, oferuje nielimitowane podpowiedzi kodu i wspiera wiele języków programowania. Według mnie to bardzo ciekawy wybór. 
• ChatGPT – tak jak wspominałem na początku i pewnie nie skłamię, pisząc, że większość osób w branży IT słyszała o tym chatbocie. W wersji bezpłatnej pomoże ci wygenerować np. komponent w React albo zrobić refaktoryzację kodu, jeśli oczywiście wpiszesz odpowiedni prompt. Jednak za wersję premium trzeba już zapłacić. 

Są też inne narzędzia wymienione wcześniej takie jak GitHub Copilot, Tabnine, które są co prawda bezpłatne w podstawowej wersji i będą nam generowały kod, ale jeśli oczekujemy od nich czegoś więcej, to trzeba wykupić pełny plan lub specjalną subskrypcję, więc nie są w pełni darmowe. 

Tak naprawdę, jeśli tworzymy coś hobbistycznie i w mniejszej skali, to większość tych narzędzi będzie dla nas dostępna za darmo (z większymi lub mniejszymi limitami). Wszystko zależy więc od licencji, i od tego, do czego użyjemy danego narzędzia. Pamiętajmy też o tym, że to, co w momencie pisania artykułu jest darmowe, za miesiąc może już nie być, bo licencja się zmieni, więc warto sprawdzić to na własną rękę przed instalacją. 

Jakie są dostępne funkcje AI w edytorach kodu, takich jak VS Code?

Większość narzędzi, które wcześniej wymieniałem, posiada integracje z popularnymi edytorami np. (VS Code) lub IDE. Github Copilot może zostać włączony bezpośrednio w VS Code, dzięki czemu możemy się cieszyć podpowiedziami w kodzie właściwie od razu. 

Copilot Chat pozwala za to zadawać pytania o kod, a Copilot w trybie „agent” wykonuje już złożone polecenia, np. uruchamia unit testy. 

Tak jak widzimy, mamy cały wachlarz możliwości – od chatu w VS Code, poprzez autouzupełnianie kodu,  na uruchamianiu unit testów czy modyfikowaniu całych plików kończąc. Dodatkowo pamiętajmy, że z powyżej wymienionych mamy narzędzia, które nie wysyłają kodu na zewnętrzne serwery, więc nawet przy projektach o wysokich wymaganiach bezpieczeństwa nasze zespoły security będą zadowolone, a dzięki temu będziemy mogli korzystać z AI. 

Jak AI wpływa na jakość kodu

AI to nie tylko generowanie kodu komponentów i rozwiązywanie codziennych problemów w kodzie. Na chwilę obecną AI potrafi przeanalizować istniejący kod w poszukiwaniu błędów lub celem sugerowania innych usprawnień. Powiem więcej, zrobi refaktoryzację i code review! Możemy ustawić takie narzędzie AI jako dodatkowego „recenzenta” naszego kodu, który wykrywa np. podejrzany kod marnej jakości, czyli tzw. „code smells”, a nawet luki w bezpieczeństwie. 

Jak AI może pomóc w code review

Dla przykładu, Gemini Code Review wykona analizę pull requesta i podkreśli fragmenty, na które warto zwrócić uwagę i ewentualnie je poprawić. 

Jeśli korzystasz z GitHuba i jego rozwiązań, to Gemini Code Assist wyłapie nawet niespójności w konwencji kodowania i sprawdzi, czy ich przestrzegasz. 

Tak jak widzisz, temat jest bardzo rozległy, i jeśli dobrze dobierzemy narzędzia AI, to możemy uniknąć wielu roboczogodzin przy sprawdzaniu tego typu rzeczy podczas rozwoju oprogramowania. AI wyłapie te niuanse za nas, a my będziemy mogli skupić się na innej pracy. 

Najlepsze praktyki używania AI do poprawy jakości kodu

1. Sprawdzaj 

Zasada numer jeden, której według mnie należy przestrzegać, to ta, że AI ma ci pomóc w „nakierowaniu” na rozwiązanie twojego problemu. Pamiętaj, aby zweryfikować wszystko, co podpowie ci AI, bo nie zawsze odpowiedzi, które otrzymasz, będą prawidłowe. Jeśli już zastosujesz się do powyższej zasady, to możemy przejść dalej. 

Słyszałem już od wielu osób, że AI bardzo pomaga w pisaniu testów jednostkowych, przynajmniej we frontendzie. Pisanie testów jednostkowych do najprzyjemniejszych nie należy, a w wielu przypadkach trzeba napisać bardzo dużo powtarzającego się kodu typu boilerplate. AI wygeneruje ci unit testy bardzo szybko i zaoszczędzisz przy tym sporo czasu na development, ale pamiętaj – zawsze weryfikuj to, co dostarcza ci AI. 

2. Postaw na iteracyjną refaktoryzację 

Kolejną rzeczą, do której według mnie AI sprawdzi się na co dzień, jest iteracyjna refaktoryzacja i ulepszanie twojego kodu. Wiesz, jak wygląda kod, w którym ktoś dopisał kawałek kodu w pośpiechu, bez większego zastanowienia, aby tylko działało? Czasami taki kod jest zupełnie nieczytelny, albo dochodzi do wielu zagnieżdżeń i tzw. ifologii. W takim przypadku AI poprawi to za ciebie i zasugeruje ci optymalne rozwiązanie. Pozbędziesz się w ten sposób mało czytelnego kodu, a twoje funkcje będą bardziej przejrzyste, kod ładnie sformatowany, a pull request dla osób robiących ci review – przyjemniejszy do czytania. 

3. Bądź elastyczny  

Pamiętaj, że AI nie zwalnia z samodzielnego myślenia, a najlepsze efekty osiągniesz, gdy będziesz weryfikować, ale i stosować pomysły, które według ciebie sprawdzą się w danym projekcie. 

Tutaj trzeba wybrać, co jest odpowiednie w danej chwili.  

Korzyści użycia AI w programowaniu

• Oszczędność czasu 

Ja osobiście dostrzegam tutaj dwie główne korzyści – oszczędność czasu na prostych i powtarzalnych zadaniach oraz zwiększenie produktywności. AI świetnie sprawdza się przy generowaniu powtarzalnego i żmudnego kodu typu boilerplate, więc możemy ten czas poświęcić na coś bardziej kreatywnego. 

• Większa produktywność  

Druga rzecz to produktywność – taki asystent może sprawić, że zajmiemy się trudniejszymi zadaniami, a te proste oddamy AI, więc będziemy też bardziej produktywni. 

• Łatwiejsze wyszukiwanie  

Ważną i niedocenianą rzeczą jest też fakt, że AI dobrze radzi sobie z dokumentacjami. Nie musimy już walczyć z przeszukiwaniem internetu czy dokumentacji, aby znaleźć jakieś informacje – AI zrobi to dużo szybciej. Dzięki temu możemy poświęcić się pracy bardziej kreatywnej, czyli skupić się np. na architekturze aplikacji, a nie na powtarzalnej i nudnej „drobnicy”. 

Potencjalne pułapki z AI w programowaniu

• Halucynacje AI 

Jednym z największych problemów związanych z AI jest to, że doświadczają tzw. halucynacji. To, co czasami wydaje się na pierwszy rzut oka poprawne, po głębszej analizie może (ale nie musi) zawierać błędy logiczne, albo może robić coś zupełnie innego, niż oczekujemy. 

Jeśli porcja kodu, którą dostaliśmy od AI, jest duża, to może zdarzyć się, że będzie to trudne do wykrycia. Jeśli nie masz dobrych unit testów, to możesz nawet nie zdawać sobie sprawy, że AI właśnie dodało ci błąd w kodzie, albo, co gorsza, wprowadzić podatność bezpieczeństwa, z której nawet nie zdajesz sobie sprawy. 

• Brak rozwoju kompetencji programistycznych 

Kolejną pułapką jest spadek umiejętności osób, które korzystają z AI na co dzień. Jeśli będziemy zdawali się wyłącznie na AI i jesteśmy na początkującej drodze, to nasze kompetencje mogą ulec zanikowi albo nie zrobimy takiego progresu, jaki byśmy chcieli. Nie oszukujmy się, ale jeśli ktoś dostaje gotowe rozwiązanie, to jest duża szansa, że nie nauczy się tego na własną rękę i nie będzie potrafił wyjaśnić logiki działania wygenerowanego kodu. Nie mówię tutaj tylko o AI, ale generalnie o tzw. gotowcach. Krótkoterminowo raczej nikt na tym nie ucierpi, ale zastanowiłbym się, czy przy długofalowym korzystaniu z tego narzędzia nasze umiejętności rozwiązywania problemów nie spadną drastycznie. 

Zalecałbym szczególnie juniorom, aby analizowali kod i pisali go samodzielnie, a to, co wygeneruje AI, traktowali bardziej jak odpowiedź na Stack Overflow, czyli bardziej jako sugestię i materiał do dalszego researchu. 

• Kwestie prawne 

Na koniec pamiętajmy też o kwestiach prawnych. Nie od dzisiaj wiadomo, że chatboty i inne generatory kodu uczą się na „cudzym” kodzie, który jest np. publicznie dostępny. Zawsze sprawdzajmy i czytajmy polityki prywatności i licencje, aby wiedzieć, co udostępniamy AI, ale jednocześnie też uważajmy na to, co samo AI nam dostarcza, aby nie otrzymać kodu łudząco podobnego do jakiegoś fragmentu z np. open source. Pamiętajmy też o aspektach security i polityce firmy, bo chyba nie chcemy, aby nasze poufne hasła czy klucze API krążyły w sieci, bo były przez nas używane w promptach, a co za tym idzie, mogły zostać użyte do trenowania modeli, prawda? 

Różnice między różnymi asystentami AI

Ilość narzędzi AI oraz różnego rodzaju asystentów potrafi przytłoczyć, a podejrzewam, że to dopiero początek. Spróbujemy zaraz porównać kilka modeli AI oraz narzędzi, które posłużą nam do programowania i codziennej pracy z kodem. 

Porównanie różnych modeli AI do programowania

Obecnie na rynku mamy sporo popularnych modeli AI oraz asystentów programowania, ale generalnie ich cel jest zbliżony – mają ułatwić i przyspieszyć pisanie kodu. Jeśli chodzi o główne różnice, to za wszystkim stoją różne modele językowe i firmy, które nad nimi pracują. 

Przykładowo, GitHub Copilot korzysta z OpenAI, CodeWhisperer od Amazon jest trenowany na kodzie źródłowym open-source, a inne narzędzia korzystają z własnych modeli, które możemy uruchomić lokalnie (Tabnine), więc mamy tutaj alternatywę dla usług chmurowych. 

I teraz pewnie część z was się domyśli, że OpenAI będzie nam płynnie odpowiadał w wielu językach, a CodeWhisperer będzie z kolei lepszy w kontekście AWS, bo na takich danych był trenowany. Tak właśnie jest z tymi narzędziami – takie są subtelne różnice między nimi. 

Różnice, które dostrzegamy gołym okiem, będą dla nas widoczne w integracjach i ekosystemie. Mamy z jednej strony chatboty bez możliwości wejścia w kontekst projektu (chociaż są pluginy pod ChatGPT, które integrują go z edytorem), a z drugiej strony mamy Tabnine, CodeWhisperer i Gemini jako wtyczki bezpośrednio pod IDE, które dają podpowiedzi na żywo w kodzie. 

Warto też zwrócić uwagę na licencję i koszty, i tutaj, jak się pewnie domyślacie, mamy dużą rozpiętość – od darmowych po bardzo drogie. Jeśli chodzi o mnie, to chyba poleciłbym któreś z tych darmowych i najbardziej dostępnych AI – Gemini lub Codeium. Dają praktycznie nieograniczone możliwości korzystania z AI bez opłat, co może być decydującym czynnikiem w niektórych przypadkach.  

Z drugiej strony firma może chcieć wykorzystać narzędzie, które będzie zgodne z politykami wewnętrznymi i wtedy trzeba będzie zapłacić więcej (np. Tabnine on-premise ze względów bezpieczeństwa). 

Jak widzicie, mamy tutaj spore różnice, jeśli chodzi o modele, narzędzia, pluginy oraz modele subskrypcji i licencji. Generalnie, jeśli chodzi o samą funkcjonalność, to jest ona bardzo podobna – dostajemy wygenerowany kod na podstawie prompta, ale czasami mamy możliwość skorzystania z dodatkowych funkcjonalności, takich jak np. agent mode w Copilot. 

W trybie agent mode AI nie tylko podpowiada nam kod, który chcemy dodać, ale też może modyfikować całe pliki projektu i wykonywać dodatkowe czynności, np. uruchamiać komendę do unit testów. Ciekawe, prawda? 

Co wyróżnia Gemini Code Assist spośród innych narzędzi?

Wyobraź sobie, że masz pod ręką wirtualnego asystenta, który robi również np. code review. Właśnie tak w skrócie działa Gemini Code Assist. Jeśli tworzysz projekt hobbistyczny, jest on dostępny od Google całkowicie za darmo, a do tego oferuje bardzo wysokie limity miesięczne, których raczej w standardowej sytuacji nie będziesz w stanie wykorzystać. 

Google zadbało również o to, aby dostroić asystenta do zadań stricte programistycznych, ponieważ był trenowany na rzeczywistych przypadkach kodowania. Wyróżniającą cechą jest także fakt, że Gemini potrafi czytać bardzo duży kontekst naraz. Oznacza to, że można mu przekazać cały kod źródłowy do analizy, co stanowi bardzo duży krok naprzód w porównaniu do innych narzędzi. 

Jeśli szukasz wsparcia w pisaniu kodu w edytorze za pomocą AI, chcesz, aby asystent zrobił code review i podał sugestie, co poprawić (nawet pod względem code guide w obecnym projekcie), warto zainteresować się Gemini. 

Najnowsze trendy w obszarze AI for coding w 2025 roku

Na chwilę obecną widać gwałtowne przyspieszenie rozwoju narzędzi typu AI for coding. Duże firmy technologiczne, takie jak Microsoft, Amazon czy Google, prześcigają się we wprowadzaniu AI do swoich produktów.   

Ostatnio widziałem, że AI nie tylko generuje kod, ale potrafi stworzyć taska w Jira nawet na podstawie treści nieczytelnej dla człowieka (np. z logów błędu na AWS). Mało tego – rozpisuje odpowiednie subtaski w bardzo ciekawy sposób, więc nie tracimy już cennego czasu na takie prace. Wystarczy, że wkleimy kawałek kodu i zweryfikujemy to, co nam podpowiada AI. Wydaje mi się, że AI będzie coraz bardziej wspierać tworzenie dokumentacji, testów, konfiguracji np. CI/CD czy analizę wymagań w oparciu o przyjętą architekturę projektu. 

Najlepsze praktyki korzystania z AI w programowaniu

AI, tak jak każde inne narzędzie, potrafi pomóc, ale też trzeba uważać na pewne pułapki. Przedstawię kilka propozycji w kolejności od tych najważniejszych według mnie, które są warte przeczytania i zastosowania, kiedy będziesz korzystać z AI na co dzień w swojej pracy z kodem. 

1. Zasada numer jeden – dbaj o prywatność swojego kodu i zasady panujące w danym projekcie (lub, jeśli pracujesz dla kogoś – w danej firmie lub organizacji). Warto upewnić się, czy korzystanie z AI w tym przypadku jest zgodne z umową lub polityką firmy/organizacji. Sprawdź też dodatkowo, czy można wyłączyć trenowanie modeli na twoim kodzie i nigdy nie wrzucaj danych, które są tajemnicą przedsiębiorstwa, do prompta. Jeśli już musisz, to zanonimizuj kod tak, aby nie zawierał danych wrażliwych, unikalnych projektowo nazw funkcji czy zmiennych, a kodu nigdy nie dało się powiązać z danym klientem/projektem/firmą czy czymkolwiek. Mam nadzieję, że wiesz, o co mi chodzi. 
2. AI ma ci pomagać, a nie wyręczać cię w codziennej pracy. Ma być bardziej pomocnikiem przy generowaniu powtarzalnego kodu, np. unit testów, lub nakierować cię na jakieś rozwiązanie. Sprawdź zawsze kod, który dostarcza ci AI. Przeanalizuj i zrozum, w jaki sposób AI dodało np. funkcję w kodzie. Taka refleksja nad kodem będzie ćwiczyła twój umysł, a dzięki temu umiejętności pozostaną na wysokim poziomie. 
3. Przy pisaniu testów jednostkowych stosujemy zasadę nr 2, ale dodatkowo uruchamiamy testy. Zobaczmy, czy rzeczywiście sprawdzają to, co trzeba, sprawdźmy, czy testowane są np. przypadki brzegowe. Zmuś się do analizowania tego kodu, tak jak by to był zwykły pull request na repozytorium do sprawdzenia. Błędy się zdarzają, więc zawsze sprawdzaj dwa razy.  
4. Warto wykorzystać technologię AI do robienia rzeczy, które wychodzą jej lepiej od innych, a te bardziej złożone – lepiej robić na własną rękę. Jeśli masz do wyboru wygenerowanie np. unit testów, zrobienie konwersji jednego formatu na drugi lub optymalizację już istniejącej funkcji, to AI sprawdzi się tutaj dużo lepiej, niż miałaby stworzyć to od podstaw. Skomplikowaną architekturę oraz funkcje zostaw sobie na start, a jeśli poziom skomplikowania się zwiększy lub potrzebujesz refaktoryzacji – wtedy udaj się z pytaniem do AI po sugestie. Nie zaniedbuj szkolenia się w danej dziedzinie. Wiem, że AI potrafi nas odciążyć i trochę zwolnić z myślenia, ale to nie powód, aby nie doszkalać się z danej dziedziny. Unikaj szczególnie “metody Copy’ego Paste’a”, czyli kopiowania i wklejania treści kodu bez przeczytania i zrozumienia, co się tam dzieje. 

Podsumowanie 

Tak naprawdę, jeśli zastosujemy te zasady w naszej codziennej pracy, to będzie się nam pracowało dużo lepiej, a jednocześnie zapewnimy większe bezpieczeństwo naszego kodu. Nasze umiejętności pozostaną na wysokim poziomie, a efektywność będzie rosła dzięki wsparciu AI. 

Temat, który dzisiaj omówiliśmy, jest bardzo rozległy i dynamiczny, ale mam nadzieję, że zaciekawiłem was nim i odpowiedziałem na parę nurtujących pytań. Na koniec powiem jeszcze chyba najważniejszą rzecz odnośnie AI. Ostatecznie to my dostarczamy kod i się pod nim podpisujemy, nie AI. Trzeba o tym pamiętać i zachować po prostu zdrowy rozsądek – tak jak we wszystkim. 

Zrozumienie poruszonych aspektów pozwala odpowiedzieć na istotne pytania. Jakie struktury wykorzystywać, by uniknąć krytycznych błędów? Jak zwiększyć efektywność pracy w Pythonie i zadbać o czysty kod? Jak asystenci AI wspierają codzienną pracę programistów?

Trochę historii na początek – przykłady problemów z liczbami zmiennoprzecinkowymi

Błąd systemu obrony przeciwrakietowej Patriot 

Podczas wojny w Zatoce Perskiej w 1991 roku system nie zadziałał prawidłowo i nie przechwycił rakiety Scud, która uderzyła w koszary wojskowe w Dhahran w Arabii Saudyjskiej, zabijając 28 osób. Przyczyną był błąd w obliczeniach czasu. System śledził czas za pomocą liczby całkowitej reprezentującej liczbę taktów zegara, przy czym każdy takt odpowiadał za około 0.1 sekundy. Aby obliczyć dokładny czas, liczba całkowita była mnożona przez 0.1, która w pamięci była reprezentowana jako liczba przybliżona ze względu na ograniczenia formatu IEEE 754. Z każdym kolejnym cyklem zegara błąd się kumulował, przez aż 100 godzin od uruchomienia systemu, ostatecznie narastając do około 0.34 sekundy. Ta różnica spowodowała, że system obliczył błędne położenie rakiety Scud i nie zadziałał na czas. Po incydencie wprowadzono aktualizację oprogramowania, która resetowała zegar systemowy częściej, zmniejszając wpływ kumulacji błędów. Ta tragiczna w skutkach historia amerykańskiego systemu obrony rakietowej Patriot to jeden z klasycznych przykładów błędu wynikającego z ograniczeń liczb zmiennoprzecinkowych. Ta historia pokazuje, że w tak istotnych obliczeniach należy unikać stosowania przybliżeń i używać precyzyjniejszych typów danych.  

Wybory parlamentarne w Schleswig-Holstein 

Innym przykładem są wybory parlamentarne z 1992 r. w niemieckim Schleswig-Holstein. W tym, jak i w większości niemieckich landów, obowiązuje system proporcjonalny, w którym partie muszą uzyskać co najmniej 5% głosów, aby otrzymać mandaty w parlamencie. Wyniki wyborów były prezentowane w procentach, a zaokrąglenia miały miejsce na różnych etapach obliczeń. Partia Zielonych uzyskała 4.97%, ale na etapie prezentacji wyników wartość została zaokrąglona do 5%, a więc próg został spełniony, co całkowicie zmieniło rozkład mandatów w parlamencie. Doprowadziło to do wielu kontrowersji i publicznej debaty, jednak mimo to wyniki zostały uznane za wiążące. W systemie nie przewidziano procedury na wypadek błędu zaokrąglenia.  

Float – liczby zmiennoprzecinkowe w Pythonie

W tym kontekście bardzo ciekawą prelekcją z mojej perspektywy była ta o typie Float, czyli liczbach zmiennoprzecinkowych w Pythonie.  

Liczby te można tworzyć na różne sposoby, poprzez dosłowne przekazanie liczby, czyli np. 1.0, używając klasy tj. float(1) lub poprzez działania matematyczne takie jak 1/1. 

Standard IEEE 754 binary64 

Z dokumentacji Pythona dowiadujemy się, że we wszystkich znanych implementacjach interpretera Pythona float zdefiniowany jest jako double. Bardziej szczegółowo typ ten jest opisany według standardu IEEE 754 binary64 i wygląda to następująco: 

Patrząc po kolei od lewej: 

• 1 bit jest poświęcony na znak (liczba dodatnia lub ujemna). 
• 11 bitów wyraża wykładnik potęgowy. 
• 52 bity wyrażają ułamek. 

A wszystko to można przedstawić za pomocą poniższego wzoru: 

(-1)^sign x 2^(exp-1023) x 1.fraction 

Według omówionego standardu poniżej kilka przykładów reprezentacji binarnej: 

a) Liczba 0.0 

0 (sign) 00000000000 (exponent)

(0).0000000000000000000000000000000000000000000000000000 (fraction) 

b) Liczba 1.0 = 1 x 1.0 = 2^0 x 1.0 = 2^(1024-1024) x 1.0 

0 (sign) 01111111111 (exponent)

(1).0000000000000000000000000000000000000000000000000000 (fraction) 

c) Liczba 3.0 = 2 x 1.5 = 2^1 x 1.5 =2^(1025-1024) x 1.5 

0 (sign) 10000000000 (exponent)

(1).1000000000000000000000000000000000000000000000000000 (fraction) 

Precyzja typu Float 

Powyższe przykłady są dość proste z punktu widzenia reprezentacji binarnej, jednak problem pojawia się przy liczbach niecałkowitych, ponieważ nie zawsze jesteśmy w stanie zapisać je w pamięci z pełną precyzją. Można to zaobserwować, używając w Pythonie metody as_integer_ratio(), aby sprawdzić, jakie liczby są użyte do dzielenia, by uzyskać oczekiwany wynik. Jak widać na poniższym przykładzie, dla liczby 0.1 nie ma liczb 1 i 10, jak byśmy tego oczekiwali, tylko 3602879701896397 i 36028797018963968. Są to liczby, które dają najbardziej precyzyjne przybliżenie do 0.1 i możliwe do zapisu w pamięci według omawianego standardu. Natomiast to, że wywołując print() na obliczeniu 1/10 otrzymujemy 0.1, wynika wyłącznie z tego, że print() automatycznie zaokrągla nam do najkrótszego zapisu dziesiętnego, który się mieści w ramach ostatniego bitu precyzji.  

Inną przydatną metodą w Pythonie, pozwalającą zyskać więcej informacji na temat floatów, jest sys.float_info. Dzięki niej możemy się dowiedzieć, że float pozwala na przechowywanie do 15 cyfr znaczących (dodatkowo ewentualnie znak plus-minus i/lub przecinek).  

To wszystko może sprawić, że zaczniemy się zastanawiać nad tym, jak dużo ucieka nam precyzji podczas używania typu float. Do tego przydatna jest metoda math.ulp() (czyli Unit in the Last Place), co w praktyce zwraca nam różnicę pomiędzy podaną liczbą a następną, którą jesteśmy w stanie zapisać w tym formacie w pamięci. W przypadku małych liczb te różnice są bardzo marginalne, jednak przy takiej liczbie jak 2^52 ta różnica wynosi już równo 1.0. Oznacza to, że właściwie od tej liczby wzwyż całkowicie tracimy części ułamkowe. Idąc dalej, przy 2^53 różnica ta wynosi już 2.0. Zatem ważnym wnioskiem jest, by tak dużych liczb, nawet całkowitych, nie przechowywać jako float, ponieważ tylko liczby parzyste w tym przypadku zachowałyby swoją precyzję. 

Symbole specjalne 

W standardzie IEEE 754 przewidziano również miejsce dla specjalnych symboli. Jeśli 11-bitowa część exponent jest cała wypełniona jedynkami, a 52-bitowa część wyrażająca ułamek wypełniona zerami, to mamy do czynienia z reprezentacją binarną nieskończoności. Zapełniając zerem bit odpowiedzialny za znak otrzymujemy plus nieskończoność, a jedynką minus nieskończoność. 

Z kolei mając również 11-bitową część exponent wypełnioną jedynkami, ale także część wyrażającą ułamek wypełnioną jedynkami, otrzymujemy symbol NaN (Not a Number). Wszelkie operacje porównujące takie jak =, >, < z udziałem NaN zwracają False, co może być problematyczne w różnych okolicznościach. Zwłaszcza kiedy użytkownik ma braki w danych i sądzi, że porównywana jest faktyczna liczba, a nie pusta reprezentacja w postaci NaN.  

Zaokrąglenia 

Co jednak, jeśli nie jest potrzebna nam aż taka dokładność i chcemy uprościć jakieś obliczenia? Odpowiedzią są zaokrąglenia i należy wiedzieć, że uzyskać je można na różne sposoby. Co istotne, nie różnią się jedynie nazwy funkcji, ale ich implementacje mają odrębne podejścia. W prezentacji podczas Python Summit 2024 przedstawiono następujące metody: 

1. Funkcja round() – zaokrągla zadaną liczbę do najbliższej liczby z określoną liczbą miejsc po przecinku, domyślnie do liczby całkowitej. Natomiast szczególnym przypadkiem jest sytuacja, gdy liczba jest równo w połowie i w obie strony jest taka sama odległość. Wtedy najmniej znacząca cyfra zaokrąglana jest do liczby parzystej, co według statystyków minimalizuje skumulowany błąd podczas wykonywania wielu operacji zaokrąglania. Czyli przykładowo zarówno 1.5, jak i 2.5 zostaną zaokrąglone do 2, jeśli interesuje nas liczba całkowita. Co ciekawe, w przypadku takich liczb jak 1.15 i 1.25 również obie powinny zostać zaokrąglone do 1.2, gdyby chcieć zachować dokładność do jednego miejsca po przecinku. Jednak tylko 1.25 zwróci poprawnie 1.2, a dla 1.15 zostanie zwrócone 1.1. Wynika to właśnie z tego, że liczby 1.15 nie da się precyzyjnie przechować w pamięci według standardu IEEE 754, a będzie to 1.1499999999999999. Czyli nie jest to de facto równo w połowie, a więc zaokrągli w dół do 1.1. 

2. int() lub math.trunc() – co prawda nie są to funkcje zaokrąglające, tylko obcinające liczbę, ale ich efekt działa tak, jakbyśmy zaokrąglali liczbę w kierunku 0. Czyli przykładowo 1.9 zostanie ucięte (zaokrąglone) do 1, natomiast -1.9 zostanie sprowadzone do -1.  

3. math.floor() lub x // 1 – pierwsza z nich po prostu zaokrągla w dół, w kierunku –nieskończoności. Natomiast druga to dzielenie bez reszty, przy czym dzieląc przez jeden, uzyskamy ten sam efekt co w przypadku pierwszej funkcji. Przykładowo dla obu z nich -1.9 zostanie zaokrąglone do -2, a 1.9 do 1. 

4. math.ceil() – zaokrąglanie w górę, w kierunku + nieskończoności. Używając tego samego przykładu -1.9 zostanie zaokrąglone do -1, natomiast 1.9 zaokrągli do 2. 

Developer Experience – jak mierzyć efektywność developera?

W przeszłości na różne sposoby próbowano mierzyć efektywność developerów. Jedną z bardziej popularnych, a zarazem nietrafionych metod, było mierzenie efektywności poprzez liczbę napisanych linii kodu. Podczas drugiej z wspomnianych prezentacji przytoczono koncepcję, która nie tyle pozwala na mierzenie produktywności, co pomaga zadbać o efektywne środowisko pracy. Mowa tutaj o DevEX (Developer Experience), które wyróżnia 3 filary: 

1. Stan przepływu (Flow state) – z punktu widzenia developera jest to stan głębokiego skupienia, w którym jesteśmy w stanie spokojnie pracować. Jeśli cele nie są jasno doprecyzowane, może wystąpić konieczność przerwania zadania, by ustalić nieścisłości. 
2. Pętle zwrotne (Feedback loops) – oznacza, ile czasu mija, zanim developer się dowie, że kod nie działa. W przypadku testów jednostkowych ten feedback jest bardzo szybki, ale w przypadku code review na feedback trzeba zaczekać dłużej. 
3. Ładunek kognitywny (Cognitive load) – oznacza wysiłek umysłowy wymagany do skutecznego pisania kodu. Jeśli programista spotyka się z projektem o innej strukturze niż zwykle albo nie ma do dyspozycji dokumentacji, do której zawsze miał dostęp, ten ładunek będzie wyższy. 

Narzędzia do efektywnej pracy w Pythonie

Wielu programistów rozpoczyna przygodę z Pythonem, gdyż zachęca ich intuicyjna składnia i wszechstronność zastosowań tego języka w analizie danych. W miarę rozwoju umiejętności w naturalny sposób poszukujemy narzędzi pozwalających zwiększyć efektywność pracy i ułatwiających życie. Podczas kolejnej prezentacji, w której miałem okazję brać udział w trakcie Python Summit 2024, zostały omówione takie narzędzia: 

1. Formatery  

Formatowanie kodu to bardzo istotny aspekt, ponieważ to od tego głównie będzie zależało, czy programiście wygodnie się czyta oraz pisze kod. Jednak każdy z nas może mieć nieco inne preferencje, przyzwyczajenia, dlatego najlepiej, aby został przyjęty jeden ściśle określony sposób formatowania. Zaleca się korzystanie ze standardu PEP 8. Jest to dość długi dokument, dlatego dbanie samodzielnie o każdy szczegół mogłoby być bardzo czasochłonne – ładunek kognitywny rośnie. Dodatkowo podczas code review to byłaby rzecz, na którą trzeba zwracać uwagę, zatem przekłada się to na dodatkowy czas poświęcony po stronie zespołu, a i pętla zwrotna się wydłuża. I tutaj z pomocą przychodzą formatery kodu, które mogą wykonać całą pracę za nas. Przykładowe formatery kodu w Pythonie to: black, isort, ruff, yapf. 

2. Lintery 

Są to narzędzia do statycznej analizy kodu, dzięki którym możemy dowiedzieć się o niektórych błędach jeszcze przed uruchomieniem kodu. Ponadto lintery są w stanie naprawiać za nas takie błędy jak np. literówki powstałe poprzez użycie nieistniejącej zmiennej. Inne kwestie, które mogą być sprawdzane automatycznie, to ilość znaków w każdej linii, długość nazw funkcji, zmiennych, ilość argumentów do funkcji itp. Przykłady linterów w Pythonie to: pylint, flake8, ruff. 
 

3. Adnotacje typów i type checkery 

W kwestii typów zmiennych Python jest bardzo liberalny, ponieważ mamy tu do czynienia z typowaniem dynamicznym. Mimo to określanie typów, jakie przewidujemy dla danych zmiennych, jest postrzegane jako dobra praktyka w Pythonie. Jest to funkcja, która została wprowadzona od wersji Pythona 3.5. Należy mieć na uwadze, że adnotacje typów są jedynie komentarzem i nie są uwzględniane przez program, o ile nie ma zewnętrznej biblioteki, która by je interpretowała. Używając jednak PyCharma, jednego z najpopularniejszych IDE dla Pythona, możemy odnieść korzyści z adnotacji typów natychmiastowo. PyCharm posiada wbudowany type checker, dzięki czemu będziemy widzieć różne podpowiedzi dotyczące typów. Inne popularne zewnętrzne type checkery to: mypy, pyright czy też pyre. 

Rekomendacja dotycząca omówionych narzędzi bardzo przypadła mi do gustu. Według prelegentów Python Summit 2024 dobrym wyborem będzie ruff, ponieważ świetnie sprawdza się zarówno jako formater, jak i linter. Zastępuje inne narzędzia oraz jest bardzo szybki. Dodatkowym argumentem, by się bliżej przyjrzeć tej bibliotece, jest to, że w planach jest rozszerzenie jej funkcjonalności również o type checker. Jednak na ten moment należy korzystać ze sprawdzonych i popularnych narzędzi do sprawdzania typów, takich jak mypy oraz pyright.  

Asystenci AI jako wsparcie produktywnej pracy

Na koniec temat, bez którego trudno obecnie wyobrazić sobie przyszłość programowania – mianowicie narzędzia sztucznej inteligencji. Poza wspomnianymi tradycyjnymi narzędziami do usprawniania pracy w Pythonie podczas konferencji w prezentacjach osobną część poświęcono nowoczesnym podejściom do tworzenia oprogramowania wykorzystującym asystentów AI.  

O ile obecnie raczej nie ma co liczyć na to, że napiszą za nas cały program, o tyle mogą świetnie się sprawdzić jako usprawnienie pracy. Zainstalowanie takiej wtyczki jak chociażby Copilot może przyspieszyć proste operacje czy też tworzenie komentarzy dzięki trafnym podpowiedziom.  

Jeśli nie pamiętamy składni, argumentów biblioteki etc., sprawdzanie dokumentacji może okazać się już zbędne. Asystenci AI mogą również przyspieszyć pisanie prostych testów jednostkowych. Warto jednak najpierw napisać kilka z nich samodzielnie, by asystent mógł lepiej rozpoznać poprawny wzór. 

Poniżej kilka przykładów najbardziej popularnych narzędzi programistycznych.   

• GitHub Copilot – narzędzie analizuje kontekst kodu i pozwala zautomatyzować, a tym samym przyspieszyć uzupełnianie fragmentów kodu. Przydatny w tworzeniu i przeglądzie dokumentacji oraz wyszukiwaniu konkretnych rozwiązań. 
• Supermaven – sugeruje zależności i poprawki w kodzie, eliminując błędy i optymalizując wydajność aplikacji. Narzędzie może zasugerować użycie najlepszej biblioteki pod kątem danego projektu, co skraca czas analizy i przyspiesza proces wdrażania nowych rozwiązań. 
• Cursor AI – usprawnia pracę programistów Python dzięki inteligentnemu autouzupełnianiu, generowaniu kodu na podstawie języka naturalnego oraz możliwości szybkiego refactoringu. 
• Tabnine – pozwala uzupełniać kod w czasie rzeczywistym, co zwiększa produktywność i pomaga unikać błędów składniowych, a także eliminuje powtarzalność zadań związanych z pisaniem kodu. 
• Sourcegraph Cody – sprawdza się świetnie w zaawansowanym przeszukiwaniu kodu. Pozwala na zrozumienie zależności w projektach oraz – dzięki kontekstowej analizie całej bazy kodu – na szybkie odnajdywanie i poprawianie błędów. 

AI w programowaniu | bezpłatny e-book

Zautomatyzuj kodowanie z AI! Pobierz darmowy e-book i odkryj nowe możliwości

Pobierz teraz!

Podsumowanie

Mnogość dostępnych technologii w świecie IT potrafi przyprawić o zawrót głowy. Samo określenie roli w projekcie IT jeszcze nie determinuje wyboru narzędzi, z których będziemy korzystać. Decydować o tym będą w głównej mierze wymagania systemu. Czy powinien być nastawiony na wydajne przetwarzanie dużych ilości danych, czy może bardziej istotna jest prostota w implementacji i szybkie wdrożenie rozwiązania kosztem niższej wydajności? Odpowiedzenie sobie na te pytania czasem nie wystarczy, ponieważ bywa, że kilka technologii spełnia wszystkie wymagania i wybór sprowadza się do względów czysto estetycznych i preferencji osobistych.  

Na szczęście są społeczności i organizacje, które skupiają ludzi zainteresowanych określoną tematyką i pomagają odnaleźć się w gąszczu wiedzy oraz poszerzać horyzonty, by być na bieżąco. Dla osób związanych zawodowo z językiem programowania Python takim miejscem jest właśnie konferencja Python Summit. Prelekcje dostępne w trakcie Python Summit 2024 i zagadnienia, które omówiłem, stanowią tylko mały wycinek wiedzy, jaki można było wynieść z tego spotkania. Zapewniam, że każdy znalazłby coś dla siebie, nawet jeśli wybrane przeze mnie tematy nie są w centrum zainteresowania danego programisty. 

Przeczytaj także nasze artykuły dotyczące bibliotek Python:  

• NumPy 
• Matplotlib 
• Pandas 

Automatyzacja i testowanie

Zmiany nie będą dotyczyły tylko kodu samej aplikacji, ale też testów (tworzenie testów jednostkowych nowej funkcjonalności). Jednym z kluczowych atrybutów ciągłej integracji jest wysoki stopień wykorzystania zautomatyzowanych testów. Po zakończeniu wprowadzania zmian na lokalnym komputerze wykonywany jest zautomatyzowany proces kompilacji (build). W procesie tym pobierany jest kod źródłowy z lokalnego repozytorium, który jest następnie kompilowany, łączony z plikiem wykonywalnym, a na końcu przeprowadzane są testy automatyczne. Build uznaje się za prawidłowy, gdy kompilacja oraz testy zakończą się poprawnie, bez błędów.  

Integracja i aktualizacja

Następnym krokiem jest zatwierdzenie zmian w repozytorium. Na tym etapie należy uwzględnić zmiany wprowadzone przez innych członków w zespole, ponieważ w międzyczasie zmiany innego programisty mogły zostać już zintegrowane z głównym repozytorium tworzonego oprogramowania. Należy więc najpierw zaktualizować lokalną gałąź z kodem z głównej gałęzi (master) i ponownie uruchomić zautomatyzowaną kompilację (build). Jeżeli w trakcie tego procesu pojawią się konflikty (zmiany w kodzie kolidujące ze zmianami wprowadzonymi przez innych programistów), należy je rozwiązać i ponownie uruchomić kompilację. Gdy zakończy się ona powodzeniem, zmiany można zatwierdzić i zintegrować z głównym repozytorium. 

W tym momencie wykonywana jest ponowna kompilacja, lecz tym razem jest ona przeprowadzana na serwerze integracyjnym. Zdarza się, że podczas kompilacji na lokalnej stacji roboczej coś może zostać przeoczone, przez co główne repozytorium zostanie zaktualizowane w nieodpowiedni sposób. Dopiero gdy zmiany w głównym repozytorium zbudują się poprawnie na serwerze CI, można je będzie uznać za zakończone sukcesem. 

Jeśli dojdzie do konfliktów w plikach zmienionych przez innych programistów, zwykle będą one wychwycone, gdy programista zatwierdzający zmiany utworzy zaktualizowaną kopię roboczą, a sama kompilacja zakończy się niepowodzeniem. Błąd jest szybko wyłapany, a zadaniem programistów jest zlokalizowanie źródła błędów i naprawienie ich. W środowisku CI należy unikać sytuacji, w których przez dłuższy czas kompilacje integracyjne kończą się błędem – trzeba je naprawić najszybciej, jak to możliwe. 

Po pomyślnej kompilacji na serwerze ciągłej integracji nowe zmiany można wprowadzić na przykład na środowiska testowe, gdzie testerzy będą mogli przeprowadzać testy na aktualnej wersji oprogramowania zawierającej najnowsze zmiany. 

Zarządzanie błędami i powiadomienia

Na każdym etapie procesu ciągłej integracji po stronie serwera, w razie niepowodzenia w budowaniu projektu, można zaimplementować narzędzia raportujące błędy. W ten sposób, w przypadku wystąpienia błędu w którymś kroku kompilacji – odpowiedni użytkownicy mogą zostać powiadomieni, na przykład za pomocą wiadomości e-mail lub powiadomienia na firmowym czacie. 

Przykładowy ogólny schemat procesu ciągłej integracji: 

Praktyka DevOps

Termin DevOps pochodzi z połączenia dwóch słów: development i operations (programowanie i operacje). Służy do określenia podejścia do rozwoju oprogramowania zakładającego zmniejszanie barier pomiędzy zespołami deweloperskimi i operacyjnymi firmy. Celem DevOps jest skrócenie czasu wprowadzenia produktu na rynek. Oznacza to przyjęcie i wdrożenie pewnych praktyk w celu skrócenia czasu od identyfikacji nowego wymagania do momentu jego wdrożenia dla klientów. W podejściu tym wykorzystywana jest omawiana ciągła integracja i ciągłe dostarczanie, które pomagają skrócić czas wprowadzenia produktu na rynek i stworzyć oprogramowanie lepszej jakości. 

Historia i rozwój

Celem DevOps jest skrócenie czasu wprowadzenia produktu na rynek. Filozofia DevOps narodziła się w 2008 roku podczas konferencji Agile w Toronto, kiedy  Patrick Debois wygłosił wykład pod tytułem „Infrastructure and Operations“. Wyjaśnił w nim zastosowanie podejścia Agile do budowy infrastruktury, a na koniec zaproponował lepszą metodę komunikacji oraz pomysły, dzięki którym programiści mogliby „ poszerzać swoje horyzonty”, w sensie pogłębiania wiedzy systemowej niezbędnej do zapewnienia płynniejszego procesu wydawania oprogramowania. Mijały lata, a podejście DevOps stawało się coraz bardziej popularne, a w ślad za nim pojawiła się nowa rola w świecie IT – inżynier DevOps.  

Rola inżyniera DevOps

Inżynier DevOps stanowi swego rodzaju pomost pomiędzy programistami a działem operacyjnym. W większości przypadków rola, jaką przyjmuje, jest ich mieszanką (inżynierowie ci muszą posiadać wiedzę niezbędną do doradzania i zarządzania problemem z obu dyscyplin). W niektórych przypadkach odpowiedzialność inżyniera DevOps związana jest z ciągłą integracją i dostarczaniem. Inne obowiązki obejmują zarządzanie infrastrukturą, zazwyczaj w postaci kodu (IaC) oraz pomoc we wdrażaniu optymalnych praktyk DevOps w całej firmie. Czasem inżyniera DevOps postrzega się go także jako osobę odpowiedzialną głównie za utrzymanie oprogramowania w środowisku produkcyjnym i automatyzację procesów, rozwiązywanie problemów, administrowanie systemem.  Rola inżyniera DevOps jest zróżnicowana i może zmieniać się w zależności od firmy. 

Zalety podejścia DevOps

Efektywność i współpraca 

Zespoły, które wdrażają podejście DevOps, stają się bardziej wydajne, dzięki czemu tworzone oprogramowanie wydawane jest nie tylko szybciej, ale też jest bardziej stabilne. Lepsza współpraca i zwiększona produktywność pozwalają też osiągać cele biznesowe, takie jak szybsze wprowadzenie produktu na rynek czy utrzymanie jego niezawodności i stabilności w każdych warunkach. Zastosowanie metodyki DevOps nie tylko pozwala zautomatyzować i optymalizować procesy za pomocą technologii. Jest to przede wszystkim zmiana kultury wewnątrz organizacji i ludzi zaangażowanych w ten proces.  

Wdrożenie kultury DevOps wymaga głębokich zmian w dotychczasowym sposobie pracy zespołów i przestrzegania określonych zasad, jednak te zmiany pozwalają stworzyć środowisko pracy o wysokiej wydajności.   Cechą charakterystyczną DevOps jest ścisła współpraca między zespołami. Różne zespoły, na przykład zespoły deweloperów i odpowiedzialne za operacje, muszą dzielić się swoimi procesami, priorytetami i problemami. Muszą także wspólnie planować pracę oraz cele i środki związane z ich osiągnięciem. W miarę jak zespoły dostosowują się do nowej rzeczywistości, obowiązki w poszczególnych rolach również zaczynają się poszerzać. Na przykład deweloperzy stają się odpowiedzialni nie tylko za tworzenie aplikacji w fazie programowania, ale też za wydajność i stabilność w fazie działania. Jednocześnie zespół operacji uwzględnia nadzór, zabezpieczenia i zgodność w fazach planowania i programowania.  

Elastyczność i reaktywność 

Elastyczność zespołów pozwala na wydawanie oprogramowania w krótszych cyklach. Łatwiej jest planować wdrażanie zmian i zarządzać ryzykiem – to droga do stworzenia stabilnego produktu. Krótsze cykle wydawania nowych wersji pozwalają także sprawniej reagować na zmiany zachodzące na rynku, dzięki czemu można szybciej dostosować się do zmian potrzeb klientów i nie odstawać od konkurencji. Podejście DevOps stanowi state-of-the-art nowoczesnego tworzenia oprogramowania i jest dziś pierwszym wyborem wielu firm z tego powodu, że promuje najlepsze praktyki niezbędne do poprawy jakości oprogramowania. DevOps wymaga zmiany nie tylko w sposobie myślenia o infrastrukturze, ale także w  zakresie dobrego projektowania i organizowania wewnętrznej infrastruktury firmy.   

Ciągłe testowanie 

Ciągłe testowanie (Continuous Testing, CT) to umiejętne wykorzystanie pewnych narzędzi i technik. Cytując sylabus ISTQB, ciągłe testowanie to:  

„Podejście obejmujące proces wczesnego, częstego, szerokiego, automatycznego testowania w celu otrzymania możliwie szybko informacji zwrotnej o poziomie ryzyka biznesowego związanego z aplikacją przed jej wydaniem”.  

Podejście to znacznie skraca czas potrzebny do wykonania testów manualnych. 

Głównym celem wprowadzenia podejścia CI/CD jest poprawa jakości wydawanego oprogramowania, a ciągłe testowanie i kontrola powinny być częścią tego procesu.  Celem ciągłego testowania jest zapewnienie, że wydawane oprogramowanie będzie niezawodne.  W tym celu tworzy się różnego rodzaju testy, które mogą być wykonywane automatycznie za każdym razem, gdy oprogramowanie jest budowane. 

Poziomy testów w ciągłym testowaniu 

1. Testy jednostkowe – bazę testów automatycznych stanowią testy jednostkowe. Są one wykonywane za każdym razem, gdy oprogramowanie jest kompilowane i budowane.  

2. Testy integracyjne – kolejnym poziomem testów, który należy włączyć, są testy integracyjne. Są one przeprowadzane po testach jednostkowych i wykorzystują rzeczywiste dane. Testy integracyjne są ważną fazą w ciągłym testowaniu, ponieważ odpowiadają za testowanie całego systemu, a nie tylko tworzonego kodu.  

3. Testy akceptacyjne (E2E) – ostatnią fazą są testy akceptacyjne. W tej fazie wykonywane są testy przygotowane przez zespół QA w celu przetestowania systemu z punktu widzenia użytkownika. Celem tej fazy jest weryfikacja wymagań użytkownika i ich walidacja. 

Kontrola kodu 

Oprócz różnych faz testowania, istnieje także faza kontroli kodu. Polega ona na sprawdzeniu kodu przy wykorzystaniu zestawu reguł wykorzystywanych do sporządzenia raportu na temat samego oprogramowania. Można ją podzielić na dwie fazy:  

1. Przegląd kodu wykonywany przez programistę, który nie jest  jego autorem. Przed integracją z główną gałęzią (master) kod musi zostać zatwierdzony. Członkowie zespołu sprawdzają kod i dodają komentarze, jeśli jakieś fragmenty wymagają zmian. W tym przypadku autor kodu dokonuje zmian na ich podstawie, a po skończonej pracy kod ponownie trafia do przeglądu. Jeśli nikt nie będzie miał zastrzeżeń – kod zostanie zaakceptowany i scalony z główną gałęzią. 
2. Faza statycznej analizy jest wykonywana przez odpowiednie narzędzia. Kod może zostać wtedy zweryfikowany przez pewne reguły, na przykład sprawdzające złożoność metod.  

Automatyzacja i shift-left testing 

Ciągłe testowanie wykorzystuje podejścia automatyzacji do przyspieszenia testowania poprzez przyjęcie podejścia shift-left testing, które łączy etapy wytwarzania oprogramowania i zapewniania jakości. Takie podejście może obejmować zestaw przepływów pracy testów automatycznych, które można łączyć z narzędziami raportującymi i metrykami w celu otrzymania jasnego obrazu jakości oprogramowania. 

Zapewnia to zespołom projektowym otrzymanie szybkiej informacji zwrotnej na temat jakości oprogramowania. Pozwala również testować na wcześniejszych etapach wytwarzania oprogramowania oraz zwiększyć pokrycie testami, eliminując wąskie gardła testowe, takie jak: dostęp do współdzielonych środowisk testowych czy oczekiwanie na stabilny interfejs użytkownika. 

Ciągłe testowanie niesie ze sobą szereg korzyści, takich jak: 

• Integrowanie zespołów testowych, deweloperskich i operacyjnych na każdym etapie cyklu życia oprogramowania. 
• Pozwala na wdrożenie testów automatycznych w takim zakresie, jak to tylko możliwe, aby stale testować kluczowe funkcje. 
• Szybkie i ciągłe informacje zwrotne, które są istotne również dla biznesu. 
• Usunięcie wąskich gardeł w kwestii dostępności środowisk testowych, które mogą być stale dostępne. 
• Pozwala na stałe i aktywne zarządzanie jakością w całym etapie dostarczania oprogramowania.  

Fundamenty ciągłego testowania 

Ciągłe testowanie opiera się na kombinacji określonych narzędzi i technik. Odpowiednie ich wdrożenie tworzy system, dzięki któremu znacząco można ograniczyć liczbę błędów przedostających się na środowiska rozwojowe lub produkcyjne. Większość błędów ma bardzo krótką żywotność, ponieważ są one wyłapywane przez testy. Odpowiednie zaimplementowanie tego podejścia powinno rozpoczynać się na jak najwcześniejszym etapie cyklu życia oprogramowania, aby móc je odpowiednio budować, aktualizować i (w razie potrzeby) refaktoryzować. Sama budowa i działanie zależą w głównej mierze od potrzeb projektowych – inne testy i techniki będą wykorzystywane do testowania sklepu internetowego, inne do testowania systemów w branży automotive. Lecz niezależnie od przypadku, cel pozostanie ten sam – uzyskanie jak najszybciej informacji zwrotnej w przypadku wystąpienia błędu. 

Projektowanie małych komponentów i usług 

Idea ciągłego testowania polega na maksymalnym zautomatyzowaniu procesów testowania i wdrażania oraz zapewnieniu, że każdy komponent aplikacji może zostać poddany testom, gdy tylko zostanie opracowany. Przykłady, które mogą ułatwić implementację tego podejścia to: projektowanie małych komponentów i usług oraz projektowanie danych testowych wykorzystywanych w ciągłym testowaniu. 

Projektowanie małych komponentów i usług – nowe komponenty powinny nie tylko spełniać określone funkcje w trakcie działania programu, ale również być w pełni testowalne niezależnie od innych komponentów. Celem jest zapewnienie, że każda w pełni przetestowana usługa będzie spełniała swoje zadania zgodnie z założeniami, aby w trakcie ich łączenia i przejścia do etapu testów integracyjnych komponenty bezproblemowo współpracowały ze sobą.. Należy więc już na etapie projektowania odpowiednio przygotować architekturę i ograniczyć sprzężenie komponentów tak bardzo, jak to możliwe. W efekcie zyskamy komponenty bardziej stabilne, które zmniejsza ryzyko, że jakakolwiek zmiana dokonana w komponencie „A” spowoduje nieoczekiwaną zmianę zachowania w innych komponentach. Ograniczenie połączeń między nimi upraszcza proces testowania, rozwiązywania problemów oraz konserwacji. Dodatkowo w łatwiejszy sposób można izolować ewentualne problemy – analizie zostanie poddany konkretny komponent, bez potrzeby przeszukiwania ich grup i zależności między nimi. 

Projektowanie danych testowych wykorzystywanych w ciągłym testowaniu 

Posiadanie w pełni zautomatyzowanego rozwiązania do zarządzania danymi testowymi jest niezbędne do solidnego wdrożenia ciągłego testowania. Złym podejściem byłoby na przykład kopiowanie produkcyjnej bazy danych w celu utworzenia danych testowych, nie anonimizując uprzednio wrażliwych danych. Tworzenie nowych zestawów danych testowych od zera dla każdej serii testów również nie jest dobrym pomysłem ze względu na bardzo słabą efektywność, zwłaszcza gdy nie są generowane automatycznie. 

Jak zatem stworzyć skuteczne rozwiązania do generowania i zarządzania danymi testowymi? Z pomocą przychodzą pewne charakterystyki, do których można zaliczyć na przykład: 

• Tworzenie i generowanie danych testowych 
  Daje możliwość tworzenia nowych, zbiorczych zestawów danych uwzględniających zależności, tak jakby pochodziły ze środowiska produkcyjnego. 
• Możliwość pobrania pewnego podzbioru danych produkcyjnych 
  Na podstawie określonych kryteriów, maskowania wrażliwych pól i umieszczania ich w środowisku testowym, zachowując ich integralność referencyjną. Najtrudniejsza w realizacji jest ostatnia część: wrażliwe pola muszą być zamaskowane w taki sposób, aby zachować oryginalne powiązania między danymi. Przykładowo, jeśli wartość numeru PESEL musi zostać zamaskowana i zastąpiona niepowiązaną wartością, każde odwołanie do tego numeru PESEL w bazie danych musi zostać zamaskowane tą samą wartością. 
• Możliwość maskowania i transformacji danych 
  Rozwiązanie powinno też zapewnić możliwość automatycznego porównania danych wstępnie zamaskowanych, aby upewnić się, że nie doszło do ich utraty i że proces maskowania nie spowodował błędów w ich integralności. 
• Możliwość przesyłania danych 
  Proces polegający na przesyłaniu wyodrębnionych, zamaskowanych danych na środowiska testowe, z zachowaniem integralności. Proces ten powinien obejmować funkcje dodawania, edytowania, aktualizacji i usuwania. 
• Możliwość odświeżania danych 
  Polega na okresowym przeglądzie i usuwaniu starych pakietów danych testowych oraz zamienianiu ich na nowy zestaw. 
• Ekstrakcja danych i tworzenie ich podzbiorów 
  Pozwala na tworzenie mniejszych kopii danych produkcyjnych zdefiniowanych za pomocą określonych kryteriów. 
• „Postarzanie” danych 
  Technika, w której dane są zmieniane w celu dopasowania ich do określonych, specyficznych warunków i wykorzystania ich w pewnych procesach (na przykład symulacji określonej godziny lub daty). 
• Możliwość tworzenia i wyodrębniania danych testowych 
• Zarządzanie zbiorami danych 
• Wykorzystanie narzędzi, które umożliwiają nie tylko zarządzanie wieloma zbiorami danych, ale także ich archiwizację i wersjonowanie.  

Rola testów jednostkowych w ciągłym testowaniu 

Podstawę testów w podejściu ciągłego testowania, zgodnie z piramidą testów, stanowią testy jednostkowe. Są one najszybsze w wykonaniu i sprawdzają działanie oprogramowania we wczesnej fazie jego wytwarzania. Powinno ich więc być jak najwięcej (przy zachowaniu odpowiedniego stosunku liczby do jakości – nie jest prawdą, że większa liczba testów stanowi o jakości).  

Projektowanie testów jednostkowych 

Zdarza się, że testy jednostkowe są źle zaprojektowane i zamiast jednostek testują kompletne przypadki użycia (wywołanie metod, asercje, wywołanie większej liczby metod i tworzenie większej liczby asercji). Takie testy są zwykle niestabilne, a błędy wykryte w jednej części kodu mogą maskować inne błędy i utrudniać ich wykrycie. Aby temu zapobiec, należy przeanalizować takie testy, wyodrębnić z nich poszczególne, testowane funkcjonalności i asercje i rozbić je na mniejsze testy sprawdzające każdą funkcjonalność z osobna. 

Implementacja testów na różnych poziomach 

Testowanie bardziej złożonych ścieżek, dajmy na to przypadków użycia, powinno zostać zaimplementowane na przykład w testach akceptacyjnych. W ciągłym testowaniu można wykonywać wszystkie rodzaje testów, lecz im wyższy poziom testów, tym liczba przypadków testowych powinna być mniejsza (są one mniej stabilne, czas ich wykonywania jest dłuższy, wykrywają błędy w późniejszych etapach, przez co wydłuża się czas naprawy, a koszt rośnie). 

Dotyczy to zwłaszcza testów UI (User Interface), gdy testowana jest logika biznesowa i zachowanie interfejsu użytkownika. Może tu dojść do wielu współzależnych awarii. Oddzielenie warstwy interfejsu od systemu bazowego, aby logika biznesowa mogła zostać opatrzona zaślepkami (mock) jest istotną zmianą zbliżającą nas do większej stabilności testów. 

Jednym z podejść jest uruchamianie testów jednostkowych w sposób ciągły, a testów wyższych poziomów – na żądanie (nie muszą one być uruchamiane automatycznie w trakcie budowy projektu w narzędziu ciągłej integracji – zamiast tego, istnieje możliwość uruchomienia ich w sposób manualny, gdy potrzeba). 

Rola podejścia TDD 

Praktykowanie podejścia TDD (Test-Driven Development) w wytwarzaniu oprogramowania ułatwia zrozumienie i wdrożenie ciągłego testowania. W TDD testy tworzone są przed implementacją funkcjonalności. Najpierw tworzony jest mały test, po którym następuje implementowanie powiązanego fragmentu całej funkcjonalności. Następnie dokonuje się refaktoryzacji w celu ulepszenia kodu i wyeliminowania ewentualnych powieleń. Dzięki ciągłemu testowaniu otrzymujemy natychmiastową informację zwrotną na każdym z tych kroków. Nie tylko z tego jednego testu, który jest w danym momencie pisany, lecz ze wszystkich powiązanych testów, bez dodatkowego wysiłku i zaangażowania ze strony programisty. Dzięki temu może on skupić się w pełni na projektowaniu i pisaniu kodu, zamiast rozpraszać się koniecznością uruchamiania testów. 

Cel ciągłego testowania 

Zarówno w podejściu TDD, jak i w ciągłym testowaniu, celem jest jak najszybsze uzyskanie informacji zwrotnej. Pod wieloma względami naturalnym rezultatem skutecznego stosowania TDD jest dobrej jakości zestaw testów. Różnica polega na tym, że stosując ciągłe testowanie, zyskuje się dodatkowe źródła informacji zwrotnych. Stary aksjomat podejścia TDD mówi, że testy sprawdzają poprawność kodu, z kolei kod weryfikuje poprawność testów. Testy sprawdzają również projekt kodu – źle zaprojektowany kod jest trudny do przetestowania.  

Jakie narzędzia wykorzystywane są w procesie dostarczania oprogramowania z CI/CD? 

Jenkins 

Jenkins to serwer ciągłej integracji (CI) typu open source.  Kontroluje kilka etapów procesu dostarczania oprogramowania, takie jak testowanie, kompilacja i wdrażanie. Popularność tego narzędzia wynika między innymi z jego możliwości śledzenia i monitorowania powtarzalnych działań pojawiających się w trakcie prac nad projektem. Każda zmiana w aplikacji jest kompilowana i testowana, a w razie wykrycia błędu Jenkins ostrzeże zespół o problemach. 

Wdrożenie kodu na produkcję 

Jednym z podstawowych zastosowań Jenkinsa jest możliwość wdrażania kodu na produkcję. Jeśli wszystkie testy opracowane dla danej funkcji lub releasu zakończą się powodzeniem, Jenkins może automatycznie opublikować kod na środowisku staging lub produkcyjnym (jest to właśnie przykład Continuous Deployment opisanego w poprzednim artykule). 

Automatyzacja workflow i różnych zadań 

Innym przypadkiem, w którym można użyć Jenkinsa, jest m.in. automatyzacja workflow. Na przykład, gdy programista pracuje na kilku środowiskach, w pewnym momencie zajdzie konieczność instalacji lub aktualizacji pewnych komponentów na każdym z nich. Jeśli instalacja lub aktualizacja wymaga wykonania wielu kroków, przeprowadzenie jej ręcznie może skutkować pojawieniem się błędów, a dodatkowo będzie czasochłonne. Zamiast tego wszystkie kroki potrzebne do finalizacji można odpowiednio skonfigurować w Jenkinsie. Dzięki temu cały proces będzie stabilny i szybki, bo też zawsze będzie wykonywany identycznie. 

Konfiguracja zadań 

Jenkins umożliwia tworzenie zadań (Jenkins Jobs) na różne sposoby. Konfigurację można stworzyć całkowicie przez UI, przeklikując odpowiednie opcje, lecz lepszym wyborem jest utworzenie pliku konfiguracyjnego i zdefiniowanie w nim wszystkich niezbędnych kroków. W Jenkinsie wykorzystuje się w tym celu skrypty pisane w języku Groovy. Zaletą w stosowaniu tej opcji jest dodatkowo to, że plik konfiguracyjny można przechowywać wraz z kodem dotyczącej go aplikacji. Dzięki temu mamy zapewnione wersjonowanie zmian i powstaje kopia zapasowa, przydatna w przypadku wystąpienia awarii. 

Rozszerzalność poprzez pluginy 

Możliwości Jenkinsa można rozszerzać dzięki wielu pluginom dostępnym na stronie https://plugins.jenkins.io/. Ich liczba pozwala na dowolne skonfigurowanie serwera pod konkretne potrzeby, począwszy od zmiany wyglądu elementów interfejsu użytkownika po możliwość integracji z zewnętrznymi serwisami lub aplikacjami czy modyfikujące kroki w tworzonych jobach.  

GitLab 

Innym narzędziem, o którym warto wspomnieć, jest GitLab. Serwis ten nie tylko pozwala na tworzenie i przechowywanie repozytoriów kodu, ale także udostępnia narzędzia do wersjonowania oprogramowania, zarządzania zadaniami oraz procesami CI/CD. Pozwala on wszystkim członkom zespołu współpracować na wszystkich etapach projektu, upraszczając tworzenie oprogramowania. 

Funkcjonalności GitLaba 

GitLab to internetowe repozytorium Git, które umożliwia zespołom programistów planowanie, kodowanie, testowanie, wdrażanie i monitorowanie zmian tworzonego oprogramowania w jednym miejscu. Natomiast Git to dobrze wszystkim znany system kontroli wersji. 

Jedną z istotnych możliwości jest śledzenie błędów: GitLab posiada wbudowany system umożliwiający zespołom tworzenie, przypisywanie i śledzenie błędów. Zapewnia także tablicę zarządzania projektami z konfigurowalnymi przepływami pracy (workflow) w celu wizualizacji zadań i postępów. 

Inną kluczową funkcjonalnością GitLaba są zintegrowane potoki CI/CD (pipelines). Dzięki temu można łatwo zautomatyzować procesy testowania, budowania i wdrażania, zapewniając dokładne testowanie zmian w kodzie przed połączeniem z główną bazą kodu i wdrożeniem w środowisku produkcyjnym. 

GitLab posiada także wewnętrzny system wiki, umożliwiający zespołom tworzenie i utrzymywanie dokumentacji projektowej. 

Podsumowanie 

Podejście Continuous Integration wraz z Continuous Development i Continuous Testing stanowią komplementarne praktyki. Continuous Development umożliwia obserwowanie wdrażanych zmian w czasie rzeczywistym i jednocześnie eliminuje proces ręcznego śledzenia zmian. Błędy znalezione na jak najwcześniejszym etapie są najszybsze i najtańsze w naprawie. 

Budowanie aplikacji wraz z przeprowadzeniem testów na lokalnym środowisku może zająć kilka minut, a ich przeprowadzenie daje pewność, że wprowadzone zmiany będą przygotowane do integracji z główną gałęzią repozytorium. Czasem zmiany mogą budzić szczególne wątpliwości –   na przykład, gdy modyfikacji wymagają pliki konfiguracyjne. W takim przypadku można wykonać pełną kompilację i uruchomić wszystkie testy, aby mieć pewność, że zmiana nie spowodowała błędów w innych obszarach aplikacji, a kod jest bezpieczny i może zostać dodany do głównego repozytorium. 

Ciągła integracja ma na celu identyfikowanie problemów, ale może również posłużyć jako narzędzie do zmniejszania kosztów uruchamiania testów wyższego poziomu – wykrycie błędów na etapie testów jednostkowych sprawi, że testy z pozostałych poziomów będą bardziej stabilne, co daje dodatkową pewność co do jakości. at the capabilities are within the connectivity management framework. At Inetum, we are a partner of Cumulocity IoT, which has a network of partners providing platform-compatible devices with substantial connectivity capabilities.

Przejdź do:

1. 1. Definicja Continuous Integration (CI) oraz Continuous Delivery (CD)
2. 2. Wyzwania CI/ CD
3. 3. Czym jest ciągłe dostarczanie i automatyzacja CI/CD?
4. 4. Continuous Delivery (CD) 
5. 5. Korzyści ciągłego dostarczania (CD)
6. 6. Automatyzacja vs. manualne wdrażanie
7. 7. Podsumowanie

Continuous Integration, Delivery and Deployment to praktyki rozwoju oprogramowania, które w ostatnich latach zdobyły dużą popularność. Gdybyśmy mieli je podsumować jednym słowem, brzmiałoby to: automatyzacja. Wszystkie te trzy praktyki sprowadzają się do automatyzacji procesu testowania i wdrażania, minimalizacji (lub całkowitego eliminowania) potrzeby ingerencji człowieka, redukcji ryzyka wystąpienia błędów oraz ułatwienia tworzenia i wdrażania oprogramowania do tego stopnia, że może to zrobić każdy programista w zespole. Poznaj kluczowe praktyki i korzyści w zakresie automatyzacji CI/CD.  

Definicja Continuous Integration (CI) oraz Continuous Delivery (CD)

Ciągła integracja

Continuous Integration, CI jest praktyką stosowaną w procesie wytwarzania oprogramowania polegającą na częstym, regularnym integrowaniu bieżących zmian w kodzie do głównego repozytorium aplikacji. Zwykle programiści włączają swoje zmiany co najmniej raz dziennie, co przy zespole składającym się z kilku lub kilkunastu osób skutkuje wieloma integracjami wykonywanymi każdego dnia. Każda integracja jest weryfikowana przez zastosowanie automatyzacji w projekcie (włączając również testy automatyczne) w celu jak najszybszego wykrycia ewentualnych błędów integrowanego kodu. Stosowanie tego podejścia prowadzi do znacznego zmniejszenia liczby problemów związanych z integracją i umożliwia szybsze tworzenie spójnego oprogramowania.

Ciągłe dostarczanie

Continuous Delivery, CD – jest praktyką inżynierii oprogramowania polegającą na regularnym wydawaniu kolejnych wersji oprogramowania w krótkich cyklach. Oznacza to, że z każdą kompilacją budowana jest nowa wersja całego tworzonego oprogramowania. Nie znaczy to jednak, że oprogramowanie jest od razu wypuszczane na środowisko produkcyjne. Nic jednak nie stoi na przeszkodzie, aby to zrobić, gdyby zaszła taka potrzeba. Ta nieznaczna różnica dotycząca automatycznego wdrażania zmian bezpośrednio na środowisku produkcyjnym odróżnia ciągłe dostarczanie od ciągłego wdrażania (Continuous Deployment) – w którym to każda kompilacja całego oprogramowania kończy się wydaniem kolejnej wersji na środowisku produkcyjnym. Zespoły developerskie dbają o to, aby nowe funkcje były dodawane w małych pakietach, dzięki czemu ewentualne wydanie nowej wersji oprogramowania może nastąpić szybko i w dowolnym momencie. W praktyce maksymalizuje to możliwość uzyskania szybkiej informacji zwrotnej na temat oprogramowania zarówno z perspektywy biznesu, jak i technicznej.

Wyzwania CI/CD

O ciągłej integracji po raz pierwszy napisał Kent Beck w swojej książce pod tytułem „Extreme Programming Explained”, wydanej po raz pierwszy w 1999 roku. Ideą CI było: jeżeli regularna integracja kodu jest dobra – dlaczego nie wykonywać jej przez cały czas? „Cały czas” oznacza: za każdym razem, gdy ktoś wprowadza zmianę w systemie kontroli wersji.

Problem z ciągłą integracją, dostarczaniem i wdrażaniem polega jednak na tym, że konfiguracja nie należy do najprostszych czynności i zajmuje dużo czasu, zwłaszcza jeśli zespół ma z nią do czynienia po raz pierwszy lub postanowiono wdrożyć proces do istniejącego już projektu.

Jednak korzyści płynące z wprowadzenia tych praktyk są warte poświęconego czasu. Przejawi się to w mniejszej liczbie błędów, ułatwieniu ich identyfikacji i naprawy, a ostatecznie w stworzeniu oprogramowania lepszej jakości.

Czym jest ciągłe dostarczanie i automatyzacja CI/CD?

Ciągła integracja (CI).

Kluczowe aspekty skutecznej ciągłej integracji

Przyjrzyjmy się CI jeszcze bliżej. Ciągła integracja na przestrzeni ostatnich kilku lat stała się w zasadzie standardem w zwinnych metodykach wytwarzania oprogramowania. Początkowo, w połączeniu z uruchamianiem automatycznych testów jednostkowych na lokalnym środowisku programisty, miała na celu zapewnienie, że programista nie włączy kodu, który mógłby powodować błędy w aplikacji. Z biegiem czasu metoda ta ewoluowała.

Obecnie kompilacje uruchamiane są na serwerach ciągłej integracji, które budują projekt oraz uruchamiają zautomatyzowane testy – automatycznie, przy każdej zmianie dodanej przez programistów, lub okresowo. Wynik (w postaci raportów, logów) generowany jest po zakończeniu procesu budowania. Obecnie podejście ciągłej integracji jest wykorzystywane nie tylko w metodykach zwinnych, ale również w innych metodykach wytwarzania oprogramowania.

Oprócz przeprowadzania testów jednostkowych i integracyjnych można też uruchamiać testy statyczne i dynamiczne, mierzyć i profilować wydajność, tworzyć dokumentację bazującą na kodzie źródłowym oraz upraszczać manualne procesy zapewnienia jakości. W ten sposób ciągła integracja zapewnia również ciągłą kontrolę jakości oprogramowania.

Dobrze funkcjonująca ciągła integracja opiera się na spełnieniu pewnych warunków wstępnych, a także przestrzeganiu kilku podstawowych praktyk. Przy jej wdrażaniu należy zadbać przede wszystkim o trzy rzeczy:

1. Narzędzie kontroli wersji
   Wszystko w projekcie musi być ewidencjonowane w jednym narzędziu kontroli wersji: kod, skrypty, bazy danych, skrypty kompilacji i wdrażania oraz wszystko inne, co jest niezbędne do tworzenia, instalowania, uruchamiania i testowania aplikacji.
2. Narzędzie do zautomatyzowanej kompilacji
   Należy mieć możliwość uruchomienia kompilacji za pomocą wiersza poleceń. Podstawowym narzędziem może być prosty program wiersza poleceń, który skompiluje tworzony program, a następnie uruchomi testy. Może to być też złożona kolekcja skryptów kompilacji, które wywołują się nawzajem w odpowiedniej kolejności. Niezależnie od mechanizmu, osoba lub komputer musi mieć możliwość uruchomienia kompilacji, budowania, uruchamiania testów i wdrażania w sposób zautomatyzowany za pomocą wiersza poleceń. Skrypty powinny być traktowane jak kod – muszą być testowane i stale refaktoryzowane, aby były stabilne, uporządkowane i łatwe do zrozumienia.
3. Zgoda całego zespołu
   Ciągła integracja jest praktyką, a nie narzędziem. Wymaga od zespołu programistycznego dyscypliny i zaangażowania. Każdy w zespole musi często wprowadzać swoje zmiany do repozytorium i przyjąć założenie, że najważniejszym zadaniem w trakcie pracy nad projektem jest naprawa wszelkich zmian, które psują aplikację. Jeśli zespół nie będzie przestrzegał tych zasad, poprawne wdrożenie ciągłej integracji może nie być efektywne i nie doprowadzi do satysfakcjonującej poprawy jakości wytwarzania oprogramowania.

Zalety ciągłej integracji w porównaniu z podejściem tradycyjnym

W porównaniu do tradycyjnego podejścia, gdzie zmiany wprowadzane w kodzie źródłowym są kompilowane, testowane i integrowane raz na jakiś czas (raz w tygodniu lub rzadziej), wykorzystanie podejścia ciągłej integracji zapewnia wiele korzyści:

• wcześniejsze wykrywanie problemów kompilacji/integracji, dzięki czemu są naprawiane w sposób ciągły, a nie w ostatniej chwili, tuż zanim główna wersja oprogramowania zostanie przygotowana do wydania, 
• zespół otrzymuje natychmiastową informację zwrotną na temat jakości, funkcjonalności oraz wpływu pisanego kodu na cały system, 
• w ramach tego procesu wykonywane są zautomatyzowane testy. Dzięki nim możliwa jest natychmiastowa kontrola poprawności architektury projektu i jakości kodu – są one wykonywane w ramach procesów kompilacji, budowania i wdrażania zmian (deployment) na różne środowiska, 
• wczesny dostęp do aktualnej wersji oprogramowania (przed oficjalnym wydaniem) do celów testowych lub demonstracyjnych. 

Kluczowe praktyki w procesie ciągłej integracji

Optymalne korzyści z procesu ciągłej integracji można uzyskać, gdy przestrzega się ustalonych w zespole procedur, co wymaga dyscypliny, jak wspomniałem wcześniej. Istnieją też sprawdzone, dobre praktyki, których przestrzeganie znacząco zwiększy sukces we wdrożeniu tego procesu. Składają się na nie poniższe aspekty: 

1. Częsta integracja kodu – najważniejsza praktyka w ciągłej integracji. Kod powinno się integrować przynajmniej kilka razy dziennie. Regularne wysyłanie zmian niesie ze sobą inne korzyści – zmiany są przesyłane w mniejszych pakietach, co zmniejsza prawdopodobieństwo błędu w kompilacji, a także ułatwia poszukiwanie ewentualnych zmian (mniejsza liczba plików do przeszukiwania). To minimalizuje też prawdopodobieństwo wystąpienia konfliktów z kodem innych programistów w przypadku pracy wymagającej zmiany w wielu plikach. W przypadku awarii lokalnej stacji roboczej, która spowodowałyby utratę lokalnych zmian w kodzie – programista nie musi pisać wszystkiego od początku, lecz może zacząć od etapu zmian wprowadzonych w ostatniej integracji.
2. Zarządzanie obszarem roboczym – ważne jest, aby środowisko programistyczne było starannie zarządzane – przede wszystkim zwiększa to produktywność. Deweloperzy powinni zawsze rozpoczynać nową pracę od aktualnej, działającej wersji kodu z głównej gałęzi repozytorium. Powinni móc uruchomić kompilację, testy i być w stanie wdrożyć aplikację w swoim lokalnym środowisku. Uruchamianie aplikacji w środowisku lokalnym powinno wykorzystywać te same zautomatyzowane procesy, co w serwerach ciągłej integracji.
3. Kompleksowy zestaw testów automatycznych – konieczne jest posiadanie zestawu testów automatycznych, aby mieć pewność, że aplikacja działa poprawnie. Najważniejsze z punktu widzenia ciągłej integracji są testy: jednostkowe, integracyjne oraz akceptacyjne. Ich kombinacja powinna zapewnić bardzo wysoki poziom pewności co do tego, że żadna z wprowadzonych zmian nie naruszyła stabilności aplikacji.   
4. Krótki proces budowania i testowania projektu – kompilacja, budowanie i wykonanie testów nie powinny trwać dłużej niż 5-10 minut. Jeśli z jakiegoś powodu proces ten zajmuje zbyt dużo czasu, mogą wystąpić problemy takie jak: 
   • niecierpliwość programistów – mogą oni przestać wykonywać pełną procedurę (na przykład pomijać etap testów), co będzie powodować więcej błędów kompilacji na serwerze ciągłej integracji. 
   • proces ciągłej integracji może trwać tak długo, że do czasu ponownego uruchomienia kompilacji może zostać zintegrowanych wiele zmian – znalezienie tej, która powoduje błędy, może być bardzo czasochłonne. 
   • rzadsza integracja zmian przez programistów z powodu czasochłonności procesu – czekanie kilku godzin na zakończenie kompilacji i testów jest stratą czasu i zasobów. 

Continuous Delivery (CD) 

Ciągła integracja stanowi podstawę solidnego, nowoczesnego wytwarzania oprogramowania. Jest to czynnik umożliwiający wdrożenie jeszcze bardziej zaawansowanych technik. W ciągłej integracji, gdy wszystkie testy zakończą się pomyślnie, zyskujemy pewność, że oprogramowanie działa. Jednakże – w jaki sposób upewnić się, że oprogramowanie będzie działało w środowisku docelowym? Czy będzie współpracowało z innymi aplikacjami? Wreszcie – jak dostarczyć je do użytkowników końcowych? Z pomocą przychodzi podejście ciągłego dostarczania (Continuous Delivery, CD). 

W swej istocie ciągłe dostarczanie polega na minimalizowaniu czasu potrzebnego do wprowadzenia zmian w aplikacji oraz minimalizowaniu ryzyka wystąpienia problemów, które także mogą pojawić się w trakcie tego procesu. Może składać się z kilku faz, takich jak: 

• Odkrywanie – w której analizuje się pomysły, ogólne działanie, funkcjonalności – aby uzyskać szersze zrozumienie przestrzeni problemu i zastanowić się nad potencjalnymi rozwiązaniami. 
• Definiowanie – gdzie formalne kryteria akceptacji i prace projektowe stanowią bazę do dalszych prac rozwojowych. 
• Rozwój – w której produkt jest budowany i testowany funkcjonalnie. 
• Akceptacja – w tej fazie przeprowadzane są testy akceptacyjne wysokiego poziomu i uzyskuje się potwierdzenia od akcjonariuszy. 
• Wdrożenie – zmiana jest wprowadzana na produkcję. 
• Weryfikacja – w ramach której, na podstawie wszelkich danych, analizuje się zmiany, aby upewnić się, że osiągnęły one zamierzony wpływ. 

Każda faza stanowi swego rodzaju listę kontrolną określającą, co jest potrzebne, aby zmiany szły naprzód. Czasem przywołane fazy wysokiego poziomu są podzielone na bardziej szczegółowe. Na przykład, faza rozwoju może mieć wyszczególnione podfazy:  

• architektury technicznej,  
• budowania lub kompilacji,  
• i przeglądu kodu.  

Niezależnie od złożoności poszczególnych faz, zadania związane z pracą nad nimi mogą być podejmowane przez wiele osób o różnych umiejętnościach. Zadania mogą być więc wykonywane równolegle, lecz powinny zachować niezależność. 

Continuous Delivery automatyzuje proces wdrażania oprogramowania na różne środowiska w projekcie. Niektóre z nich można wykorzystać do przeprowadzania różnych testów automatycznych, takich jak:  

• testy integracyjne,  
• testy akceptacyjne,  
• czy też testy niefunkcjonalne, jak na przykład testy wydajnościowe lub penetracyjne.  

Nie należy również zapominać o przeprowadzeniu testów manualnych, które mogą wykryć nowe klasy defektów, których automatyczne testy zwykle nie są w stanie wychwycić. 

Korzyści ciągłego dostarczania (CD) 

Wdrożenie podejścia ciągłego dostarczania niesie wiele korzyści, do których należą:

#1. Oszczędność czasu

W średnich i dużych firmach programy oraz ich infrastruktura są zwykle tworzone i obsługiwane przez wiele oddzielnych zespołów. Każde wdrożenie nowej wersji aplikacji musi być skoordynowane między nimi. Należy ustalić między zespołami datę wprowadzenia nowej zmiany, takiej, która obu zespołom będzie odpowiadała.

Ponadto należy rozpowszechnić informację na temat nowej wersji (na przykład: jakie obszary aplikacji zostaną poddane zmianom, czy jest wymagana nowa konfiguracja, zmiany w integracji itp.). Dodatkowo zespoły muszą udostępnić niezbędne pliki, i tak dalej – procedury mogą się różnić w zależności od stopnia formalności i dojrzałości procesów w organizacji.

Generalnie wszystkie niezbędne działania z pewnością będą trwały kilka godzin, czasem nawet kilka dni. Często procesowi temu towarzyszą również przestoje spowodowane różnymi czynnikami. A ponieważ przestojów należy unikać w godzinach pracy, zdarza się, że wdrożenia odbywają się w nocy lub w weekend. Może to działać demotywująco na zespoły operacyjne odpowiedzialne za wdrożenie, a stąd już tylko krok do popełniania błędów. Wprowadzenie ciągłego wdrażania poprzez automatyzację zadań może zaoszczędzić wiele czasu i skrócić proces z kilku dni do nawet kilku minut oraz oszczędzić nerwów ludziom z zespołów operacyjnych. Dobrze skonfigurowane narzędzie pozwoli na praktycznie bezobsługowe wdrożenie, koordynowane przez jedną lub kilka osób bez potrzeby angażowania całych zespołów.

#2. Krótsze cykle wdrożeń

Firmy wykonujące wydania i wdrożenia manualnie robią to zwykle raz w tygodniu lub nawet rzadziej. Rzadkie wydania doprowadzają do przedłużających się procesów rozwoju, a w ostateczności spowolnienia czasu wprowadzenia produktu na rynek. Jeżeli na przykład oprogramowanie jest aktualizowane raz na kwartał, wprowadzenie nowej, małej funkcji lub istotnej poprawki może niepotrzebnie rozciągnąć się w czasie i spowodować odpływ klientów. Na przykład właściciel sklepu internetowego, w którym pewien etap procesu zakupowego został źle zaprojektowany (co powoduje trudności w zakupach) będzie musiał czekać 3 miesiące, zanim poprawka zostanie wdrożona. W tym czasie sklep może stracić ogromną liczbę klientów, a co za tym idzie – realne pieniądze. Automatyczne wdrażanie może całkowicie wyeliminować ten rodzaj problemów.

#3. Krótszy czas otrzymania informacji zwrotnej (feedback)

Najlepszym sposobem na uzyskanie wartościowych opinii na temat produktu jest wdrożenie go na środowisko produkcyjne, gdzie będzie ono używane przez prawdziwych użytkowników. Dzięki temu można mierzyć ich zaangażowanie w różnych częściach systemu. Użytkownicy często wyrażają również opinie na temat aplikacji i sugerują zmiany.

Niestety, zadanie to nie jest takie proste, gdy tworzy się na przykład narzędzia do użytku wewnętrznego w firmie. Można wtedy poprosić kilka osób, aby przetestowały je na jednym ze środowisk testowych, lecz to rodzi wyzwania. Potrzeba na to wykorzystania ich roboczogodzin, środowisko testowe musi być w pełni przygotowane i skonfigurowane z wszystkimi niezbędnymi danymi, które na końcu i tak zostaną usunięte. Jest to proces czasochłonny i skomplikowany.

Przy ręcznych wydaniach, co często idzie w parze z nieczęstym okresem wdrażania, cykl otrzymania feedbacku jest bardzo powolny, co jest sprzeczne z całą ideą zwinnego procesu wytwarzania oprogramowania. Komunikacja między ludźmi również nie zawsze jest idealna – praca w grupie to zawsze ryzyko nieporozumień. Zdarza się, że pierwsza implementacja funkcjonalności nie spełnia pierwotnych oczekiwań. W takiej sytuacji dyskusje (a więc informacja zwrotna) są nieuniknione. Powolne cykle wdrożeniowe prowadzą zatem do spowolnienia rozwoju aplikacji, frustrując nie tylko zespół, ale także interesariuszy. Użytkownicy docelowi, zdając sobie sprawę z czasu trwania wdrażania kolejnych aktualizacji, mogą nawet nie prosić o poprawki lub nie sugerować różnych udogodnień – prędzej przeniosą się do aplikacji konkurencyjnej, której autorzy lepiej dbają o ten aspekt. Na dłuższą metę powolne cykle wdrożeniowe przekładają się na utratę jakości aplikacji i odpływ użytkowników.

#4. Niezawodność wydań

Manualne wdrażanie zazwyczaj nie odbywa się często. To oznacza, że każde wydanie zawiera dużo zmian, co z kolei zwiększa ryzyko niepowodzenia. Gdy duże aktualizacje są źródłem zbyt wielu problemów, inżynierowie i managerowie szukają sposobów na poprawę stabilności kolejnego wydania, niejednokrotnie poprzez tworzenie kolejnych procedur i list kontrolnych.

Tworzy to błędne koło, ponieważ więcej procesów wymaga włożenia jeszcze większego wysiłku w kolejne wydania, a co za tym idzie – więcej czasu. Sprawia to, że cykle wydawania oprogramowania są jeszcze dłuższe, co z kolei rodzi potrzebę zmiany procedur, aby… ten czas skrócić. Sposobem na wyjście z tego błędnego koła jest automatyzacja etapów lub nawet całego procesu wydawania. Gdy więc proces ten stanie się niezawodny i szybszy, nic nie będzie stało na przeszkodzie, aby zwiększyć liczbę wydań, które jednorazowo będą zawierały mniejsze zmiany. Czas zaoszczędzony dzięki automatyzacji uwalnia zasoby, które można wykorzystać, aby jeszcze bardziej usprawnić zautomatyzowany proces wydawania.

#5. Mniejsze pakiety ułatwiają znalezienie źródła problemu

Kiedy wdrożenie spowoduje błąd w oprogramowaniu (a zawierało ono tylko jedną lub dwie nowe funkcje lub same poprawki błędów), dość łatwo można ustalić, która ze zmian stanowi źródło błędu. Duże pakiety, gdzie na jedno wydanie przypada wiele zmian w różnych częściach aplikacji, utrudniają znalezienie źródła problemów i wydłużają czas poszukiwań oraz naprawy. Ta, ze względu na wiele zmian zawartych w wydaniu (poziom skomplikowania pakietu przez różne zależności) trwa dłużej.

#6. Swoboda architektoniczna

Obecne trendy w inżynierii oprogramowania odchodzą od monolitycznych aplikacji na rzecz systemów rozproszonych, składających się z małych komponentów (mikroserwisów). Mniejsze aplikacje lub usługi są łatwiejsze w utrzymaniu, a wymagania dotyczące skalowalności wymuszają, aby działały na różnych urządzeniach, często na wielu jednocześnie. Ręczne wydawanie poszczególnych mikroserwisów, w przypadku gdy są ich setki, wydaje się być niemożliwe do przeprowadzenia w sposób bezawaryjny w satysfakcjonującym czasie. Automatyzacja wdrożeń pozwala konfigurować wydawanie aplikacji w sposób optymalny, tak, aby zapewnić niezawodność działania oprogramowania.

#7. Zaawansowane techniki zapewnienia jakości

Wyobraźmy sobie wyszukiwarkę wycieczek, której właściciel chce ulepszyć algorytm wyszukiwania. Można wdrożyć zarówno starą, jak i nową wersję silnika jednocześnie i uruchamiać zapytania na obu. Definiując przy tym odpowiednie metryki, można w prosty sposób oceniać działanie nowego algorytmu. Dzięki nim, w przypadku, gdy stary silnik będzie zwracał na przykład lepsze wyniki na niektóre zapytania – można wykorzystać te dane w celu ulepszenia nowego. Automatyczne wdrażanie nie jest samo w sobie gwarantem zapewnienia jakości, ale stanowi bazę do zastosowania zaawansowanych technik w celu jego osiągnięcia.

Automatyzacja vs. manualne wdrażanie

Główne praktyki stosowane w obu podejściach (Continuous Integration i Continuous Deployment) są jednakowe. Różnicę stanowi etap zastosowania automatyzacji wdrożenia do środowiska produkcyjnego, co obrazuje poniższy rysunek.  

Jak już wspomniałem, celem podejścia Continuous Delivery jest automatyzacja każdego etapu cyklu wdrażania do ostatniego środowiska przedprodukcyjnego, dzięki czemu zmiany można wprowadzić na docelowe środowisko w dowolnym momencie. W Continuous Deployment zmiany są dostarczane bezpośrednio na środowisko produkcyjne. Różnica to sposób wdrażania – automatyczny lub manualny.

Praktyka ciągłego wdrażania jest skomplikowana, procesy wykorzystywane w ciągłej integracji nie są w stanie pokryć wszystkich niezbędnych etapów koniecznych do jej poprawnego zaimplementowania w projekcie. Niezbędne jest użycie dodatkowych narzędzi, pozwalających na testowanie i kontrolowanie różnych części systemu (na przykład wydajności, gotowości do działania, weryfikacja poprawności integracji itp.).

Podsumowanie

Dziś bez praktyk CI/CD trudno wyobrazić sobie jakikolwiek nowoczesny projekt IT. Automatyzacja procesów ciągłej integracji i ciągłego dostarczania pozwala nam skrócić czas wdrażania zmian, wydawać oprogramowanie częściej i w sposób niezawodny. Dodatkowo szybciej uzyskujemy feedback od użytkowników. Już teraz zachęcam was do lektury drugiej części artykułu. Przyjrzę się w nim bliżej procesowi dostarczania oprogramowania z wykorzystaniem CI/CD i omówię konkretne praktyki testerskie wraz z przeglądem najlepszych narzędzi CI/CD.