Pobierz fragment
Pobierz fragment w jednym z dostępnych formatów
Head First Software Development. Edycja polska - ebook
Format ebooka:
PDF
Format
PDF
czytaj
na laptopie
czytaj
na tablecie
Format e-booków, który możesz odczytywać na tablecie oraz
laptopie. Pliki PDF są odczytywane również przez czytniki i smartfony,
jednakze względu na komfort czytania i brak możliwości skalowania
czcionki, czytanie plików PDF na tych urządzeniach może być męczące dla
oczu. Więcej informacji znajdziesz w dziale Pomoc.
czytaj
na laptopie
Pliki PDF zabezpieczone watermarkiem możesz odczytać na dowolnym
laptopie po zainstalowaniu czytnika dokumentów PDF. Najpowszechniejszym
programem, który umożliwi odczytanie pliku PDF na laptopie, jest Adobe
Reader. W zależności od potrzeb, możesz zainstalować również inny
program - e-booki PDF pod względem sposobu odczytywania nie różnią
niczym od powszechnie stosowanych dokumentów PDF, które odczytujemy
każdego dnia.
Informacje na temat zabezpieczenia e-booka znajdziesz na karcie produktu
w "Szczegółach na temat e-booka". Więcej informacji znajdziesz w dziale
Pomoc.
czytaj
na tablecie
Aby odczytywać e-booki na swoim tablecie musisz zainstalować specjalną
aplikację. W zależności od formatu e-booka oraz systemu operacyjnego,
który jest zainstalowany na Twoim urządzeniu może to być np. Bluefire
dla EPUBa lub aplikacja Kindle dla formatu MOBI.
Informacje na temat zabezpieczenia e-booka znajdziesz na karcie produktu
w "Szczegółach na temat e-booka". Więcej informacji znajdziesz w dziale
Pomoc.
Pobierz fragment
Pobierz fragment w jednym z dostępnych formatów
Head First Software Development. Edycja polska - ebook
Opanuj niezwykłą sztukę wytwarzania oprogramowania!
- W jaki sposób zadowolić klienta?
- Jak wygląda proces wytwarzania oprogramowania?
- Jakie pułapki czekają na Ciebie?
Proces wytwarzania oprogramowania -- już sam opis sugeruje trudności. I rzeczywiście -- jest to proces niezwykle złożony. Od samego początku trafiamy na kwestie takie, jak analiza potrzeb klienta i zebranie jego wymagań. Z każdym krokiem wszystko komplikuje się jeszcze bardziej... Konieczna jest implementacja poszczególnych wymagań klienta, testowanie tych rozwiązań, korekta znalezionych błędów. Na to wszystko nakłada się jeszcze konieczność tworzenia różnych wersji rozwiązań i zmienny nastrój klienta. Jak sobie z tym wszystkim poradzić? Jak bezboleśnie i skutecznie przejść przez cały ten proces?
Tylko bez obaw! Oto podręcznik, który dzięki innowacyjnym metodom przekazywania wiedzy sprawi, że szybko zrozumiesz proces wytwarzania oprogramowania i nauczysz się gładko podążać jego wyboistą ścieżką. Autorzy książki "Head First Software Development. Edycja polska" -- Dan i Russ -- pokażą Ci, w jaki sposób zadowolić klienta i zebrać od niego wymagania oraz określić jego potrzeby. Dowiesz się, jak zapanować nad poszczególnymi wersjami Twojego projektu. Nauczysz się prowadzić testy i usuwać błędy. Zdobędziesz informacje dotyczące wytwarzania oprogramowania sterowanego testami, a na koniec zobaczysz, jak taki proces wygląda w rzeczywistości. Wszystkie te informacje przedstawione zostały na licznych ilustracjach, co wydatnie ułatwia przyswajanie wiedzy, dodatkowo przekazanej przystępnym i pełnym humoru językiem. Po lekturze tego podręcznika nawet laik będzie w stanie zarządzać takim procesem!
- Zbieranie wymagań
- Planowanie projektu
- Kontrola wersji
- Wytwarzanie sterowane testami
- Testy integracyjne
- Usuwanie błędów
Tworzenie oprogramowania? Nic prostszego!!!
Spis treści
Wprowadzenie
- Dla kogo przeznaczona jest ta książka? (26)
- Wiemy, co sobie myślisz (27)
- Metapoznanie: myślenie o myśleniu (29)
- A oto, co TY możesz zrobić, aby zmusić mózg do posłuszeństwa (31)
- Przeczytaj koniecznie (32)
- Zespół recenzentów technicznych (34)
- Podziękowania (35)
Rozdział 1. Zapewnianie zadowolenia klienta
- Szlakami Macieja wchodzi do internetu (38)
- W większości projektów trzeba uwzględnić dwa główne zagadnienia (39)
- Rozwój oprogramowania metodą wielkiego wybuchu (40)
- Przenieśmy się w czasie - dwa tygodnie później (41)
- Rozwój oprogramowania metodą wielkiego wybuchu kończy się zwykle WIELKIMI PROBLEMAMI (42)
- Doskonały rozwój oprogramowania polega na... (45)
- Dochodzenie do celu dzięki ITERACJOM (46)
- Każda iteracja to miniprojekt (50)
- Każda iteracja prowadzi do rozwoju oprogramowania o WYSOKIEJ JAKOŚCI (50)
- Klient BĘDZIE zmieniał zdanie (56)
- Wprowadzenie poprawek to Twoje zadanie (56)
- Musisz poradzić sobie z POWAŻNYMI problemami... (56)
- Iteracje automatycznie uwzględniają zmiany (58)
- Oprogramowanie jest gotowe dopiero w momencie jego UDOSTĘPNIENIA (61)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (62)
Rozdział 2. Określanie potrzeb klientów
- Orbity Oriona przystępują do modernizacji (64)
- Porozmawiaj z klientem, aby uzyskać WIĘCEJ informacji (67)
- W obłokach z klientem (68)
- Czasem sesje bujania w obłokach wyglądają tak jak na rysunku... (70)
- Dowiedz się, co użytkownicy NAPRAWDĘ robią (71)
- Wymagania muszą być zorientowane na KLIENTA (73)
- Rozwijaj wymagania na podstawie informacji zwrotnych od klienta (75)
- Opowieści użytkownika opisują, CO należy zrealizować w projekcie... a szacunki określają, KIEDY należy to zrobić (77)
- Rozmowa przy stanowisku pracy (81)
- Gra w pokera planistycznego (82)
- Osądź zasadność założeń (85)
- DŁUGIE w realizacji opowieści użytkownika to ZŁE opowieści użytkownika (88)
- Celem jest zbieżność (91)
- Cykl przechodzenia od wymagań do szacunków (94)
- Na zakończenie można oszacować czas trwania całego projektu (97)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (99)
Rozdział 3. Planowanie z myślą o sukcesie
- Klienci chcą otrzymać oprogramowanie OD RAZU! (102)
- Określanie priorytetów razem z klientem (105)
- Wiemy, co znajdzie się w wydaniu 1.0 (prawdopodobnie) (106)
- Jeśli szacowany czas jest za długi, zmień priorytety (107)
- Im więcej osób, tym mniej korzyści (109)
- Dochodzenie do rozsądnego wydania 1.0 (110)
- Iteracje powinny być krótkie i przyjemne (117)
- Porównywanie planu z rzeczywistością (119)
- Szybkość uwzględnia niespodziewane wydarzenia (121)
- Programiści myślą w kategoriach dni UTOPIJNYCH (122)
- Twórcy oprogramowania myślą w kategoriach dni REALNYCH (123)
- Co zrobić, jeśli iteracja jest za długa? (124)
- Uwzględnij szybkość PRZED zaplanowaniem iteracji (125)
- Czas na dokonanie oceny (129)
- Radzenie sobie z wkurzonymi klientami (130)
- Duża tablica na ścianie (132)
- Jak zrujnować życie osobiste członków zespołu? (135)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (137)
Rozdział 4. Przystępowanie do prawdziwej pracy
- Poznajemy iSwoon (140)
- Łączny czas realizacji zadań (143)
- Uwzględniaj tylko niewykonane zadania (145)
- Umieszczanie zadań na tablicy (146)
- Rozpoczynanie pracy nad zadaniami (148)
- Zadanie jest w toku tylko wtedy, kiedy jest W TOKU (149)
- Co zrobić, jeśli pracuję jednocześnie nad dwoma zadaniami? (150)
- Pierwsze spotkanie "na stojaka" (153)
- Zadanie 1: utworzenie klasy Date (154)
- Krótkie spotkanie robocze: dzień 5, koniec tygodnia 1 (160)
- Krótkie spotkanie robocze: dzień 2, tydzień 2 (166)
- Przerywamy ten rozdział... (170)
- Musisz kontrolować niezaplanowane zadania (171)
- Nieoczekiwane prace podwyższają poziom zadań do wykonania (173)
- Szybkość pomaga, ale... (174)
- Mamy dużo do zrobienia... (176)
- ...jednak DOKŁADNIE wiemy, na czym stoimy (177)
- Wszystko o Szybkości (178)
Rozdział 5. Tworzenie oprogramowania na podstawie doskonałych projektów
- Zespół pracujący nad iSwoon ma poważne problemy (180)
- Taki projekt narusza zasadę jednego zadania (183)
- Wykrywanie wielu obowiązków w projekcie (186)
- Przechodzenie od wielu obowiązków do jednego zadania (189)
- Projekt powinien być zgodny z SRP, a także z zasadą DRY (190)
- Krótkie spotkanie robocze po zakończeniu refaktoryzacji (194)
- Niezaplanowane zadania to wciąż zadania (196)
- Częścią Twojego zadania jest przeprowadzenie prezentacji (197)
- Kiedy wszystko jest gotowe, iteracja jest ukończona (200)
Rozdział 6. Programowanie defensywne
- Podpisałeś nowy kontrakt na aplikację MuzMachina Pro (206)
- Praca nad interfejsem GUI (210)
- Demonstracja nowej MuzMachiny klientowi (213)
- Zacznijmy od KONTROLI WERSJI (216)
- Najpierw skonfiguruj projekt... (218)
- ...a następnie prześlij i pobierz kod (219)
- Większość narzędzi do kontroli wersji próbuje rozwiązywać problemy za Ciebie (220)
- Serwer próbuje SCALIĆ zmiany (221)
- Jeśli system nie potrafi scalić zmian, informuje o konflikcie (222)
- Następne iteracje, następne opowieści (226)
- Mamy kilka wersji oprogramowania (228)
- Opisowe komentarze dodane przy przesyłaniu ułatwiają znalezienie starszego oprogramowania (230)
- Teraz możesz pobrać wersję 1.0 (231)
- (Awaryjne) krótkie spotkanie robocze (232)
- Oznaczanie wersji (233)
- Oznaczenia, gałęzie, pnie - co jeszcze? (235)
- Poprawianie wersji 1.0 - tym razem na poważnie (236)
- Teraz mamy DWIE wersje kodu bazowego (237)
- Kiedy NIE należy tworzyć gałęzi? (240)
- Zen poprawnego rozgałęziania (240)
- Co zapewnia system kontroli wersji... (242)
- System kontroli wersji nie może sprawdzić, czy kod działa (243)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (244)
Rozdział 6.5. Wstaw element a w pole b...
- Programiści nie potrafią czytać w myślach (248)
- Budowanie projektu w jednym kroku (249)
- Ant - narzędzie do budowania projektów w języku Java (250)
- Projekty, właściwości, cele i zadania (251)
- Dobre skrypty kompilacji... (256)
- Dobre skrypty kompilacji wykraczają POZA podstawy (258)
- Skrypty kompilacji to też kod (260)
- Nowy, weź dwójkę (261)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (262)
Rozdział 7. Pojawiają się problemy
- ZAWSZE coś pójdzie źle (264)
- Są trzy sposoby postrzegania systemu (266)
- Testy czarnej skrzynki dotyczą przede wszystkim danych WEJŚCIOWYCH i WYJŚCIOWYCH (267)
- Testy szarej skrzynki ZBLIŻAJĄ Cię do kodu (268)
- Testy białej skrzynki wymagają wiedzy o wnętrzu systemu (271)
- Testowanie WSZYSTKIEGO w jednym kroku (276)
- Automatyzacja testów przy użyciu platformy testowej (278)
- Używanie platformy do uruchamiania testów (279)
- Sterowanie CI za pomocą narzędzia CruiseControl (282)
- Testy gwarantują działanie programu, prawda? (284)
- Przetestowanie całego kodu wymaga sprawdzenia KAŻDEJ GAŁĘZI (292)
- Użyj raportu pokrycia, aby zobaczyć, które metody są sprawdzane (293)
- Uzyskanie wysokiego pokrycia kodu nie zawsze jest proste (295)
- Krótkie spotkanie robocze (297)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (300)
Rozdział 8. Zapewnianie poprawności kodu
- Pisz testy NA POCZĄTKU, a nie na końcu (302)
- NAJPIERW testy (303)
- Witamy w świecie wytwarzania sterowanego testami (303)
- Pierwszy test... (304)
- ...kończy się całkowitym niepowodzeniem (305)
- Doprowadź testy do koloru ZIELONEGO (306)
- Czerwone, zielone, refaktoryzacja... (307)
- W TDD testy STERUJĄ rozwojem kodu (312)
- Ukończenie zadania oznacza, że napisałeś wszystkie potrzebne testy i kończą się one sukcesem (314)
- Kiedy kod przejdzie testy, idź dalej! (315)
- Prostota oznacza unikanie zależności (319)
- Zawsze pisz kod, który można przetestować (320)
- Kiedy wystąpią trudności, przyjrzyj się projektowi (321)
- Wzorzec strategii pozwala tworzyć wiele wersji jednego interfejsu (322)
- Przechowuj kod testowy razem z testami (325)
- Testy prowadzą do powstania lepszego kodu (326)
- Więcej testów zawsze oznacza więcej kodu (328)
- Wzorce strategii, luźne powiązanie, zastępowanie obiektów (329)
- Potrzebujemy wielu odmiennych, choć podobnych obiektów (330)
- A gdyby tak wygenerować obiekty? (330)
- Obiekty zastępcze zastępują prawdziwe obiekty (331)
- Obiekty zastępcze to działające zastępniki obiektów (332)
- Dobre oprogramowanie można przetestować (335)
- Niełatwo być zielonym (336)
- Dzień z życia programisty stosującego TDD (338)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (340)
Rozdział 9. Wszystkie elementy łączą się ze sobą...
- Iteracja jest prawie ukończona... (342)
- ...jednak możesz zrobić jeszcze wiele rzeczy (343)
- TRZEBA przeprowadzić testy systemu... (348)
- ...ale KTO ma to zrobić? (349)
- Testy systemu wymagają kompletnego oprogramowania (350)
- Dobre testy systemu wymagają DWÓCH cykli iteracji (351)
- Więcej iteracji oznacza dodatkowe problemy (352)
- Życie (i śmierć) błędu (358)
- Znalazłeś błąd i co dalej? (360)
- Anatomia raportu o błędzie (361)
- Jest jeszcze wiele rzeczy, które MÓGŁBYŚ zrobić... (362)
- Czas na przegląd iteracji (366)
- Przykładowe pytania z przeglądu iteracji (367)
- OGÓLNA lista priorytetów zadań DODATKOWYCH (368)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (370)
Rozdział 10. Jeśli nie jest zepsute... i tak lepiej to naprawić
- Czym jest działające oprogramowanie? (372)
- Potrzebujesz planu następnej iteracji (374)
- Szybkość pozwala uwzględnić... RZECZYWISTOŚĆ BIZNESOWĄ (381)
- Klient NADAL jest najważniejszy (382)
- Oprogramowanie innych zespołów to NADAL tylko oprogramowanie (384)
- Akceptacja klienta? Jest! (387)
- Testowanie kodu (392)
- Houston, mamy problem... (393)
- Krótkie spotkanie robocze (394)
- Nie ufaj NIKOMU (395)
- Zespół bez procesu (400)
- Zespół z procesem (401)
Rozdział 11. Profesjonalne usuwanie błędów
- W poprzednim odcinku (404)
- Najpierw musisz porozmawiać z klientem (406)
- Pierwszy priorytet: umożliwienie zbudowania oprogramowania (412)
- Moglibyśmy naprawić kod... (414)
- ...ale trzeba naprawić funkcje systemu (415)
- Określ, które funkcje działają (416)
- TERAZ wiesz, co (nie) działa (419)
- Co zrobiłbyś w tej sytuacji? (419)
- Oszacuj czas pracy przy użyciu testów punktowych (420)
- O czym informują Cię wyniki testów punktowych? (422)
- Intuicja członków zespołu ma znaczenie (424)
- Poinformuj klienta o szacunkowym czasie naprawy błędów (426)
- Sytuacja wygląda dobrze... (430)
- ...i kończysz iterację sukcesem! (431)
- I klient jest zadowolony (432)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (434)
Rozdział 12. Proces w praktyce
- Definiowanie procesu rozwoju oprogramowania (436)
- Dobry proces prowadzi do dobrego oprogramowania (437)
- Wymagany jest strój wieczorowy (442)
- Wybrane materiały dodatkowe (444)
- Więcej wiedzy = lepszy proces (445)
- Narzędzia do Twojej programistycznej skrzynki narzędziowej (446)
Dodatek A Pięć najważniejszych tematów (których nie poruszyliśmy)
- Numer 1. Diagramy klas w notacji UML (450)
- Numer 2. Diagramy sekwencji (452)
- Numer 3. Opowieści użytkownika i przypadki użycia (454)
- Numer 4. Testy systemu a testy jednostkowe (456)
- Numer 5. Refaktoryzacja (457)
Dodatek B Narzędzia dla doświadczonych programistów
- Techniki rozwoju (460)
- Zasady rozwoju (462)
Skorowidz (465)
| Kategoria: | Programowanie |
| Zabezpieczenie: |
Watermark
|
| ISBN: | 978-83-246-6058-2 |
| Rozmiar pliku: | 38 MB |
