Słowniczek programistyczny
There are currently 3 names in this directory beginning with the letter S.
Smoke test
(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.
SOLID
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.
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.
Sprint
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.
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.
Submit a name