Чергова книга від 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’ та інші». До зустрічі!

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Бути керівником (лідером)

керівник != лідер
керівник має бути лідером, але лідер не завжди керівник.

Велика дяка за розширення мого беклогу книжок до читання!

дякую за огляд книжки!

Google звільняє інженерів з 20-річним стажем через пошту
www.businessinsider.com/...​l-slap-in-the-face-2023-1
це все що треба знати про гугл

В штатах багато компаній звільняють людей через емейли, це не показник)

А там видать был баш скрипт:
— Удалить все права на список емейлов
— Выслать емейл «это не я плохой — это все рецессия»

Це по суті набір коротких есе, написаних різними інженерами на обрані теми.

Интересно, сколько из них уволили сегодня?)

Астрологи оголосили тиждень жартiв про лейофф гугель)

Не ну чтоб просто знать какие секции книги читать, а какие пропускать)

Интересно, сколько из них уволили сегодня?)

Єдина радість галєрному гребцю

Що за клавіатура на фото?

Ducky One 2.

Підписатись на коментарі