- promocja
Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania - ebook
Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania - ebook
Inżynieria oprogramowania jest pojęciem znacznie szerszym od kodowania: oznacza wszystkie niezbędne narzędzia i procesy stosowane przez organizację do tworzenia oprogramowania. To daje możliwość zachowania wartości kodu w dłuższej perspektywie czasu i pozwala ustanowić bardziej rygorystyczne zasady tworzenia oprogramowania, a dzięki temu sam kod jest podatniejszy na zmiany. Innymi słowy, inżynieria oprogramowania polega na optymalnym integrowaniu i organizowaniu tworzenia aplikacji ... od koncepcji, poprzez tworzenie, wdrażanie i utrzymywanie, po jej wycofywanie.
To nie jest podręcznik dla programistów. Celem autorów jest zaprezentowanie jedynej w swoim rodzaju perspektywy firmy Google, od lat rozwijającej trwały ekosystem oprogramowania, co pozwoliło zebrać pożyteczne wnioski dotyczące skali działalności i czasu jej trwania. W książce zwrócono uwagę na to, że proces tworzenia oprogramowania jest wysiłkiem zespołowym, omówiono najlepsze praktyki związane z utrzymywaniem bazy kodu o dużych rozmiarach i długim stażu, pokazano także narzędzia, które mogą się okazać przydatne w jej utrzymywaniu. Omówione tu zagadnienia uwzględniają doświadczenia, jakie typowy inżynier oprogramowania zdobywa w ramach swojej pracy, służą też wskazaniu różnorodnych sposobów rozwiązywania poszczególnych problemów.
Najciekawsze zagadnienia:
- unikatowa kultura pracy w Google
- procesy i narzędzia stosowane w Google
- metody zwiększania odporności kodu na upływ czasu
- wpływ skali oprogramowania na organizację pracy inżynierów
- kompromisy w procesie podejmowania decyzji projektowych
Piszesz kod? To ważne zadanie - bierz przykład z najlepszych!
Spis treści
Słowo wstępne
Przedmowa
Część I. Teza
- 1. Czym jest inżynieria oprogramowania
- Czas i zmiana
- Prawo Hyruma
- Przykład: uporządkowanie z mieszaniem
- Dlaczego po prostu nie dążyć do sytuacji "nic się nie zmienia"?
- Skala i efektywność
- Zasady, które nie zapewniają skalowania
- Zasady zapewniające dobre skalowanie
- Przykład: aktualizacja kompilatora
- Przesunięcie w lewą stronę
- Kompromisy i koszty
- Przykład: markery
- Informacje zapewniane przy podejmowaniu decyzji
- Przykład: kompilacje rozproszone
- Przykład: wybór między czasem i skalą
- Ponowne analizowanie decyzji i popełnianie błędów
- Porównanie inżynierii oprogramowania i programowania
- Podsumowanie
- W skrócie
- Czas i zmiana
Część II. Kultura pracy
- 2. Jak dobrze pracować w zespołach?
- Pomóż mi ukryć mój kod
- Mit geniuszu
- Ukrywanie uważane za coś szkodliwego
- Wczesne wykrywanie
- Wskaźnik autobusowy
- Tempo postępów
- Analiza przypadku: inżynierowie i ich biura
- Mówiąc wprost, nie ukrywaj się
- Liczy się tylko zespół
- Trzy filary interakcji społecznych
- Dlaczego te filary są istotne?
- Pokora, szacunek i zaufanie w praktyce
- Kultura analizowania bez obwiniania
- Bycie "googlowym"
- Podsumowanie
- W skrócie
- 3. Dzielenie się wiedzą
- Wyzwania związane z uczeniem się
- Filozofia
- Przygotowanie: bezpieczeństwo psychologiczne
- Doradztwo
- Bezpieczeństwo psychologiczne w dużych grupach
- Poszerzanie własnej wiedzy
- Zadawaj pytania
- Zrozum kontekst
- Skalowanie pytań: zadaj je społeczności
- Rozmowy grupowe
- Listy wysyłkowe
- Poczta elektroniczna w firmie Google
- YAQS - platforma pytań i odpowiedzi
- Skalowanie posiadanej wiedzy - zawsze możesz się czegoś nauczyć
- Spotkania w godzinach pracy
- Konsultacje techniczne i zajęcia
- Dokumentacja
- Kod
- Skalowanie wiedzy na poziomie organizacji
- Doskonalenie kultury dzielenia się wiedzą
- Ustanawianie kanonicznych źródeł informacji
- Bycie na bieżąco
- Czytelność - standaryzowane doradztwo w ramach inspekcji kodu
- Czym jest proces oceny czytelności?
- Dlaczego korzysta się z tego procesu?
- Podsumowanie
- W skrócie
- 4. Inżynieria zapewniająca równość
- Uprzedzenie z założenia
- Zrozumienie potrzeby uwzględniania różnorodności
- Zapewnianie zdolności wspierania wielokulturowości
- Ustanawianie różnorodności bodźcem do podejmowania działań
- Odrzucanie osobliwych metod
- Uporanie się z ugruntowanymi procesami
- Wartości a wyniki
- Zachowaj ciekawość i nie zatrzymuj się
- Podsumowanie
- W skrócie
- 5. Jak kierować zespołem?
- Menedżerowie i kierownicy techniczni (i osoby pełniące obie role)
- Menedżer inżynierów
- Kierownik techniczny
- Menedżer i kierownik techniczny w jednym
- Analiza przypadku: wywieranie wpływu na osoby, które nam nie podlegają
- Przejście z roli pojedynczego uczestnika do roli przywódcy
- Jedyna rzecz wywołująca obawy to. w zasadzie wszystko
- Przywództwo służebne
- Menedżer inżynierów
- Menedżer to osoba identyfikowana przez 4-literowe słowo
- Współczesny menedżer inżynierów
- Antywzorce
- Antywzorzec: zatrudnianie naiwniaków
- Antywzorzec: ignorowanie osób o kiepskiej wydajności
- Antywzorzec: ignorowanie problemów ludzkich
- Antywzorzec: przyjaźnienie się z każdym
- Antywzorzec: naruszanie poprzeczki zatrudnienia
- Antywzorzec: traktowanie własnego zespołu jak dzieci
- Pozytywne wzorce
- Zrezygnuj z ego
- Bądź mistrzem zen
- Bądź katalizatorem
- Usuwaj przeszkody
- Bądź nauczycielem i mentorem
- Określ wyraźne cele
- Bądź szczery
- Monitoruj poziom zadowolenia
- Nieoczekiwane pytanie
- Inne wskazówki i rady
- Ludzie są jak rośliny
- Motywacja wewnętrzna i zewnętrzna
- Podsumowanie
- W skrócie
- Menedżerowie i kierownicy techniczni (i osoby pełniące obie role)
- 6. Przywództwo przy dużej skali
- Zawsze bądź rozstrzygającym
- Przypowieść o samolocie
- Identyfikowanie osób "z klapkami na oczach"
- Ustalanie kluczowych kompromisów
- Decydowanie, a następnie powtarzanie działań
- Zawsze możesz odejść
- Twoja misja: zbuduj niezależny zespół
- Dzielenie obszaru problemu
- Zawsze stawiaj na rozwój
- Cykl sukcesu
- Ważne kontra pilne
- Uczenie się upuszczania piłek
- Oszczędzanie własnej energii
- Podsumowanie
- W skrócie
- Zawsze bądź rozstrzygającym
- 7. Pomiar wydajności inżynierów
- Dlaczego powinno się mierzyć wydajność inżynierów?
- Segregacja: czy w ogóle jest to warte przeprowadzania pomiaru?
- Wybór sensownych metryk uwzględniających cele i sygnały
- Cele
- Sygnały
- Metryki
- Użycie danych do weryfikowania poprawności metryk
- Podejmowanie działania i monitorowanie wyników
- Podsumowanie
- W skrócie
Część III. Procesy
- 8. Wytyczne i reguły dotyczące stylu
- Dlaczego stosujemy reguły?
- Tworzenie reguł
- Zasady ustalania wytycznych
- Przewodnik stylów
- Modyfikowanie reguł
- Proces
- Moderatorzy stylów
- Wyjątki
- Wytyczne
- Stosowanie reguł
- Narzędzia do sprawdzania błędów
- Narzędzia formatujące kod
- Podsumowanie
- W skrócie
- 9. Inspekcja kodu
- Przepływ procesu inspekcji kodu
- Realizowanie inspekcji kodu w firmie Google
- Zalety inspekcji kodu
- Poprawność kodu
- Zrozumiałość kodu
- Spójność kodu
- Korzyści natury psychologicznej i kulturowej
- Dzielenie się wiedzą
- Najlepsze praktyki dotyczące inspekcji kodu
- Bądź miły i profesjonalny
- Tworzenie drobnych zmian
- Tworzenie dobrych opisów zmian
- Ograniczanie liczby inspektorów do minimum
- Automatyzowanie, gdy tylko jest to możliwe
- Typy inspekcji kodu
- Inspekcje zupełnie nowego kodu
- Zmiany behawioralne, ulepszenia i optymalizacje
- Poprawki błędów i wycofania
- Refaktoryzacje i zmiany na dużą skalę
- Podsumowanie
- W skrócie
- 10. Dokumentacja
- Co jest kwalifikowane jako dokumentacja?
- Dlaczego dokumentacja jest niezbędna?
- Dokumentacja jest jak kod
- Poznaj swoich odbiorców
- Typy odbiorców
- Typy dokumentacji
- Dokumentacja referencyjna
- Dokumenty projektowe
- Kursy
- Dokumentacja pojęciowa
- Strony docelowe
- Inspekcje dokumentacji
- Filozofia towarzysząca dokumentacji
- KTO, CO, KIEDY, GDZIE i DLACZEGO
- Początek, środek i zakończenie
- Parametry dobrej dokumentacji
- Wycofywanie dokumentów
- Kiedy są potrzebni twórcy dokumentów technicznych?
- Podsumowanie
- W skrócie
- 11. Testowanie - przegląd
- Dlaczego tworzymy testy?
- Historia serwera Google Web Server
- Testowanie z szybkością nowoczesnego procesu projektowania
- Utwórz, uruchom i zareaguj
- Korzyści wynikające z testowania kodu
- Projektowanie zestawu testów
- Wielkość testu
- Zasięg testów
- Reguła Beyoncé
- Coś na temat pokrycia kodu
- Testowanie w firmie tak dużej jak Google
- Pułapki towarzyszące dużemu zestawowi testów
- Historia testowania w firmie Google
- Zajęcia wprowadzające
- Program certyfikacji Test Certified
- Testowanie w toalecie
- Kultura testowania obecnie
- Ograniczenia zautomatyzowanego testowania
- Podsumowanie
- W skrócie
- Dlaczego tworzymy testy?
- 12. Testowanie jednostkowe
- Doniosłość możliwości utrzymania
- Unikanie niepewnych testów
- Dążenie do uzyskania trwałych testów
- Testowanie za pośrednictwem publicznych interfejsów API
- Testuj stan, a nie interakcje
- Tworzenie przejrzystych testów
- Zapewnianie kompletności i zwięzłości testów
- Testuj zachowania, a nie metody
- Nie umieszczaj logiki w testach
- Twórz przejrzyste komunikaty o niepowodzeniach
- Testy i współużytkowanie kodu: zasada DAMP, a nie DRY
- Wartości współużytkowane
- Konfiguracja współużytkowana
- Współużytkowane metody pomocnicze i sprawdzanie poprawności
- Definiowanie infrastruktury testów
- Podsumowanie
- W skrócie
- 13. Dublery w testach
- Wpływ dublerów w testach na projektowanie oprogramowania
- Dublery w testach w firmie Google
- Podstawowe pojęcia
- Przykładowy dubler w teście
- Łącza
- Środowiska tworzące obiekty zastępcze
- Techniki użycia dublerów w testach
- Użycie fałszywego obiektu
- Użycie obiektów stub
- Testowanie interakcji
- Rzeczywiste implementacje
- Wybieraj realizm, a nie izolację
- Decydowanie o tym, kiedy skorzystać z rzeczywistej implementacji
- Zastosowanie fałszywego obiektu
- Dlaczego fałszywe obiekty są ważne?
- Kiedy powinno się tworzyć fałszywe obiekty?
- Wierność fałszywych obiektów
- Fałszywe obiekty powinny być testowane
- Jak postąpić, jeśli fałszywy obiekt jest niedostępny?
- Użycie obiektów stub
- Zagrożenia związane z nadużywaniem obiektów stub
- Kiedy użycie obiektów stub jest właściwe?
- Testowanie interakcji
- Zamiast testowania interakcji preferuj testowanie stanu
- Kiedy testowanie interakcji jest właściwe?
- Najlepsze praktyki związane z testowaniem interakcji
- Podsumowanie
- W skrócie
- 14. Testowanie na dużą skalę
- Czym są większe testy?
- Wierność
- Typowe luki w testach jednostkowych
- Dlaczego nie warto korzystać z większych testów?
- Większe testy w firmie Google
- Większe testy i czas
- Większe testy przy skali działań firmy Google
- Struktura dużego testu
- Testowany system
- Dane testu
- Weryfikacja
- Typy większych testów
- Testowanie funkcjonalne jednego lub większej liczby plików binarnych prowadzących interakcję
- Testowanie przeglądarki i urządzenia
- Testowanie wydajności, obciążenia i przeciążenia
- Testowanie konfiguracji wdrażania
- Testowanie rozpoznawcze
- Testowanie różnic A/B (regresji)
- Testowanie akceptacyjne na poziomie użytkowników
- Kontrolery i analiza kanarkowa
- Przywracanie awaryjne i inżynieria chaosu
- Ocena na poziomie użytkowników
- Duże testy i przepływ informacji procesu projektowania
- Tworzenie dużych testów
- Uruchamianie dużych testów
- Ustanowienie właścicieli dużych testów
- Podsumowanie
- W skrócie
- Czym są większe testy?
- 15. Wycofywanie
- Dlaczego warto wycofywać?
- Dlaczego wycofywanie jest takie trudne?
- Uwzględnienie wycofywania podczas projektowania
- Typy procesu wycofywania
- Wycofywanie wskazane
- Wycofywanie obowiązkowe
- Ostrzeżenia związane z wycofywaniem
- Zarządzanie procesem wycofywania
- Właściciele procesu
- Kamienie milowe
- Narzędzia do wycofywania
- Podsumowanie
- W skrócie
Część IV. Narzędzia
- 16. Kontrola wersji i zarządzanie gałęziami
- Czym jest kontrola wersji?
- Dlaczego kontrola wersji jest ważna?
- Porównanie scentralizowanego i rozproszonego systemu VCS
- "Źródło prawdy"
- Kontrola wersji i zarządzanie zależnościami
- Zarządzanie gałęziami
- Praca w trakcie jest równoznaczna istnieniu gałęzi
- Gałęzie rozwojowe
- Gałęzie wersji do opublikowania
- Kontrola wersji w firmie Google
- Jedna wersja
- Scenariusz: wiele dostępnych wersji
- Reguła "jednej wersji"
- (Prawie) żadnych długo istniejących gałęzi
- A co z gałęziami publikowanych wersji?
- Repozytoria monolityczne
- Przyszłość kontroli wersji
- Podsumowanie
- W skrócie
- Czym jest kontrola wersji?
- 17. Narzędzie Code Search
- Interfejs użytkownika narzędzia Code Search
- W jaki sposób pracownicy firmy Google korzystają z narzędzia Code Search?
- Gdzie?
- Co?
- Jak?
- Dlaczego?
- Kto i kiedy?
- Dlaczego zdecydowano się na osobne narzędzie internetowe?
- Skala
- Globalny widok kodu bez wymogu konfiguracji
- Specjalizacja
- Integracja z innymi narzędziami do projektowania
- Udostępnianie interfejsów API
- Wpływ skali na projekt
- Opóźnienie zapytania wyszukiwania
- Opóźnienie indeksowania
- Implementacja firmy Google
- Indeks wyszukiwania
- Klasyfikowanie
- Wybrane kompromisy
- Kompletność - liczy się przede wszystkim repozytorium
- Kompletność - wszystkie wyniki i te najbardziej trafne
- Kompletność - porównanie bieżącej gałęzi kodu z innymi gałęziami kodu oraz całej historii i obszarów roboczych
- Wyrazistość - porównanie tokenów, podłańcuchów i wyrażeń regularnych
- Podsumowanie
- W skrócie
- 18. Systemy do kompilacji i filozofia procesu kompilacji
- Przeznaczenie systemu do kompilacji
- Co się dzieje, gdy nie ma systemu do kompilacji?
- Wszystko, czego potrzebuję, to kompilator
- Czy skrypty powłoki nas uratują?
- Nowoczesne systemy do kompilacji
- Wszystko sprowadza się do zależności
- Systemy do kompilacji oparte na zadaniach
- Systemy do kompilacji oparte na artefaktach
- Kompilacje rozproszone
- Czas, skala i kompromisy
- Radzenie sobie z modułami i zależnościami
- Użycie szczegółowych modułów i reguła 1:1:1
- Minimalizowanie widoczności modułów
- Zarządzanie zależnościami
- Podsumowanie
- W skrócie
- 19. Critique - narzędzie firmy Google do inspekcji kodu
- Zasady dotyczące narzędzi do inspekcji kodu
- Przepływ inspekcji kodu
- Powiadomienia
- Etap 1. Tworzenie zmiany
- Ujawnianie różnic
- Wyniki analizy
- Ścisła integracja narzędzi
- Etap 2. Żądanie inspekcji
- Etapy 3. i 4. Zaznajomienie się ze zmianą i skomentowanie jej
- Komentowanie
- Stan zmiany
- Etap 5. Zatwierdzenie zmiany
- Etap 6. Wprowadzanie zmiany
- Po wprowadzeniu zmiany - historia śledzenia
- Podsumowanie
- W skrócie
- 20. Analiza statyczna
- Właściwości efektywnej analizy statycznej
- Skalowalność
- Użyteczność
- Kluczowe wnioski związane z wdrażaniem analizy statycznej
- Skoncentrowanie się na zadowoleniu projektanta
- Ustanowienie analizy statycznej częścią głównego przepływu informacji procesu projektowania
- Pozwól użytkownikom zaangażować się
- Tricorder - platforma do analizy statycznej firmy Google
- Zintegrowane narzędzia
- Zintegrowane kanały informacji zwrotnych
- Poprawki sugerowane
- Dostosowywanie przed rozpoczęciem projektu
- Sprawdzenia przed wysłaniem
- Integracja z kompilatorem
- Analiza w trakcie edytowania i przeglądania kodu
- Podsumowanie
- W skrócie
- Właściwości efektywnej analizy statycznej
- 21. Zarządzanie zależnościami
- Dlaczego zarządzanie zależnościami jest tak trudne?
- Wymagania powodujące konflikt i zależności diamentowe
- Importowanie zależności
- Możliwości zapewnienia zgodności
- Kwestie uwzględniane podczas importowania
- Jak w firmie Google radzimy sobie z importowaniem zależności?
- Zarządzanie zależnościami w teorii
- Nic się nie zmienia (czyli statyczny model zależności)
- Wersjonowanie semantyczne
- Pakietowe modele dystrybucji
- Model Live at Head
- Ograniczenia wersjonowania semantycznego
- Wersjonowanie semantyczne może nadmiernie ograniczać
- Wersjonowanie semantyczne może zapewniać zbyt wygórowaną obietnicę
- Motywacje
- Wybór wersji minimalnej
- Czy zatem wersjonowanie semantyczne się sprawdza?
- Zarządzanie zależnościami przy nieograniczonych zasobach
- Eksportowanie zależności
- Podsumowanie
- W skrócie
- Dlaczego zarządzanie zależnościami jest tak trudne?
- 22. Zmiany na dużą skalę
- Czym jest zmiana na dużą skalę?
- Kto zajmuje się zmianami na dużą skalę?
- Bariery w przypadku zmian atomowych
- Ograniczenia techniczne
- Konflikty związane ze scalaniem
- Nie ma "nawiedzonych cmentarzy"
- Niejednoznaczność
- Testowanie
- Inspekcja kodu
- Infrastruktura zmian na dużą skalę
- Zasady i kultura pracy
- Analiza bazy kodu
- Zarządzanie zmianami
- Testowanie
- Obsługa zmian przez języki
- Proces zmian na dużą skalę
- Autoryzowanie
- Tworzenie zmiany
- Podział na zmiany składowe i wprowadzanie ich do bazy kodu
- Oczyszczanie
- Podsumowanie
- W skrócie
- 23. Integracja ciągła
- Pojęcia związane z integracją ciągłą
- Szybkie pętle informacji zwrotnej
- Automatyzacja
- Testowanie ciągłe
- Wyzwania towarzyszące integracji ciągłej
- Testowanie hermetyczne
- Integracja ciągła w firmie Google
- Analiza przypadku procesu integracji ciągłej - aplikacja Google Takeout
- Nie mogę jednak pozwolić sobie na zastosowanie integracji ciągłej
- Podsumowanie
- W skrócie
- Pojęcia związane z integracją ciągłą
- 24. Wdrażanie ciągłe
- Idiomy wdrażania ciągłego w firmie Google
- Szybkość to sport zespołowy - sposób podziału procesu wdrażania na możliwe do zarządzania części
- Ocena wyizolowanych zmian - opcje z flagą ochraniającą
- Dążenie do zapewnienia zwinności - przygotowanie łańcucha wersji
- Żadne binaria nie są idealne
- Dotrzymuj ustalonego ostatecznego terminu publikacji wersji
- Skupienie się na jakości i użytkowniku - udostępniaj tylko to, co jest przydatne
- Przesunięcie w lewo - wcześniejsze podejmowanie decyzji opartych na danych
- Zmiana kultury zespołowej - uwzględnienie dyscypliny w procesie wdrażania
- Podsumowanie
- W skrócie
- 25. Model CaaS
- Ujarzmianie środowiska przetwarzania
- Automatyzacja mozolnej pracy
- Konteneryzacja i wielodostępność
- Podsumowanie
- Tworzenie oprogramowania dla zarządzanego środowiska przetwarzania
- Tworzenie architektury pod kątem awarii
- Zadania wsadowe i obsługujące
- Zarządzanie stanem
- Nawiązywanie połączenia z usługą
- Kod jednorazowy
- Wpływ czasu i skali na model CaaS
- Kontenery jako abstrakcja
- Jedna usługa, by wszystkimi rządzić
- Wprowadzana konfiguracja
- Wybór usługi przetwarzania
- Centralizacja kontra dostosowywanie
- Poziom abstrakcji: wariant bezserwerowy
- Publiczne i prywatne
- Podsumowanie
- W skrócie
- Ujarzmianie środowiska przetwarzania
Część V. Podsumowanie
- Posłowie
Kategoria: | Branża IT |
Zabezpieczenie: |
Watermark
|
ISBN: | 978-83-283-9972-3 |
Rozmiar pliku: | 6,6 MB |