Pseudokod to uniwersalny, uproszczony sposób zapisu działania algorytmu, który łączy naturalny język ludzki z podstawowymi strukturami programistycznymi. Używamy go żeby zaplanować logikę aplikacji przed napisaniem właściwego kodu źródłowego. Dzięki temu analitycy biznesowi i programiści mają wspólny punkt odniesienia. Nie wymaga kompilatora. Skupia się wyłącznie na krokach prowadzących do rozwiązania problemu.
Piszemy go zazwyczaj na kartce, tablicy lub w zwykłym notatniku tekstowym. Zasady są proste. Zaczynamy od zdefiniowania danych wejściowych, a potem linijka po linijce opisujemy co system ma z nimi zrobić. Używamy wcięć do oznaczania bloków warunkowych i pętli. Unikamy specyficznej składni konkretnych języków takich jak Python czy Java. Dobrym pomysłem jest stosowanie angielskich słów kluczowych typu IF, WHILE, FOR, bo to ujednolica zapis w międzynarodowych zespołach.
Jak pisać pseudokod żeby programiści nas zrozumieli?
Najgorsza opcja z wszystkich to pisanie referatów. Zamiast lać wodę w dokumentacji, musimy podać konkretne instrukcje krok po kroku. Programista nie czyta opowieści o biznesowych potrzebach, gdy siada do edytora kodu. Szuka twardych zmiennych, warunków brzegowych i operacji matematycznych. Pisz krótko. Używaj czasowników w stronie czynnej. Zamiast pisać, że dane zostaną pobrane przez system, napisz po prostu „Pobierz dane logowania”.
Zrobiliśmy na wdrożeniu moduł autoryzacji dla małej apteki na krakowskim Podgórzu we wtorek. Wcześniej analityk opisał to w pięciu stronach prozy. Zespół deweloperski zgubił się po drugim akapicie. Przerobiliśmy to na dwadzieścia linijek prostego pseudokodu. W środę rano moduł działał bez błędu. To jest bez mała najlepszy dowód na to, że techniczny skrót myślowy wygrywa z korporacyjną nowomową. Prawda jest zresztą absolutnie taka, że baza danych nie wybacza błędów w interpretacji słownej.
Czym różni się pseudokod od zwykłego schematu blokowego?
Schemat blokowy to grafika. Pseudokod to tekst. Rysowanie rombów i prostokątów sprawdza się przy prostych procesach decyzyjnych. Kiedy algorytm ma zagnieżdżone w sobie cztery pętle i kilkanaście warunków, schemat zamienia się w nieczytelną plątaninę strzałek. Zapis tekstowy pozwala na zachowanie porządku dzięki zwykłym wcięciom. Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Zazwyczaj winne jest graficzne modelowanie procesów, które gubi szczegóły techniczne. Zapis tekstowy wymusza myślenie o typach danych. Grafika pozwala na niebezpieczne skróty.
Jakie są podstawowe zasady tworzenia logiki w pseudokodzie?
Zaczynamy i kończymy algorytm wyraźnymi komendami START i STOP. Deklarujemy zmienne na samej górze. Każda operacja przypisania wartości musi być jasna. Używamy znaku równości lub strzałki skierowanej w lewo. Nie mieszamy języka polskiego z angielskimi strukturami w sposób losowy. Przyjmujemy jedną konwencję na cały projekt.
| Język naturalny | Odpowiednik w pseudokodzie |
| Jeśli użytkownik ma więcej niż 18 lat, wpuść go. | IF wiek > 18 THEN dostep = TRUE |
| Powtarzaj to aż skończą się maile w skrzynce. | WHILE maile_nieprzeczytane > 0 DO czytaj_mail() |
| Zwiększ licznik o jeden. | licznik = licznik + 1 |
| Wyświetl wynik na ekranie. | PRINT wynik |
Tabele takie jak ta wyżej pokazują, jak łatwo przełożyć myślenie biznesowe na instrukcje. Maszyna nie domyśli się kontekstu. Musimy podać jej wszystko na tacy.
Składnia i zmienne w codziennej pracy analityka
Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku. Nie wiem jak inne zespoły to formatują. U nas w biurze przyjęliśmy zasadę, że zmienne piszemy małymi literami z podkreśleniami. Słowa kontrolne wielkimi literami. Funkcje mają nawiasy na końcu. Taki układ pozwala odróżnić operację od danych, na których ta operacja się wykonuje. Czasem kod po prostu wywala się na pysk przez złe typowanie już na etapie planowania. Zapominamy, że tekst to nie liczba. Próba dodania słowa do cyfry w pseudokodzie przejdzie bez błędu. W prawdziwym środowisku programistycznym zablokuje cały proces.
Jak opisać pętle i instrukcje warunkowe bez używania konkretnego języka?
Instrukcje warunkowe to rdzeń każdego programu. Oznaczamy je blokiem IF, THEN, ELSE. Zawsze musimy przewidzieć ścieżkę negatywną. Jeśli sprawdzamy czy hasło jest poprawne, musimy zapisać co system zrobi, gdy poprawne nie będzie. Zostawienie pustego ELSE to proszenie się o kłopoty. Brak obsługi błędów na etapie projektowania mści się podczas testów integracyjnych.
Pętle wymagają jeszcze większej ostrożności. Złe zaplanowanie warunku wyjścia tworzy pętlę nieskończoną. Serwer zawiesza się i przestaje odpowiadać na zapytania użytkowników. Pamiętajmy o kilku żelaznych regułach podczas pisania:
- Zawsze jasno określaj warunek brzegowy przerywający działanie pętli, bo bez tego system zawiesi się w nieskończonym oczekiwaniu na zmianę stanu zmiennej, która nigdy nie nadejdzie z zewnątrz.
- Używaj wcięć konsekwentnie.
- Zamykaj bloki komendą END IF lub END WHILE.
- Aktualizuj licznik wewnątrz pętli.
Przykłady algorytmów z życia codziennego w IT
Weźmy prosty mechanizm logowania do aplikacji bankowej. Użytkownik podaje login. System weryfikuje go w bazie. Następnie prosi o PIN. Mamy trzy próby. Jeśli się pomylimy, konto zostaje zablokowane.
START
zmienna proby = 0
WHILE proby < 3 DO
POBIERZ pin_od_uzytkownika
IF pin_od_uzytkownika == pin_w_bazie THEN
ZALOGUJ_UZYTKOWNIKA()
STOP
ELSE
proby = proby + 1
PRINT „Błędny PIN”
END IF
END WHILE
ZABLOKUJ_KONTO()
STOP
Zwykły użytkownik klika i czeka, a w tle leci pętla sprawdzająca uprawnienia. BAZA danych musi otrzymać precyzyjne zapytanie. Brak aktualizacji zmiennej proby spowodowałby, że użytkownik mógłby zgadywać PIN w nieskończoność. To prosta droga do wycieku danych.
Dlaczego tworzenie pseudokodu pomaga w naprawianiu błędów przed wdrożeniem?
Papier jest tani. Serwer produkcyjny jest drogi. Poprawa błędu logicznego na etapie projektowania kosztuje pięć minut pracy analityka. Poprawa tego samego błędu po wdrożeniu na środowisko produkcyjne angażuje programistę, testera, kierownika projektu i dział wsparcia klienta. Bez mała prawie osiemdziesiąt procent błędów logicznych wyłapujemy czytając wspólnie instrukcje tekstowe na spotkaniach planistycznych.
Czytanie na sucho pozwala symulować działanie systemu w głowie. Nazywamy to „dry run”. Przechodzimy linijka po linijce z ołówkiem w ręku. Śledzimy jak zmieniają się wartości zmiennych. Jeśli w trzecim kroku zmienna traci swoją wartość, od razu wiemy, gdzie brakuje operacji przypisania. Nie potrzebujemy do tego środowiska testowego za tysiące dolarów. Wystarczy bystre oko inżyniera. Zmieniliśmy te zasady na robocie rok temu i liczba krytycznych awarii spadła o połowę. Czasem brutalne i proste metody dają najlepsze rezultaty.
Kto najczęściej czyta pseudokod w zespole projektowym?
Wydaje się, że to narzędzie wyłącznie dla programistów. To błąd. W dobrze ułożonym procesie wytwarzania oprogramowania, ten format dokumentacji przechodzi przez wiele rąk. Każda z ról w zespole szuka w nim innych informacji.
Analitycy biznesowi weryfikują czy wszystkie wymagania klienta zostały uwzględnione. Testerzy na podstawie tych krótkich instrukcji piszą przypadki testowe. Wiedzą dokładnie, jakie warunki brzegowe muszą sprawdzić. Programiści przepisują to na docelowy język programowania. Architekci oceniają złożoność obliczeniową i decydują o doborze odpowiednich struktur danych w tle. My czytamy. Wy piszecie.
Najczęstsze błędy podczas rozpisywania logiki aplikacji
Młodzi adepci inżynierii oprogramowania mają tendencję do pisania gotowego kodu w Pythonie lub C++ i nazywania go pseudokodem. Wrzucają specyficzne dla danego języka metody wbudowane, operatory trójargumentowe i skomplikowane zarządzanie pamięcią. Przestaje to być czytelne dla osoby nietechnicznej. Skrótowość jest dobra. Zbytnia technikalizacja zabija główny cel tego narzędzia. Kolejnym grzechem jest mieszanie poziomów abstrakcji. W jednej linijce autor pisze „Oblicz podatek”, a w następnej rozpisuje ręcznie algorytm sortowania bąbelkowego dla listy produktów. Należy trzymać się jednego poziomu szczegółowości operacji.
Z drugiej strony mamy analityków, którzy piszą zbyt ogólnikowo. Komenda „Zrób raport z danych” nie mówi absolutnie nic. Jakich danych? Z jakiego okresu? W jakim formacie ma być ten raport? Brakuje parametrów wejściowych. Taki zapis rodzi dziesiątki pytań podczas implementacji i opóźnia zamknięcie sprintu. Musimy znaleźć złoty środek między biznesowym ogólnikiem a programistycznym detalem.
Wszystko zależy od doświadczenia. Siadaj do edytora, weź konkretny problem ze swojego projektu i po prostu spróbuj go opisać krok po kroku, używając maksymalnie dwudziestu linijek tekstu. Sprawdź, czy twój kolega z biurka obok zrozumie intencję bez zadawania pytań pomocniczych.
FAQ – Najczęściej zadawane pytania
-
1. Czy pseudokod ma jakieś oficjalne standardy i normy ISO?
Nie. Nie istnieje jeden oficjalny standard. Każda uczelnia techniczna i każda firma informatyczna wypracowuje swój własny styl. Najważniejsza jest konsekwencja w obrębie jednego zespołu projektowego. -
2. Jakiego języka najlepiej używać do pisania słów kluczowych?
Zdecydowanie angielskiego. Słowa takie jak IF, WHILE, FOR, RETURN są naturalne dla każdego programisty na świecie. Zmienne i opisy funkcji można pisać po polsku, ale słowa sterujące logiką powinny zostać anglojęzyczne. -
3. Czym różni się pseudokod od języka Python?
Python to pełnoprawny język programowania, który można uruchomić na komputerze. Wymaga ścisłej składni, instalacji interpretera i dbałości o detale. Pseudokod to tylko notatka koncepcyjna na papierze. Nie da się go skompilować. -
4. Kiedy nie warto tracić czasu na pisanie pseudokodu?
Przy bardzo prostych operacjach typu CRUD (Create, Read, Update, Delete). Jeśli robisz standardowy formularz kontaktowy, który tylko zapisuje imię i email do bazy, rozpisywanie tego na kroki to strata czasu. Stosuj to przy złożonej logice biznesowej. -
5. W jakim programie najlepiej tworzyć takie zapisy?
Wystarczy zwykły Notatnik, Notepad++, Sublime Text lub środowisko Confluence. Narzędzie nie ma znaczenia. Liczy się obsługa wcięć (tabulatorów), które wizualnie organizują bloki kodu. -
6. Czy rekruterzy proszą o pisanie pseudokodu na rozmowach o pracę?
Bardzo często. Sprawdzają w ten sposób umiejętność logicznego myślenia kandydata bez oceniania jego znajomości specyficznej składni danego języka. Chcą zobaczyć jak rozwiązujesz problem analityczny.
Bibliografia
1. Politechnika Warszawska – https://www.pw.edu.pl
2. Wydawnictwo Naukowe PWN – https://pwn.pl
3. Uniwersytet Jagielloński – https://www.uj.edu.pl
4. Główny Urząd Statystyczny – https://stat.gov.pl
5. Narodowe Centrum Badania i Rozwoju – https://www.gov.pl/web/ncbr
