Słownik pojęć programistycznych

Metoda wytwarzania oprogramowania, w których kolejne poszczególne funkcje aplikacji dostarczane są co jakiś czas. Zakłada częsty kontakt z klientem i reagowanie na pojawiające się zmiany.

Sposób wytwarzania oprogramowania, który łączy w sobie zasady TDD (rozpoczęcie od napisania testu) i podejście DDD (nacisk na jak najwierniejsze odwzorowanie rzeczywistości).

W tym podejściu, aplikacja rozwijana jest na podstawie wymagań użytkownika w formie tzw. user stories, które opisują w jaki sposób aplikacja powinna się zachować w konkretnych sytuacjach.

Opiera się na schemacie given, when, then. Przykład poniżej.

Given: będąc na stronie internetowej portalu aukcyjnego
When: po wpisaniu nazwy przedmiotu w wyszukiwarkę
Then: powinienem otrzymać listę aukcji oferujących szukany przedmiot

Potoczne określenie błędu występującego w aplikacji, który uniemożliwia lub powoduje problemy w jej działaniu.

To praktyka polegająca na przekazaniu napisanego przez siebie kodu do oceny przed innego członka zespołu.

Pozwala to w dużej mierze na wykrycie i poprawienie ewentualnych błędów przed wprowadzeniem zmian do aplikacji, zachowanie dobrej jakości kodu i stanowi dobre wskazówki dla obydwu stron.

Jedna z dobrych praktyk programowania, która mówi o tym, aby nie powielać kodu, który realizuje te same funkcje. Założeniem jest tworzenie kodu, który napisany raz będzie mógł zostać użyty wielokrotnie przez różne części aplikacji.

To podejście do tworzenia oprogramowania, w którym nacisk kładziony jest na jak najwierniejsze odzwierciedlenie procesów, rzeczywistości, założeń biznesowych w implementacji.

To platforma programistyczna służąca do budowy aplikacji. Definiuje powstawanie aplikacji pewnym w ustalonym modelu i dostarcza wielu gotowych rozwiązań i udogodnień, przez co ułatwia tworzenie aplikacji.

Zasada wywodząca się z TDD. Definiuje pięć cech jakie powinny posiadać testy jednostkowe.

F (Fast) - powinny być szybkie. Od momentu uruchomienia testu do jego zakończenia nie powinna upłynąć więcej niż jedna sekunda.

I (Independent) - powinny być niezależne. Każdy test powinien dać się uruchomić w dowolnej kolejności.

R (Repeatable) - powinny być powtarzalne. Uruchomienie tego samego testu wiele razy za każdym razem powinno dać ten sam wynik.

S (Self-Checking) - powinny być samo sprawdzające. Wynik testu powinien być określony automatycznie, bez konieczności jego interpretacji.

T (Timely) - powinny być pisane w tym samym czasie co kod aplikacji, przed wdrożeniem na środowisko produkcyjne.

To graficzny interfejs, który pozwala na komunikację użytkownika z system komputerowym. Najczęściej obsługiwany jest myszką lub dotykiem.

Hipertekstowy język znaczników służący do tworzenia dokumentów, które są ze sobą połączone hiperłączami. Zawiera wiele znaczników np. znacznik B określający, że tekst ma być wytłuszczony. Jego najpopularniejsze zastosowanie to tworzenie stron WWW.

HTML nie jest językiem programowania.

Jest to aplikacja służąca tworzenia oprogramowania, np. NetBeans, Eclipse, IntellIJ.

Jest to framework służący do tworzenia testów jednostkowych w języku Java.

Dobra praktyka programowania mówiąca o tym, aby unikać zbędnych komplikacji w kodzie, tak aby był możliwe jak najprostszy, dający się łatwo przeanalizować i łatwo zrozumieć.

To metoda wykorzystywana w zarządzaniu projektami kategoryzująca priorytety wymagań.

M (MUST) - opisuje wymagania, które muszą zostać dostarczone
S (SHOULD) - opisuje wymagania, które jeśli to możliwe powinny zostać dostarczone
C (COULD) - opisuje wymagania, które nie są krytyczne, ale byłoby dobrze jeśli zostałyby dostarczone
W (WON'T) - opisuje wymagania, które za zgodą klienta mogą zostać dostarczone w przyszłości

Obiektowy język programowania. Polega na tworzeniu obiektów i wywoływaniu metod, tak współdziałały ze sobą. Przykładowe języki: C#, Java, Python.

Sposób odwzorowywania obiektów i powiązań między nimi na tabele i relacje istniejące w bazie danych.

Polega na podziale treści i umieszczenie jej na kolejnych stronach. Często spotykane rozwiązanie w przypadku sklepów internetowych gdzie kolejne produkty w danej kategorii umieszczane są na kolejnych stronach w celu poprawienia czytelności i uniknięcia długiego czasu wczytywania.

Zasada ta dopuszcza w uzasadnionych przyczynach, posiadanie w aplikacji tego samego kodu w maksymalnie dwóch miejscach. Jeśli jednak ten sam kod wystąpi w 3 miejscach należy zastosować regułę DRY.

To pojęcie odnoszące się do dobrych praktyk tworzenia oprogramowania. Składa się z pięciu zasad.

S - zasada pojedynczej odpowiedzialności (ang. Single-Responsibility Principle – SRP)
Zasada mówiąca o tym, że jedna klasa powinna odpowiadać tylko za jedną funkcjonalność, realizować jeden cel.

O - zasada otwarte-zamknięte (ang. Open/Closed Principle – OCP)

Zasada mówiąca o tym, że poszczególne elementy aplikacji powinny być otwarte na rozbudowę, ale zamknięte na modyfikacje. Chodzi o to, żeby daną funkcjonalność programu dało się rozbudować bez modyfikacji istniejącego kodu.

L - zasada podstawiania Liskov (ang. Liskov Substitution Principle – LSP)
Definicja wygląda następująco: funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów. W praktyce sprowadza się ona do właściwego wykorzystania dziedziczenia i polimorfizmu.

I - zasada segregacji interfejsów (ang. Interface Segregation Principle – ISP)
Zasada mówiąca o tym, że interfejsy powinny dostarczać tylko takich funkcjonalności jakich potrzebuje implementująca go klasa. Lepiej stworzyć kilka mniejszych interfejsów niż jeden ogólny.

D - zasada odwracania zależności (ang. Dependency Inversion Principle – DIP)
Zasada mówi, że wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych – zależności między nimi powinny wynikać z abstrakcji. Upraszczając, mówi ona o tym, aby w jak największym stopniu wykorzystywać klasy abstrakcyjne i interfejsy, a nie uzależniać klas od konkretnych implementacji.

To sposób testowania całej konkretnej funkcjonalności programu. Test integracyjny sprawdza czy zależności pomiędzy poszczególnymi fragmentami aplikacji są prawidłowe i czy końcowy wynik działania jest taki jak oczekiwano.

To sposób testowania małego fragmentu aplikacji np. metody, w celu sprawdzenia czy działa ona w zakładany sposób.

Sposób tworzenia oprogramowania, w którym pisanie kodu zaczyna się najpierw od napisania testu jednostkowego danej funkcjonalności, a następnie napisanie implementacji tej funkcjonalności.

Jest językiem, za pomocą którego można stworzyć graficzny, bazujący na diagramach model systemu, procesu, aplikacji i jej funkcji. Używa się go również w celach dokumentacyjnych.

Przykładowy diagram UML

Jest to całość wrażeń, jakich doświadcza użytkownik podczas korzystania z produktu.

Jest to wirtualny serwer, który powstał w wyniku podziału fizycznego serwera na kilka części.

Zbiór uniwersalnych, łatwych do utrzymania i sprawdzonych w praktyce rozwiązań w programowaniu obiektowym dla często pojawiających się, powtarzalnych problemów projektowych.

Zbiór zasad dotyczących programowania w sytuacji gdy założenia aplikacji nie są do końca znane i nie można przewidzieć ich finalnego kształtu.

Dobra praktyka programowania mówiąca o tym, żeby nie tworzyć nadmiarowego kodu, który nie wiemy czy będzie przydatny w przyszłości. Chodzi tutaj też o usuwanie z aplikacji kodu, którego już nie potrzebujemy i nie dołączanie do programu zbędnych zależności.