Чергова книга від Google: кому з розробників варто читати і чому

Усім привіт, мене звати Олександр. Я працюю у сферах тестування, автоматизації та розробки вже трохи понад 10 років. У цій статті розповідаю про книгу, яку прочитав сам, і яку вважаю корисною для будь-якого інженера. Чому — спробую аргументувати нижче.

Спочатку трохи історичного контексту. Десять років тому James Whittaker, Jason Arbon Jeff Carollo написали одну з найвідоміших книг про тестування «How Google Tests Software». В ній автори розповідали, які інструменти та підходи використовуються тест-інженерами в Google. А також — хто ж такі ті таємничі SDET-інженери (Software Developer In Test) і що вони реально роблять.

На момент виходу книги, та й багато років після цього, описані підходи були джерелом натхнення для всіх спеціалістів, хто хотів ефективно тестувати. Звичайно, далеко не всі описані речі можна було брати та й одразу налаштовувати на своєму конкретному проєкті. Але найголовніше в книзі було ось що — ідеї того, яким може бути тестування, коли за нього беруться інженери.

Особисто мені книга в цілому сподобалася. Багато нового це читання не дає, втім показує лишень приклад того, як можна організовувати та виконувати тестування дуже великих продуктів. Єдине, чого мені в ній не вистачало — хотілося б трохи більше інформації про інструменти за межами тестування. Адже крім тестування, є й інші аспекти розробки: інструменти збірки, процеси делівері, деплойменту та ін.

Навесні 2020 року вийшла нова книга від Google, що зветься «Software Engineering at Google: Lessons Learned from Programming Over Time», авторами якої є Titus Winters, Tom Manshreck та Hyrum Wright.

Я дізнався про цю книгу випадково. Перш ніж її придбати, я вирішив прочитати відгуки. І от відгуки були різними — від хороших, до доволі негативних. Більшість людей, яким книга не сподобалася, вказували на те, що сподівалися відкрити для себе інструменти та підходи, які вони одразу зможуть принести у свою роботу та впровадити в реальності. Тут їх, на жаль, спіткало розчарування.

Саме через те, що моя поточна робота вже давно вийшла за межі звичайного тестування — ця нова книга від Google була для мене ще цікавішою та й кориснішою. Тож не вагаючись, я купив її та доволі швидко прочитав.

Нижче я хочу поділитися зі спільнотою короткою рецензією на цю книгу: чому її варто читати та що конкретно ви можете дізнатися з цього тексту корисного для себе і своєї роботи.

Структура

Книга поділена на три великі частини:

• культура,
• процеси
• та інструменти.

Це по суті набір коротких есе, написаних різними інженерами на обрані теми. Але усі вони об’єднані однією важливою характеристикою: тим, що це досвід інженера у конкретній компанії. Небагато хто у світі оперує у масштабах Google.

Але навіть для пересічного інженера читати про проблеми та шляхи вирішення — буде дуже й дуже корисним. Бо, можливо, сьогодні ви ще не стикаєтесь у роботі з такою задачею, але вже завтра вам доведеться вирішувати саме її. Ніколи не зможеш гарантовано знати наперед, які складеться.

Далі викладу тезисно про важливе з різних розділів.

Про культуру

• Коли ви дизайните та створюєте систему будь-якого розміру, вам у пригоді стануть такі принципи:
  • Час та Зміни. Як довго код буде знаходитися у продакшені та як часто ви плануєте робити у ньому зміни. Цей принцип працює також і з тестуванням: якщо ви пишете скрипт, для того, щоб застосувати його раз чи два — немає сенсу дбати про його розширюваність. Але коли багато команд будуть користуватися вашими тестами, тоді й треба робити їх легкими у підтримці та стабільними.
  • Масштаб та Ріст. Створюючи нову систему, важливо планувати, як вона буде працювати з ростом користувачів (під збільшеним навантаженням); наскільки легко працювати з вашим API?
  • Опції вибору та витрати. Витрати можуть бути як грошові, так і у вигляді робочого часу, витраченого на певне завдання.
• Сучасні системи розробляються командою професіоналів, а не самотнім вченим десь у віддаленій печері. Саме тому успіх чи провал продукту залежить від вміння взаємодіяти з іншими людьми для досягнення цілей.
• Психологічна безпека — це те, що допомагає командам вчитися (у тому числі на своїх помилках).
• Обмін знаннями може набирати дуже багатьох різних форм: від чистого коду до документації й туторіалів. Який би вид обміну ви не обрали, треба слідкувати чи він ефективний та корисний у конкретній ситуації.
• Бути керівником (лідером) в команді — складно. Особливо для тих, хто ще вчора був просто сеньйором. Але найкраща порада тут — це перестати міряти себе за кількістю рядків коду, які конкретно ви написали. Міряйте себе за успішністю усієї вашої команди.
• Можна користуватися великою кількістю різних метрик. Але як обрати нову метрику — допоможе GSM (Goals — Signals — Metrics) фреймворк.

Про процеси

• Гайди зі стилю стануть вам у пригоді, якщо ви хочете досягти consistency у коді.
• Під час code review думайте не тільки про те, чи код правильно працює. А й наскільки легко його читати чи збагнути.
• Завжди пам’ятайте про те, для якої аудиторії ви створюєте ту чи іншу форму документації.
• Чим швидше ви домовитеся щодо термінології в тестах — тим краще.
• Розглядайте модульні тести як засіб проти страху рефакторингу.
• Впроваджувати нову культуру тестування у команді чи компанії займає багато часу та зусиль.
• Моки (mocks) корисні в модульному тестуванні — але не треба занадто захоплюватися ними.
• Flaky тести є навіть у Google. Це велика та універсальна проблема, для якої немає легкої та простої відповіді.

Про інструменти

В секції про інструменти автори описуються ряд тулів, якими користуються команди в Google.

З книги ви дізнаєтеся більше про наступне:

• плюси та мінуси різних видів систем контролю версій — та як працює VCS Piper;
• навіщо будувати свою власну пошукову систему для програмного коду;
• якою повинна бути ефективна білд-система у масштабі Google;
• навіщо «заморочуватися» над code review та як це робити правильно;
• як працює інструмент для статичного аналізу коду — Tricorder;
• як виглядають CICD-процеси для десятків тисяч девелоперів, що пишуть код щодня.

Замість висновків

Кожен продукт, проєкт та компанія — унікальні. Дуже складно взяти одні й ті ж інструменти та користуватися ними, де заманеться (зі збереженням тієї самої ефективності).

Але компанії, свою чергою, мають і багато спільного між собою. Усі ми працюємо з комп’ютерами та з людьми.

Книга Software Engineering At Google не містить в собі набору готових рецептів на всі випадки. Вона, скоріше — спроба поділитися тими знаннями та уроками, які інженери накопичили за час існування компанії. Я певен, що кожен може знайти щось цікаве в цих уроках. Хоча б у вигляді натхнення чи нових поглядів на «старі» проблеми.

Кому варто читати цю книгу:

• Якщо ви інженер-розробник (чи тест-інженер) та маєте бажання дізнатися про підходи та інструменти, які дійсно працюють у великій технологічній компанії.

Кому не варто читати цю книгу:

• Якщо ви тільки-но почали свій шлях в IT. Найбільше користі отримають інженери з досвідом — тому початківці, будь ласка, відкладіть цю книгу на декілька років;
• Якщо ви у пошуках «готових» рішень чи покрокових туторіалів для того чи іншого інструменту;
• Якщо ви вважаєте, що ваші робочі задачі не мають абсолютно нічого спільного з задачами Google.

P.S. Крім можливості придбати книгу на Amazon, автори вирішили також поділитися нею безкоштовно та виклали її в HTML-форматі онлайн.

А Ви читали цю книгу? Які Ваші враження від неї? Діліться у коментарях!

Якщо вам подобається обговорювати книжки, запрошую також завтра, 25.01. о 19:00, на войсчат DOU за моєї участі: «Книги для QA. ‘How Google Tests Software’ та інші». До зустрічі!