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

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. Teza1. Czym jest inżynieria oprogramowaniaCzas 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 pracy2. 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 skaliZawsze 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ówDlaczego 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. Procesy8. Wytyczne i reguły dotyczące styluDlaczego 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 koduPrzepł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. DokumentacjaCo 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ądDlaczego 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 jednostkoweDoniosł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 testachWpł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. WycofywanieDlaczego 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ędzia16. Kontrola wersji i zarządzanie gałęziamiCzym 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 SearchInterfejs 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 kompilacjiPrzeznaczenie 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 koduZasady 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 statycznaWł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ściamiDlaczego 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łaPoję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łeIdiomy 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 CaaSUjarzmianie ś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. PodsumowaniePosłowie