Разработка программного обеспечения от Google. О чем стоит узнать

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

Titus Winters, Tom Manshreck, Hyrum Wright

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!

O autorze:

Titus Winters jest starszym inżynierem oprogramowania w Google. Kieruje pracami zespołu odpowiedzialnego za bazę kodu C++ firmy Google.

Tom Manshreck jest członkiem zespołu zajmującego się bibliotekami języka C++ w Google. Odpowiada za tworzenie dokumentacji technicznej.

Hyrum Wright jest inżynierem oprogramowania w Google. Kieruje grupą, która tworzy narzędzia do zautomatyzowanego wprowadzania zmian.

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