Кент Бек — один із ключових людей, які сформували сучасну інженерію: Extreme Programming, TDD, JUnit, Agile Manifesto. Та, опинившись у Facebook у 2010‑х, він потрапив у середовище, де юніт‑тести практично не писали, а код масштабувався й деплоївся на сотні мільйонів користувачів щодня. У розмові в подкасті The Pragmatic Engineer Бек розклав по поличках, чому це працювало, якою була реальна «сітка безпеки» компанії — і чому більшість організацій не можуть просто відмовитися від тестів, пославшись на приклад Facebook.
«Клас танго — повний, клас Excel — повний, а на TDD не прийшов ніхто»
Перший культурний шок Бека в Facebook був дуже простим: тестів майже не було.
Коли він приїхав у компанію, його «пробою пера» мав стати внутрішній хакатон. Під хакатони традиційно організовували серію міні‑курсів, і Бек вирішив зробити те, що виглядало абсолютно логічно з його досвідом: запропонував клас з test‑driven development.
У списку занять поряд стояли «аргентинське танго» та «просунутий Excel». Коли настав час, картина виявилася промовистою. «Коли час настав, клас аргентинського танго був повний, клас Excel був повний, і ніхто, жоден, навіть „з жалю“, не записався на мій TDD‑клас», — згадує він.
До того моменту Бек уже встиг помітити: юніт‑тести у Facebook — рідкість. Для людини, яка допомогла перетворити TDD на еталон професійної практики, це було не просто дивно, а й тривожно. Проте замість того, щоб читати нотації, він прийняв радикальне рішення: «я просто забуду все, що, як мені здається, знаю про software engineering, і спробую робити те, що роблять вони». Далі почалося уважне вивчення того, на чому реально трималася якість у компанії.
Девмашина як живий сайт: перший рівень фідбеку
Базовий шар безпеки у Facebook будувався не на тестах, а на швидкості замкнутого циклу «зміна — результат». Кожен інженер мав локальне середовище, яке фактично запускало Facebook.
«Розробницькі машини запускали сайт… ти міг змінити синій на зелений і побачити результат за секунди… це дає один рівень фідбеку», — пояснює Бек.
PHP, відсутність важких компіляційних кроків і локальний клон продакшн‑середовища дозволяли буквально відчути систему. Інженер міг експериментувати зі змінами інтерфейсу або логіки і миттєво бачити наслідки на «справжньому» сайті, тільки ізольованому. Це не гарантувало відсутності помилок, але давало потужний інструмент для розуміння коду й поведінки продукту без проміжних бар’єрів.
У класичному TDD цю роль відіграє цикл «написав тест — побачив, як він падає — зробив зелений». У Facebook місце швидкого зворотного звʼязку займала сама система, що працювала прямо на девмашині.
Код‑ревʼю, внутрішній rollout і «Facebook як власний продукт»
Наступний щабель — людський і користувацький фідбек. Зміни проходили крізь кілька щільних сит.
По‑перше, обовʼязковий code review. Навіть без формалізованих юніт‑тестів це створювало ще один барʼєр для грубих помилок і дивних рішень.
По‑друге, внутрішній rollout. Facebook масово використовували всередині — і як особистий продукт, і як інструмент для внутрішнього бізнесу. «Потім внутрішній rollout… кожен користувався Facebook для персонального й внутрішнього бізнесу, тож будь-яку фічу починали юзати миттєво», — описує Бек.
Це означало, що щойно фіча потрапляла в «внутрішній прод», її миттєво підхоплювали тисячі колег. Будь‑який дивний UX, випадкове ламання сценарію чи непродумана взаємодія ставали помітними буквально в перші години. Для компанії, де співробітники є водночас і масою ранніх користувачів, внутрішнє розгортання перетворюється на потужну реальну тестову площадку.
Цей шар фідбеку не замінює формальний coverage, але створює надзвичайно щільне поле «живих тестів» — людей, залучених у роботу через продукт.
Поетапний реліз і «blast radius» у кілька мільйонів
Далі включався продакшн‑контур. Facebook ніколи не викочував зміни одним ударом на всю базу користувачів. Система деплою будувалася навколо принципу обмеженого радіуса ураження.
«Ми мали поетапний rollout, де ти починаєш розгортання… якщо є проблема, blast radius обмежений кількома мільйонами людей, а не всіма», — каже Бек.
У практиці це означало: якщо фіча або зміна викликали проблеми на ранній хвилі розгортання, її можна було зупинити або відкрутити назад, перш ніж помилка перетвориться на глобальний інцидент. Цей шар відігравав ту саму роль, яку у світі з масовими тестами виконують складні pipelines із канарейками та автоматичним моніторингом: помилки виявлялися на маленьких підмножинах користувачів, а не на всьому трафіку.
За спиною інженерів працювала команда деплою під керівництвом Чака Россі, яка додавала ще один рівень контролю — вже не технічного, а соціально‑процедурного.
Зірочки Чака Россі: «якщо ти одна зірка, ти просто не можеш запушити»
У системі деплою було закладено дуже просту, але жорстку модель довіри. «У деплоймент‑команди Чака Россі були зірочки… якщо ти три зірки, вони не дивляться на твій код, якщо одна — ти просто не можеш запушити», — розповідає Бек.
Цей рейтинг був внутрішнім, його не афішували. Але він безпосередньо впливав на те, як саме проходив код інженера в продакшн:
- розробники з високим рівнем довіри могли деплоїти швидше, без детальної перевірки деплой-команди;
- для тих, хто мав низький рейтинг, фактично стояла заборона на пуш у продакшн.
Фактично, це був ще один шар фільтрації: навіть якщо локальні перевірки, ревʼю та внутрішній rollout не вловлювали проблему, уразливі з точки зору ризику люди просто не могли самостійно протиснути небезпечний код.
Цікаво, що довіра тут була не декларативною, а формалізованою в процесі. Замість того щоб «усі рівні перед продакшном», Facebook закладав асиметрію: чим більше історія безпечних й успішних деплоїв, тим менше тертя між інженером і продом — і навпаки.
Інцидент‑ревʼю щопʼятниці: фідбек, від якого холодіє в спині
Останній, найжорсткіший рівень фідбеку включався вже після того, як щось пішло не так. Якщо зміни провокували інцидент, їх автор опинявся перед найсильнішою аудиторією компанії.
«Ще один рівень фідбеку був incident review… щоп’ятниці найсеньйорніші люди збирались, і будь-хто, хто спричинив інцидент, мав прийти і пояснити таймлайн… якщо ти казав „ops зробили це“, тебе могли буквально провести до дверей», — згадує Бек.
Ключові елементи цієї практики:
- публічність: перед старшими лідерами потрібно було покроково розібрати, що сталося;
- фокус на навчанні: що зрозуміли, що зроблять, аби це ніколи не повторилося;
- нульова толерантність до перекладання відповідальності: спроба «списати» на іншу команду могла закінчитися миттєвим розставанням із компанією.
Це створювало дуже потужний культурний сигнал: помилятися дозволено, приховувати або відштовхувати помилку — ні. Інцидент‑ревʼю не замінювало інші бар’єри, але робило одне — гарантувало, що ті самі проблеми не виникатимуть повторно, а люди серйозно ставитимуться до наслідків своїх змін.
Чи могли б тести зробити краще? Навіть Бек з ними «повісив сайт»
На тлі всієї цієї архітектури фідбеку природно виникає питання: а хіба юніт‑тести не зробили б усе ще надійнішим? Бек відповідає на це дуже обережно.
«Unit‑тести могли б бути кращими, можливо… я написав їх для першої фічі й все одно спричинив site event, бо був інший зв’язаний код, який я не знайшов», — визнає він.
Цей епізод добре показує обмеження юніт‑тестів у великій, щільно зв’язаній системі. Навіть ретельно покривши свій модуль тестами, інженер може не помітити складні залежності або бічні ефекти в іншій частині коду. У Facebook, де зміни прокочувалися крізь багатошарову матрицю середовищ і людей, це виявлялось у вигляді site event — але водночас саме шари фідбеку дозволяли швидко виявити й локалізувати проблему.
Для Бека це стало ілюстрацією: тести — не магічний щит. Вони один із можливих шарів фідбеку, і в певних умовах компанія може побудувати іншу, теж працездатну конфігурацію шарів — як це зробив Facebook.
Чому цей підхід не масштабується на «звичайні» компанії
Зі сторони така історія виглядає спокусливо: «якщо Facebook зміг обійтися без юніт‑тестів, то, можливо, й нам не обовʼязково витрачати на них час». Бек, по суті, застерігає від подібних висновків.
Те, що працювало у Facebook, спиралося на кілька специфічних передумов, які він окреслює в інших фрагментах розмови:
- надзвичайно розвинена інфраструктура деплоїв і спостереження;
- культура, де інженерія мала величезний вплив і швидко отримувала фідбек;
- готовність компанії будувати жорсткі соціальні механізми — від «зірочок» до інцидент‑ревʼю з найстаршими лідерами;
- масштаб користувацької бази, який робив поетапні розгортання статистично ефективними.
Більшість організацій не мають ані такої внутрішньої культури, ані подібних інструментів. Вони не можуть дозволити собі свідомо знімати один зі щільних шарів контролю — юніт‑тести — без того, щоб компенсувати його чимось на тому ж рівні зрілості. Інакше замість багатошарової «швейцарської сітки безпеки» виходить сир без шарів: діри безпосередньо над дірами.
Facebook у часи, коли там працював Бек, показав, що можна побудувати працюючу екосистему якості без масових юніт‑тестів. Але показав і інше: таке рішення вимагає гігантських інвестицій в інші типи фідбеку — технічні, організаційні, культурні. І просто викреслити TDD з процесу, прикриваючись великим ім’ям, — найшвидший шлях не до Facebook‑масштабів, а до Facebook‑масштабних аварій без Facebook‑масштабної здатності їх гасити.
Висновок
Історія Кента Бека у Facebook — не про те, що юніт‑тести «не потрібні». Вона про інше: про те, що якість у великих продуктах народжується не з єдиного ритуалу (TDD, code review чи автоматизовані тести), а з сукупності шарів фідбеку, які разом утворюють захисну сітку.
Facebook на початку 2010‑х побудував цю сітку з девмашин, які запускали справжній сайт; з живої внутрішньої аудиторії; з поетапних релізів; із рейтингу довіри до інженерів; з безкомпромісного розбору інцидентів. Така конструкція дозволила компанії йти швидко, масштабуватися та залишатися відносно стабільною — попри брак юніт‑тестів.
Для індустрії це швидше попередження, ніж рецепт: перш ніж відмовлятися від класичних практик на кшталт TDD, потрібно чесно відповісти, чи є у вас настільки ж сильні, послідовні й болючі механізми фідбеку, які їх замінять. У Facebook вони були. У більшості — ні.
Джерело
Повна розмова: How Kent Beck shapes the software engineering industry