Head First Software Development. Edycja polska

Spis treści
Wprowadzenie
Dla kogo przeznaczona jest ta książka?
Wiemy, co sobie myślisz
Metapoznanie: myślenie o myśleniu
A oto, co TY możesz zrobić, aby zmusić mózg do posłuszeństwa
Przeczytaj koniecznie
Zespół recenzentów technicznych
Podziękowania
1. Zapewnianie zadowolenia klientów
Szlakami Macieja wchodzi do internetu
W większości projektów trzeba uwzględnić dwa główne zagadnienia
Rozwój oprogramowania metodą wielkiego wybuchu
Przenieśmy się w czasie — dwa tygodnie później
Rozwój oprogramowania metodą wielkiego wybuchu kończy się zwykle WIELKIMI PROBLEMAMI
Doskonały rozwój oprogramowania polega na…
Dochodzenie do celu dzięki ITERACJOM
Każda iteracja to miniprojekt
Każda iteracja prowadzi do rozwoju oprogramowania o WYSOKIEJ JAKOŚCI
Klient BĘDZIE zmieniał zdanie
Wprowadzenie poprawek to Twoje zadanie
Musisz poradzić sobie z POWAŻNYMI problemami…
Iteracje automatycznie uwzględniają zmiany
Oprogramowanie jest gotowe dopiero w momencie jego UDOSTĘPNIENIA
Narzędzia do Twojej programistycznej skrzynki narzędziowej
2. Określanie potrzeb klientów
Orbity Oriona przystępują do modernizacji
Porozmawiaj z klientem, aby uzyskać WIĘCEJ informacji
W obłokach z klientem
Czasem sesje bujania w obłokach wyglądają tak jak na rysunku…
Dowiedz się, co użytkownicy NAPRAWDĘ robią
Wymagania muszą być zorientowane na KLIENTA
Rozwijaj wymagania na podstawie informacji zwrotnych od klienta
Opowieści użytkownika opisują, CO należy zrealizować w projekcie… a szacunki określają, KIEDY należy to zrobić
Rozmowa przy stanowisku pracy
Gra w pokera planistycznego
Osądź zasadność założeń
DŁUGIE w realizacji opowieści użytkownika to ZŁE opowieści użytkownika
Celem jest zbieżność
Cykl przechodzenia od wymagań do szacunków
Na zakończenie można oszacować czas trwania całego projektu
Narzędzia do Twojej programistycznej skrzynki narzędziowej
3. Planowanie z myślą o sukcesie
Klienci chcą otrzymać oprogramowanie OD RAZU!
Określanie priorytetów razem z klientem
Wiemy, co znajdzie się w wydaniu 1.0 (prawdopodobnie)
Jeśli szacowany czas jest za długi, zmień priorytety
Im więcej osób, tym mniej korzyści
Dochodzenie do rozsądnego wydania 1.0
Iteracje powinny być krótkie i przyjemne
Porównywanie planu z rzeczywistością
Szybkość uwzględnia niespodziewane wydarzenia
Programiści myślą w kategoriach dni UTOPIJNYCH
Twórcy oprogramowania myślą w kategoriach dni REALNYCH
Co zrobić, jeśli iteracja jest za długa?
Uwzględnij szybkość PRZED zaplanowaniem iteracji
Czas na dokonanie oceny
Radzenie sobie z (wkurzonymi) klientami
Duża tablica na ścianie
Jak zrujnować życie osobiste członków zespołu?
Narzędzia do Twojej programistycznej skrzynki narzędziowej
4. Przystępowanie do prawdziwej pracy
Poznajemy iSwoon
Łączny czas realizacji zadań
Uwzględniaj tylko niewykonane zadania
Umieszczanie zadań na tablicy
Rozpoczynanie pracy nad zadaniami
Zadanie jest w toku tylko wtedy, kiedy jest W TOKU
Co zrobić, jeśli pracuję jednocześnie nad dwoma zadaniami?
Pierwsze spotkanie „na stojaka”
Zadanie 1: utworzenie klasy Date
Krótkie spotkanie robocze: dzień 5, koniec tygodnia 1
Krótkie spotkanie robocze: dzień 2, tydzień 2
Przerywamy ten rozdział…
Musisz kontrolować niezaplanowane zadania
Nieoczekiwane prace podwyższają poziom zadań do wykonania
Szybkość pomaga, ale…
Mamy dużo do zrobienia…
…jednak DOKŁADNIE wiemy, na czym stoimy
Wszystko o Szybkości
5. Tworzenie oprogramowania na podstawie doskonałych projektów
Zespół pracujący nad iSwoon ma poważne problemy
Taki projekt narusza zasadę jednego zadania
Wykrywanie wielu obowiązków w projekcie
Przechodzenie od wielu obowiązków do jednego zadania
Projekt powinien być zgodny z SRP, a także z zasadą DRY
Krótkie spotkanie robocze po zakończeniu refaktoryzacji
Niezaplanowane zadania to wciąż zadania
Częścią Twojego zadania jest przeprowadzenie prezentacji
Kiedy wszystko jest gotowe, iteracja jest ukończona
6. Programowanie defensywne
Podpisałeś nowy kontrakt na aplikację MuzMachina Pro
Praca nad interfejsem GUI
Demonstracja nowej MuzMachiny klientowi
Zacznijmy od KONTROLI WERSJI
Najpierw skonfiguruj projekt…
…teraz możesz przesyłać i pobierać kod
Większość narzędzi do kontroli wersji próbuje rozwiązywać problemy za Ciebie
Serwer próbuje SCALIĆ zmiany
Jeśli system nie potrafi scalić zmian, informuje o konflikcie
Następne iteracje, następne opowieści
Mamy kilka wersji oprogramowania
Opisowe komentarze dodane przy przesyłaniu ułatwiają znalezienie starszego oprogramowania
Teraz możesz pobrać wersję 1.0
(Awaryjne) krótkie spotkanie robocze
Oznaczanie wersji
Oznaczenia, gałęzie, pnie — co jeszcze?
Poprawianie wersji 1.0 — tym razem na poważnie
Teraz mamy DWIE wersje kodu bazowego
Kiedy NIE należy tworzyć gałęzi?
Zen poprawnego rozgałęziania
Co zapewnia system kontroli wersji...
System kontroli wersji nie może sprawdzić, czy kod działa
Narzędzia do Twojej programistycznej skrzynki narzędziowej
6.5. Wstaw element a w pole b…
Programiści nie potrafią czytać w myślach
Budowanie projektu w jednym kroku
Ant — narzędzie do budowania projektów w języku Java
Projekty, właściwości, cele i zadania
Dobre skrypty kompilacji…
Dobre skrypty kompilacji wykraczają POZA podstawy
Skrypty kompilacji to też kod
Nowy, weź dwójkę
Narzędzia do Twojej programistycznej skrzynki narzędziowej
7. Pojawiają się problemy
ZAWSZE coś pójdzie źle
Są trzy sposoby postrzegania systemu
Testy czarnej skrzynki dotyczą przede wszystkim danych WEJŚCIOWYCH i WYJŚCIOWYCH
Testy szarej skrzynki ZBLIŻAJĄ Cię do kodu
Testy białej skrzynki wymagają wiedzy o wnętrzu systemu
Testowanie WSZYSTKIEGO w jednym kroku
Automatyzacja testów przy użyciu platformy testowej
Używanie platformy do uruchamiania testów
Sterowanie CI za pomocą narzędzia CruiseControl
Testy gwarantują działanie programu, prawda?
Przetestowanie całego kodu wymaga sprawdzenia KAŻDEJ GAŁĘZI
Użyj raportu pokrycia, aby zobaczyć, które metody są sprawdzane
Uzyskanie wysokiego pokrycia kodu nie zawsze jest proste
Krótkie spotkanie robocze
Narzędzia do Twojej programistycznej skrzynki narzędziowej
8. Zapewnianie poprawności kodu
Pisz testy NA POCZĄTKU, a nie na końcu
NAJPIERW testy
Witamy w świecie wytwarzania sterowanego testami
Pierwszy test…
…kończy się całkowitym niepowodzeniem.
Doprowadź testy do koloru ZIELONEGO
Czerwone, zielone, refaktoryzacja…
W TDD testy STERUJĄ rozwojem kodu
Ukończenie zadania oznacza, że napisałeś wszystkie potrzebne testy i kończą się one sukcesem
Kiedy kod przejdzie testy, idź dalej!
Prostota oznacza unikanie zależności
Zawsze pisz kod, który można przetestować
Kiedy wystąpią trudności, przyjrzyj się projektowi
Wzorzec strategii pozwala tworzyć wiele wersji jednego interfejsu
Przechowuj kod testowy razem z testami
Testy prowadzą do powstania lepszego kodu
Więcej testów zawsze oznacza więcej kodu
Wzorce strategii, luźne powiązanie, zastępowanie obiektów
Potrzebujemy wielu odmiennych, choć podobnych obiektów
A gdyby tak wygenerować obiekty?
Obiekty zastępcze zastępują prawdziwe obiekty
Obiekty zastępcze to działające zastępniki obiektów
Dobre oprogramowanie można przetestować
Niełatwo być zielonym
Dzień z życia programisty stosującego TDD
Narzędzia do Twojej programistycznej skrzynki narzędziowej
9. Wszystkie elementy łączą się ze sobą…
Iteracja jest prawie ukończona…
…jednak możesz zrobić jeszcze wiele rzeczy
Krótkie spotkanie robocze
TRZEBA przeprowadzić testy systemu…
…ale KTO ma to zrobić?
Testy systemu wymagają kompletnego oprogramowania
Dobre testy systemu wymagają DWÓCH cykli iteracji
Więcej iteracji oznacza dodatkowe problemy
Życie (i śmierć) błędu
Znalazłeś błąd i co dalej?
Anatomia raportu o błędzie
Jest jeszcze wiele rzeczy, które MÓGŁBYŚ zrobić…
Czas na przegląd iteracji
Przykładowe pytania z przeglądu iteracji
OGÓLNA lista priorytetów zadań DODATKOWYCH
Narzędzia do Twojej programistycznej skrzynki narzędziowej
10. Jeśli nie jest zepsute… i tak lepiej to naprawić
Czym jest działające oprogramowanie?
Potrzebujesz planu następnej iteracji
Szybkość pozwala uwzględnić… RZECZYWISTOŚĆ BIZNESOWĄ
Klient NADAL jest najważniejszy
Oprogramowanie innych zespołów to NADAL tylko oprogramowanie
Akceptacja klienta? Jest!
Testowanie kodu
Houston, mamy problem…
Krótkie spotkanie robocze
Nie ufaj NIKOMU
Zespół bez procesu
Zespół z procesem
11. Profesjonalne usuwanie błędów
W poprzednim odcinku
Najpierw musisz porozmawiać z klientem
Pierwszy priorytet: umożliwienie zbudowania oprogramowania
Moglibyśmy naprawić kod…
…ale trzeba naprawić funkcje systemu
Określ, które funkcje działają
TERAZ wiesz, co (nie) działa
Co zrobiłbyś w tej sytuacji?
Oszacuj czas pracy przy użyciu testów punktowych
O czym informują Cię wyniki testów punktowych?
Intuicja członków zespołu ma znaczenie
Poinformuj klienta o szacunkowym czasie naprawy błędów
Sytuacja wygląda dobrze…
…i kończysz iterację sukcesem!
I klient jest zadowolony
Narzędzia do Twojej programistycznej skrzynki narzędziowej
12. Proces w praktyce
Definiowanie procesu rozwoju oprogramowania
Dobry proces prowadzi do dobrego oprogramowania
Wymagany jest strój wieczorowy
Wybrane materiały dodatkowe
Więcej wiedzy == lepszy proces
Narzędzia do Twojej programistycznej skrzynki narzędziowej
A. Pięć najważniejszych tematów
Numer 1. Diagramy klas w notacji UML
Numer 2. Diagramy sekwencji
Numer 3. Opowieści użytkownika i przypadki użycia
Numer 4. Testy systemu a testy jednostkowe
Numer 5. Refaktoryzacja
B. Narzędzia dla doświadczonych programistów
Techniki rozwoju
Zasady rozwoju
Skorowidz