Ten post to subiektywy wybór z pracy Software Engineering at Google autorstwa Fergusa Hendersona, która jest przeglądem praktyk wytwarzania oprogramowania w Google. Nie jest moją ambicją streścić tę pracę w całości, a jedynie wybrać to, co wydawało mi się interesujące lub niespotykane w innych firmach. Praca pochodzi z końca stycznia 2017 roku.

• W styczniu 2015 repozytorium Google zawierało 86 terabajtów danych. Było to w sumie miliard plików, a z tego miliada ponad 9 milionów plików to były pliki źródłowe, zawierające w sumie ponad 2 miliardy linii kodu. Dziennie do repozytorium wykonywanych było 40 tysięcy commitów, co przekładało się na historię zawierające 35 milionów commitów.
• Programiści w Google mogą commitować do każdej części repozytorium, jeśli uznają, że mogą coś poprawić. Development większości funkcjonalności odbywa się na głównym branchu, a nie na pobocznych branchach. Każde poddrzewo w repozytorium posiada właścicieli, którzy jako jedyni mogą akceptować zmiany. Wszystkie commity są budowane automatycznie, także wtedy, gdy zmienią się zależności przechodnie. W większych zespołach istnieje rotacyjna pozycja „build copa”, który pilnuje, by wszystkie testy zawsze przechodziły na najnowszej wersji repozytorium.
• Google posiada narzędzia, które potrafią podpowiedzieć, kogo dodać do review commitu, bazujące na historii danego programisty oraz na tym, kto ostatnio robił recenzję w wybranym obszarze, a nawet na podstawie tego, ile recenzji oczekuje w tej chwili na każdego recenzenta. Nie jest jednak jednoznacznie powiedziane, czy duża ilość oczekujących recenzji jest przesłanką do tego, by zasugerować włączenie danego recenzenta, czy przeciwnie, ktoś taki jest pomijany w sugestiach.
• Jeśli zmiana, która została włączone do głównego brancha zawiera błąd, to praktyką w Google jest, by w code review oryginalnego commitu, który wprowadzał błąd, dać o tym znać, tak by autor zmiany i wszyscy, którzy tamten commit recenzowali, mieli świadomość tego błędu. Zdarza się też, że commity wchodzą po akceptacji tylko jednego recenzenta, a pozostali recenzenci mogą dalej dodawać swoje komentarze do commitu, ale zasugerowane przez nich zmiany wejdą w następnych commitach, wykonanych – jak rozumiem – przez tego samego programistę, który zrobił oryginalny commit. Zmiany, które zawierają szczególnie złożony kod, muszą być dodatkowo zatwierdzone przez osobę, która zdała wewnętrzne szkolenie z pisania kodu czytelnego dla innych.
• Przed każdym deploymentem robione są testy obciążeniowe, który efektem jest raport zawierający informacje o opóźnieniu w obsłudze nadchodzących żądań i częstotliwości błędnych odpowiedzi.
• Programiści w Google są zachęcani do programowania w 4 językach: C++, Javie, Pythonie, i Go. Ma to maksymalizować możliwość ponownego wykorzystania kodu i zapewniać możliwie bliską współpracę wszystkich programistów. Rozumiem przez to jednak, że nie jest tak, że inne języki są w Google zakazane, a jedynie, że wymieniona czwórka jest szczególnie promowana wewnątrz organizacji, i że powstają w niej najważniejsze produkty. Wymianę danych między różnymi językami programowania zapewnia projekt Protocol Buffers rozwijany przez Google. Proces budowania we wszystkich językach obsługiwany jest tym tymi samymi poleceniami, czyli np. do uruchomienia testów zawsze będzie to polecenie test.
• Nowe wersje swoich produktów zespoły wydają często – raz w tygodniu, a nawet raz dziennie. Pozwala to wykonać więcej krótkich iteracji, szybciej reagować na bugi i feedback, i pozostawia zespoły zmotywowanymi, ponieważ na bieżąco widzą efekty swojej pracy w działaniu. Nowe zmiany są propagowane na produkcję często najpierw na małą ilość serwerów, a w przeciągu kilku dni na wszystkie, żeby zmniejszyć rozmiar potencjalnych szkód, które ostatnie zmiany mogłyby wyrządzić.
• Duże funkcjonalności przechodzą dodatkowo review pod względem bezpieczeństwa, pod względem prawnym i pod względem tego, że są odpowiednio monitorowane na wypadek awarii. Po każdej poważnej awarii tworzone jest post-mortem, które zawiera informacje o tym, co doprowadziło do incydentu, jak przebiegał w czasie, jakich innych obszarów dotknął, co zadziałało, a co nie zadziałało, i jako można uniknąć podobnych błędów w przyszłości.
• Większość oprogramowania w Google jest przepisywana raz na kilka lat z powodu zmieniających się wymagań i faktu, że zmienia się technologia wokół. Przyjmuje się w Google, że ilość wymagań, które narosły przez kilka lat, stanowią wystarczające uzasadnienie, żeby całkowicie wymienić kod, który nie został zoptymalizowany pod nawarstwiające się przez lata wymagania. Przy okazji przepisywania usuwa się niepotrzebną złożoność, a dodatkowo wytwarza w zespole poczucie własności względem kodu.
• Zespoły w Google są zobligowane do wyznaczania sobie kwartalnych i rocznych celów, i do rozliczania się z nich. Ta praktyka istnieje na każdym poziomie organizacji. Oceny kwartalne i roczne służą wyłącznie do ewaluacji zespołów, a nie pojedynczych osób. Spodziewane jest, by zespół ustawił sobie jako cel wykonanie około 50% większej ilości zadań, niż jest w stanie zrealizować, stąd osiągniecie założonych celów na poziome 65% jest uznawane za wysokie.
• W Google nie istnieje jasny proces zatwierdzania i anulowania projektów i nie ma określonego szczebla, na którym zapadają decyzję na ten temat. Zdarzają się przesunięcia wśród ludzi i zespołów, tak by nad jednym projektem pracowali ludzie w zbliżonej lokalizacji geograficznej. W takiej sytuacji programiści mogą wybrać zmianę projektu i poszukanie nowego w miejscu, w którym pracują, lub wyjazd do siedziby Google w innym kraju i podążenie za projektem, w którym są. Programiści nie zmieniają jednak projektu częściej, niż raz na rok.
• Co oczywiste, programiści w Google są ewaluowani między innymi przez management. Co ciekawe, także menadżerowie są oceniani przez podległe im zespoły, dwa razy do roku.

Osoby zainteresowane pogłębieniem swojej wiedzy na temat praktyk wytwarzania oprogramowania w Google mogą znaleźć całą pracę w języku angielskim na tej stronie.