Inżynieria oprogramowania według Google - Titus Winters, Tom Manshreck, Hyrum Wright

Opis produktu: Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania - Titus Winters, Tom Manshreck, Hyrum Wright

Książka autorstwa trzech inżynierów firmy Google (w tłumaczeniu Piotra Plicha) -Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania. Nie jest to podręcznik dla programistów, autorzy skupiają się na praktycznych aspektach inżynierii oprogramowania, opierając się na doświadczeniach zgromadzonych przez firmę Google. Inżynieria oprogramowania to nie tylko pisanie kodu, obejmuje ona szeroki zakres działań takich jak zarządzanie projektem czy analiza wymagań. Zagadnienia omówione w książce 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.

Widok z tyłu.

Zagadnienia poruszane w książce

• 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

Informacje o książce

• Tytuł: Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania
• Autorzy: Titus Winters, Tom Manshreck, Hyrum Wright
• Tłumaczenie: Piotr Pilch
• ISBN: 978-83-283-9971-6
• Rok wydania: 2023
• Format: 165 x 235 mm
• Ilość stron: 576
• Wydawnictwo: Helion S.A.
• Oprawa: miękka

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

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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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

Część V. Podsumowanie

• Posłowie