Що насправді являє собою реліз із 127 комітів

Є версія цього допису, яка просто перелічує все в GeekBye v1.7.0 — перероблений головний екран, процес калібрування, згортувану бічну панель, нові налаштування і так далі. Вона була б точною і нічого б вас не навчила. Бо чесна історія релізу із 127 комітів — це не список. Це форма.

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

Нитка перша: калібрування

Першою ниткою було калібрування — голосова AI-оцінка ваших комунікативних навичок. Ви починаєте живу розмову з AI «кар'єрним коучем», проходите структурований набір фаз (розминка, поведінкова, технічна комунікація, реакція під тиском, постановка цілей), а в кінці отримуєте оцінку за шістьма вимірами: впевненість, ясність, конкретність, залученість, самовладання, релевантність. Під капотом воно вимірює й конкретні метрики мовлення — темп говоріння, частоту слів-паразитів, чи читаються ваші паузи як стратегічні, чи як невпевнені.

Результат — це не оцінка, це відправна точка. Калібрування видає ваші сильні сторони, зони зростання і — що критично важливо — рекомендований рівень складності, з якого варто почати практикуватися. Воно калібрує те, де продукт має вас зустріти. Кожна навичка повертається розгортуваною карткою зворотного зв'язку з резюме, конкретною пропозицією і реальною цитатою з вашої власної розмови як прикладом. Це функція, поверх якої побудовано весь інший досвід практики.

Нитка друга: ціле нове вікно

Другою ниткою був преміум-редизайн — і назвати це редизайном означає його недооцінити. Це було не перефарбування наявних екранів; це було по суті друге вікно застосунку, розгорнуте в шість явних фаз: згортувана бічна панель у стилі Notion, випадне меню в шапці, що замінило старий список сесій, навігація у стилі браузера з історією та хлібними крихтами і преміум-переробки екранів Home, Профілі, Зустрічі й Налаштування.

Дві великі функції. Ось чим насправді були 127 комітів. І найважчою частиною їхнього випуску було не написання будь-якої з них — це було переплетення. Обидві гілки були взаємозалежні; одну злили в другу, а гілці калібрування довелося підтягнути основну гілку чотири окремі рази лише для того, щоб не вийти із синхронізації, поки редизайн рухався під нею. Кількість комітів — це не ціна великого релізу. Ціна — це довгоживучі гілки й порядок інтеграції.

Частина, заради якої варто читати: ми побудували калібрування не в тому місці

Ось помилка, і вона хороша саме тим, що така поширена.

У GeekBye є жорстке архітектурне правило: усі операції AI живуть на бекенді. Клієнт — це тонка оболонка, яка розмовляє із сервером. Усі це знали.

І все ж калібрування спершу побудували в локальній базі даних клієнта. Окрема таблиця, міграція бази даних, репозиторій на 254 рядки, обробники IPC і банк оцінювальних питань на 515 рядків — усе живе на машині користувача. Воно працювало. І воно ж тихо порушувало контракт, на якому побудовано весь застосунок.

Через три дні один коміт видалив 680 рядків у восьми файлах, щоб перенести все це на бекенд, де дані калібрування стали повноцінною серверною моделлю, а логіка питань і підрахунок балів стали турботою сервера. Інший коміт видалив клієнтський банк питань на 515 рядків цілком. Дифф майже кумедний: одна вставка, шістсот вісімдесят видалень.

Ніхто не збирався писати 680 рядків одноразового коду. Це сталося так, як це завжди стається: зріз кута на боці клієнта прямо тут, прототипувати локально швидше, а «перенесемо на бекенд пізніше» здається нешкідливим. Але коли ваша архітектура вже каже вам, де живе джерело істини, будувати це деінде — не зріз кута, це переробка, яку ви заздалегідь запланували собі самі. Урок, який залишився: покладіть це туди, де каже контракт, з першого разу, навіть коли локальну версію швидше підняти.

Баг, який могла знайти лише інтеграція

Ще одна розписка, бо це фірмовий режим відмови великих релізів. Щойно калібрування й нову навігацію з'єднали разом і вони реально запрацювали, застосунок почав спрацьовувати на ліміт частоти запитів — HTTP 429 — без очевидної причини.

Причина була суто інтеграційною. Статус калібрування запитувався на рівні компонента, тому кожна навігація запитувала його заново — а суворий режим React, який навмисно двічі викликає ефекти в розробці, щоб виявити баги, подвоїв це ще раз. Результатом були від чотирьох до восьми однакових запитів калібрування, що вистрілювали при кожній зміні екрана, — достатньо, щоб спрацював обмежувач частоти сервера. Виправлення консолідувало отримання даних до пари викликів при монтуванні.

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

Три речі, яких навчив великий реліз

1. Реліз із 127 комітів — це дві-три великі теми, а не сотня дрібних. Знайдіть нитки. Робота — і ризик — живуть у тому, як вони переплітаються, а не в кількості.
2. Покладіть джерело істини туди, де каже контракт, з першого разу. Ми видалили 680 рядків, переносячи калібрування з клієнта на бекенд. Локальний зріз кута — це переробка, запланована заздалегідь; архітектура вже дала вам відповідь.
3. Інтеграція виявляє відмови, недоступні ізоляції. Шторм 429 жив на шві між двома коректними функціями і з'явився лише тоді, коли вони запрацювали разом. Закладіть бюджет на інтеграційний прохід, а не лише на тестування кожної функції окремо.

Це родич епохи v1 історії, яку ми розповіли б знову в значно більшому масштабі, — див. що насправді потребує друга версія: 206 комітів чесних станів (v2.0.0), де та сама істина «велике число — це насправді пара великих ідей» розігрується в усьому переписуванні v2. За попередній розділ історії v1 див. як транслювати звіт у реальному часі без мерехтіння (v1.6.13); а за всю дугу — анатомію доведення ПЗ до досконалості.