Słowniczek programistyczny

(ang. robal, pluskwa) - błąd w kodzie programu powodujący, że aplikacja nie działa w sposób zamierzony. Np. zwraca inne dane niż powinna lub wywala się.

Ciekawostka:
Nazwa "bug" wzięła się z początków komputerów, gdy były jeszcze wielkimi szafami wypełnionymi lampami elektronowymi. Czasem dostawały się do nich pluskwy lub inne żyjątka, które powodowały zwarcia i komputer przestawał działać.

(odpluskwiacz) – narzędzie programistyczne pomagające programiście na zlokalizowanie błędów (bugów) w programie. Debuggery umożliwiają zatrzymanie wykonywania programu w określonych punktach (breakpoint), badanie jego stanu i wykonywanie programu krok po kroku.

przeniesienie kodu źródłowego z zewnętrznego systemu kontroli wersji (np. Git) na serwer produkcyjny, gdzie będzie on dostępny dla użytkowników.

Deployowanie może być trudnym i czasochłonnym procesem, a błędy podczas wdrażania kodu mogą prowadzić do poważnych problemów z wydajnością i stabilnością aplikacji. Dlatego programiści często korzystają z narzędzi, takich jak systemy zarządzania konfiguracją (np. Ansible, Chef), systemy kontroli wersji (np. Git), platformy do ciągłej integracji (CI - continous integration) i dostarczania (np. Jenkins, GitLab CI/CD) i innych, które ułatwiają proces deployowania.

(ang. Don’t Repeat Yourself) – jedna z zasad programowania, która mówi żeby nie powtarzać fragmentu swojego kodu lub kodu podobnego. Jeśli jakiś fragment kodu pojawia się kilka razy w aplikacji powinno się z niego zrobić metodę/funkcję.

Zasada DRY ułatwia i przyspiesza pracę programisty. Jeśli jakiś fragment kodu musi zostać zmieniony i występuje kilka razy w aplikacji, mogłoby nie być możliwe odnalezienie wszystkich jego wystąpień. Przez co część aplikacji mogłaby działać niepoprawnie. Stosując zasadę DRY, zmiany robimy zazwyczaj w jednym miejscu.

(ang. Integrated Development Enviroment) – zintegrowane środowisko programistyczne. Jest to aplikacja, która zawiera w sobie (lub komunikuje się) wszystkie niezbędne usługi/programy potrzebne, żeby z kodu źródłowego powstał działający program.

IDE zawiera takie elementy jak edytor kodu (notatnik na wypasie), debugger, linker, kompilator i inne. Przy czym linker i kompilator często są osobnymi aplikacjami, ale zarządzanymi z poziomu IDE.

Takim IDE jest np. Visual Studio.

(ang. Keep It Simple Stupid) – jedna z zasad programowania, która mówi, żeby pisać w jak najprostszy sposób. Chodzi o to, żeby sztucznie nie wymyślać dziwnych mechanizmów, gdy można jakiś problem rozwiązać bardzo prosto.

Oczywiście w rzeczywistości może okazać się, że bardziej skomplikowany mechanizm będzie lepszym rozwiązaniem, bo dzięki niemu późniejsze zmiany będą dużo szybsze w implementacji.

struktura danych, reprezentująca obiekty i ich atrybuty w programie. Mówi się, że „klasa jest szablonem dla obiektu”. Wyobraź sobie, że tworzysz telewizor. Klasa byłaby wtedy schematem telewizora, natomiast faktycznie działające urządzenie będzie obiektem tej klasy.

Klasy są podstawowym elementem programowania obiektowego, co oznacza, że programiści mogą tworzyć obiekty zdefiniowane przez klasy, a następnie korzystać z ich metod i atrybutów do manipulowania danymi w programie.

podstawowe narzędzie w programowaniu, które umożliwia programistom skuteczne i bezpieczne zarządzanie kodem źródłowym projektu.

Pozwala na śledzenie zmian, przywracanie lub podglądanie starszych wersji kodu, a także ułatwia pracę w zespołach programistów.

Najbardziej popularnymi systemami kontroli wersji są GIT i SVN

model można rozumieć na wiele różnych sposobów w zależności od kontektu. Generalnie jest to jakaś reprezentacja rzeczywistego problemu. Przykładowym modelem może być klasa Person, która przechowuje dane osoby z bazy danych.

Modelem może być również diagram UML, przepływu danych itd.

Modele ułatwiają tworzenie aplikacji a także komunikację między programistami a „światem zewnętrznym” – np. zleceniodawcą (mówimy wtedy o modelu domenowym).

(dosłownie "test dymowy") to rodzaj testu oprogramowania, który ma na celu szybkie sprawdzenie, czy najważniejsze funkcje systemu działają poprawnie po wprowadzeniu jakieś zmiany lub aktualizacji. W ramach smoke testu testowane są zwykle tylko podstawowe scenariusze użycia, które są kluczowe dla użytkowników systemu. Testując te scenariusze, testerzy mają za zadanie zweryfikować, czy system uruchamia się i działa poprawnie oraz czy nie ma żadnych błędów krytycznych.

skrót od pięciu zasad projektowania oprogramowania, mających na celu zwiększenie czytelności, elastyczności i łatwości utrzymania kodu.

S – Zasada jednej odpowiedzialności (Single Responsibility Principle) – Klasa powinna mieć tylko jeden powód do zmiany. Oznacza to, że klasa powinna być odpowiedzialna tylko za jedną rzecz i nie powinna mieć wielu funkcjonalności.

O – Zasada otwarte-zamknięte (Open-Closed Principle) – Kod powinien być otwarty na rozszerzenia, ale zamknięty na modyfikacje. Oznacza to, że istniejące klasy i funkcje nie powinny być zmieniane, aby dodać nową funkcjonalność. Zamiast tego powinno się je rozszerzać przez dodanie nowych klas lub funkcji.

L – Zasada podstawienia Liskov (Liskov Substitution Principle) – Klasa dziedzicząca powinna być w stanie zastąpić klasę bazową bez wpływu na poprawność działania programu. Oznacza to, że klasa dziedzicząca powinna mieć taki sam interfejs jak klasa bazowa, ale może mieć różne implementacje.

I – Zasada segregacji interfejsów (Interface Segregation Principle) – Klient powinien być zależny tylko od tych części interfejsu, których potrzebuje. Oznacza to, że interfejsy powinny być małe i sprecyzowane, aby klienci mogli korzystać tylko z tych części, które potrzebują.

D – Zasada odwrócenia zależności (Dependency Inversion Principle) – Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu, a oba powinny zależeć od abstrakcji. Oznacza to, że zależności między modułami powinny być oparte na interfejsach lub abstrakcyjnych klasach, a nie na konkretnej implementacji.

okres trwający zwykle od jednego do czterech tygodni, podczas którego zespół pracuje nad wybranymi zadaniami lub funkcjonalnościami systemu. Sprinty są częścią metodyki Agile.

Na początku sprintu zespół zazwyczaj planuje, co chce w danym sprincie osiągnąć i jakie zmiany w oprogramowaniu wprowadzić. Na końcu sprintu zespół przeprowadza retrospektywę, aby omówić, co zostało osiągnięte i jakie kroki należy podjąć w celu poprawy pracy w kolejnym sprincie. Po retrospekcji zespół przystępuje do kolejnego sprintu, w którym kontynuowane są prace nad projektem.

test jednostkowy. Fragment kodu, który automatycznie jest w stanie przetestować inny kod. Testy jednostkowe powinny testować najmniejsze publiczne części aplikacji (poszczególne metody/funkcje) pod różnymi warunkami. Zazwyczaj testy jednostkowe pisze się w taki sposób, żeby przekazać do testowanej metody wartość normalną, błędną i skrajną. W teście jednostkowym oczekujemy konkretnego działania testowanej metody – np. przy danych błędnych powinna zwrócić błąd lub wysypać się.

Podstawy testów jednostkowych opisałem w tym artykule.

to skrót od dwóch oddzielnych, ale ze sobą powiązanych dziedzin: User Experience (UX) oraz User Interface (UI).

User Experience (UX) odnosi się do doświadczeń użytkowników, jakie mają podczas interakcji z aplikacją lub stroną internetową. Mogą przeprowadzać rozmowy z użytkownikami aby dowiedzieć się, czy aplikacja jest dla nich łatwa w obsłudze, ewentualnie z czym mają problem. Następnie proponują alternatywne rozwiązania.

User Interface (UI) to projektowanie interfejsów, czyli konkretnych elementów z którymi użytkownik wchodzi w interakcje. UI designerzy zajmują się tworzeniem layoutu, kolorów, typografii, ikon, przycisków i innych elementów interfejsu, które umożliwiają użytkownikowi interakcję z aplikacją. Celem UI jest stworzenie spójnego, atrakcyjnego i łatwego do zrozumienia interfejsu, który przyciągnie uwagę użytkownika i ułatwi mu korzystanie z aplikacji.

UX/UI designerzy współpracują ze sobą w celu zaprojektowania aplikacji, która będzie łatwa w użyciu i estetycznie przyjemna dla użytkownika. UX i UI odgrywają kluczową rolę w procesie tworzenia aplikacji i są ważne dla sukcesu aplikacji, ponieważ wpływają na to, czy użytkownik będzie zadowolony z doświadczenia, jakie uzyska podczas korzystania z aplikacji.

(ang. HTTP request) to wiadomość wysyłana przez klienta (np. przeglądarkę internetową) do serwera w celu uzyskania zasobu, takiego jak dokument HTML, obrazek lub plik.

Żądanie HTTP zawiera informacje o zasobie, który jest żądany, oraz inne dane, takie jak nagłówki HTTP i ciało żądania.

Przykładowo po wpisaniu do przeglądarki adresu: „https://masterbranch.pl”, przeglądarka tworzy specjalną standaryzowaną wiadomość tekstową („cześć masterbranch.pl, prześlij mi proszę stronę główną twojego serwisu), którą wysyła do serwera. Serwer odczytuje ją i zwraca odpowiedź.

W odpowiedzi może być żądany zasób (np. strona www), błąd lub inne informacje.

Technicznie żądanie HTTP składa się z 3 elementów:

• metoda – mówi, czy chcemy dane pobrać, wysłać, usunąć, zaktualizować itd.


• URI – adres serwera, do któego chcemy wysłać wiadomość


• nagłówki