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

• Назва: Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania
• Автор: Titus Winters, Tom Manshreck, Hyrum Wright
• Оригінальна назва: Software Engineering at Google: Lessons Learned from Programming Over Time
• Переклад: Piotr Pilch
• ISBN: 978-83-283-9972-3, 9788328399723
• Дата видання: 2023-05-04
• Формат: Eлектронна книга
• Ідентифікатор видання: iogoog
• Видавець: Helion