Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński

Transkrypt

1 Wskazówki projektowe Programowanie Obiektowe Mateusz Cicheński

2 Przydatne zasady SOLID Wzorce struktury aplikacji MVC MVP MVVM Metody wytwarzania oprogramowania Manifest Zwinnego Wytwarzania Oprogramowania Scrum TDD Przydatne odnośniki Plan zajęć

3 S O L I D RP CP SP SP IP Przydatne zasady

4 S O L I D RP CP SP SP IP Każda klasa jest odpowiedzialna za jedną rzecz. vs Single responsibility principle

5 S O L I D RP CP SP SP IP Klasa jest otwarta na rozszerzenia, ale zamknięta na modyfikacje. Open/closed principle

6 S O L I D RP CP SP SP IP Jeśli klasa S jest podklasą T, to obiekty klasy T mogą być podmienione przez obiekty klasy S bez wpływu na działanie aplikacji. vs Liskov substitution principle

7 S O L I D RP CP SP SP IP Interfejsy powinny definiować minimalny zbiór metod zapewniających spójną funkcjonalność. vs Interface segregation principle

8 S O L I D RP CP SP SP IP 1. Moduły wysoko-poziomowe nie powinny zależeć od modułów niskopoziomowych. Jedne i drugie powinny bazować na abstrakcji. 2. Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. Szczegółowe rozwiązania powinny zależeć od abstrakcji. Dependency inversion principle

9 Jeśli w jednym pokoju spotka się 10 architektów aplikacji i każesz im omówić 1 wybrany wzorzec struktury aplikacji, to choćbyś nie wiem jak się starał uzyskasz 12 różnych definicji 10 x 1 = 12 matematyka architektów aplikacji Wzorce struktury aplikacji

10 APLIKACJA jest widoczne dla używa Użytkownik Najprościej i bez pomysłu

11 MODEL WIDOK zarządza KONTROLER Użytkownik Model View Controller

12 Użytkownik jest widoczne dla wchodzi w interakcje WIDOK przekazuje interakcje aktualizuje PREZENTER MODEL używa Model View Presenter

13 MODEL WIDOKU WIDOK MODEL Użytkownik Model View ViewModel

14 Ułatwiają pracę w zespole Umożliwiają kontrolę postępów pracy Organizują pracę zespołu Realizują wszystkie etapy związane z wytwarzaniem aplikacji, tj.: Zebranie wymagań Projekt aplikacji Implementacja Testowanie Wytworzenie produktu finalnego Metody wytwarzania oprogramowania

15 Ludzie i ich wzajemne interakcje (współdziałanie) ponad procedury i narzędzia. Działające oprogramowanie nad wyczerpującą dokumentację. Współpraca z klientem nad negocjację umów. Reagowanie na zmiany ponad realizowanie planu. Manifest Agile

16 Role: zespół, klient, scrum master Product Backlog = spis wymagań w postaci historyjek (INVEST independent, negotiable, valuable, estimable, small and testable) Sprint Backlog = lista wymagań uwzględnionych w danym przyroście (sprincie) Sprint = przedział czasowy, w ramach którego powinien powstać nowy produkt realizujący wybrane funkcjonalności (zazwyczaj to 2 do 4 tygodni) Scrum

17 Spotkanie dzienne Ograniczone czasowo (max 15 minut) Obecność całego zespołu Co zostało zrobione wczoraj, co zostanie zrobione dzisiaj, czy wystąpiły jakieś problemy? Przygotowanie Backlogu Ograniczone czasowo (max 1 godzina) Służy analizie historii i ich ewentualnemu podziałowi na mniejsze historie Planowanie sprintu Ograniczone czasowo (max 8 godzin) Wybranie historii z Backlogu = utworzenie Sprint Backlogu z uwzględnieniem czasu wykonania zadań Scrum c.d.

18 Podsumowanie sprintu Określenie co zostało zrobione, a co nie Przedstawienie nowej wersji oprogramowania klientowi Spotkanie retrospektywne Co poszło dobrze/sprawnie w poprzednim sprincie? Co może zostać poprawione przy realizacji kolejnego sprintu? Scrum c.d.

19 Etap 1: sformułowanie funkcjonalności w postaci testu jednostkowego Etap 2: upewnienie się, że test zakończy się niepowodzeniem Etap 3: implementacja nowej funkcjonalności Etap 4: upewnienie się, że test zakończy się powodzeniem Etap 5: refaktoryzacja kodu Etap 6: wróć do Etapu 1 Test Driven Development

20 Struktura dobrego testu: 1. przygotowanie systemu 2. uruchomienie testu 3. walidacja rezultatów 4. posprzątanie po sobie Testy powinny być niezależne od siebie! Testy powinny być powtarzalne! Nie oczekuj dokładnych wyników dla testów wydajności lub czasu wykonania Testując wartości zależne od zewnętrznych czynników uwzględnij pewien margines błędu (np. przy pomiarze czasu) Porównuj tylko wartości istotne dla danego testu TDD dobre praktyki

21 TDD SVN Bug tracker Projektowanie obiektowe ansowane_projektowanie_obiektowe Przydatne odnośniki