Деталі електронної книги

Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania

Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania

Titus Winters, Tom Manshreck, Hyrum Wright

Eлектронна книга

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!

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