Какво всъщност представлява едно издание със 127 комита
GeekBye v1.7.0 бяха 127 комита за единайсет дни. Отвън това изглежда като сто дребни неща. Отвътре бяха две големи функции, преплетени една в друга — и едната от тях беше изградена на грешното място, после изтръгната и построена наново по средата на изданието. Ето анатомията на едно голямо издание.
Има версия на този блог пост, която просто изброява всичко в GeekBye v1.7.0 — преработен начален екран, поток за калибриране, сгъваем страничен панел, нови настройки и така нататък. Тя би била точна и не би те научила на нищо. Защото честната история на едно издание със 127 комита не е списъкът. Тя е формата.
Ето формата. Сто двайсет и седем комита звучат като сто двайсет и седем дребни неща. Почти никога не е така. v1.7.0 бяха две големи функции, изградени паралелно на дългоживеещи клонове за около единайсет дни, преплетени в самия край. Да разбереш едно голямо издание означава да разбереш тези две нишки — и единственото място, където изградихме нещо на грешния кът и трябваше да го изтръгнем обратно по средата на полета.
Нишка едно: калибриране
Първата нишка беше калибрирането — AI гласова оценка на комуникационните ти умения. Започваш разговор на живо с AI „кариерен коуч", преминаваш през структуриран набор от фази (загрявка, поведенческа, техническа комуникация, реакция под напрежение, поставяне на цели), а накрая получаваш оценка по шест измерения: увереност, яснота, конкретност, ангажираност, самообладание, релевантност. Отдолу тя измерва и конкретни речеви показатели — темпото ти на говорене, честотата на думите паразити, дали паузите ти се четат като стратегически или колебливи.
Резултатът не е оценка, а отправна точка. Калибрирането извежда силните ти страни, зоните ти за растеж и — което е ключово — препоръчана трудност, от която да започнеш да практикуваш. То калибрира къде продуктът трябва да те посрещне. Всяко умение се връща като разгъваща се карта с обратна връзка, съдържаща обобщение, конкретно предложение и реален цитиран ред от собствения ти разговор като пример. Това е функцията, върху която е изградено останалото от практическото изживяване.
Нишка две: цял нов прозорец
Втората нишка беше premium редизайн — и да го наречем редизайн е подценяване. Не беше просто нова визия на съществуващите екрани; беше на практика втори прозорец на приложението, изграден в шест изрични фази: сгъваем страничен панел в стил Notion, падащо меню в хедъра, което замени стария списък със сесии, навигация в стил браузър с история и трохи, и premium преизграждания на Начало, Профили, Срещи и Настройки.
Две големи функции. Ето какво всъщност бяха 127 комита. И най-трудната част от доставянето им не беше писането на нито една от тях — беше преплитането. Двата клона бяха взаимозависими; единият беше слят в другия, а клонът за калибриране трябваше да изтегли main клона четири отделни пъти само за да не се разсинхронизира, докато редизайнът се движеше под него. Броят на комитите не е цената на едно голямо издание. Дългоживеещите клонове и редът на интеграция са.
Частта, заслужаваща да се прочете: изградихме калибрирането на грешното място
Ето грешката, и тя е добра, защото е толкова разпространена.
GeekBye има твърдо архитектурно правило: всички AI операции живеят на backend. Клиентът е тънка обвивка, която говори със сървър. Всички го знаеха.
И въпреки това калибрирането първо беше изградено в локалната база данни на клиента. Специална таблица, миграция на базата данни, 254-редово repository, IPC handler-и и 515-редов набор от въпроси за оценка — всичко живеещо на машината на потребителя. Работеше. Също така тихомълком нарушаваше договора, върху който е изградено цялото приложение.
Три дни по-късно един комит изтри 680 реда в осем файла, за да премести всичко на backend, където данните от калибрирането станаха истински модел от страна на сървъра, а логиката с въпросите и оценяването станаха грижа на сървъра. Друг комит изтри 515-редовия клиентски набор от въпроси изцяло. Дифът е почти забавен: едно вмъкване, шестстотин и осемдесет изтривания.
Никой не си постави за цел да напише 680 реда код за изхвърляне. Стана така, както винаги става това: клиентската пряка пътека е точно там, по-бързо е да прототипираш локално, а „ще го преместим на backend по-късно" изглежда безобидно. Но когато архитектурата ти вече ти казва къде живее source of truth, изграждането му където и да е другаде не е пряка пътека — това е преработка, която сам си си планирал предварително. Урокът, който остана: сложи го там, където казва договорът, още първия път, дори когато локалната версия се вдига по-бързо.
Бъгът, който само интеграцията можеше да открие
Още едно доказателство, защото това е характерният режим на провал на големите издания. След като калибрирането и новата навигация бяха свързани и наистина работеха, приложението започна да задейства ограничение на честотата — HTTP 429 — без очевидна причина.
Причината беше чиста интеграция. Статусът на калибрирането се извличаше на ниво компонент, така че всяка навигация го извличаше отново — а strict режимът на React, който умишлено извиква ефектите двойно в разработка, за да извади наяве бъгове, удвои това отново. Резултатът беше от четири до осем идентични заявки за калибриране, изстрелвани при всяка смяна на екран, достатъчно, за да задействат ограничителя на честотата на сървъра. Поправката консолидира извличането до няколко заявки при монтиране.
Не би могъл да откриеш този бъг, тествайки само калибрирането или само навигацията. Той съществува единствено на шева — там, където се срещат две независимо коректни функции. Това е данъкът, който едно голямо издание налага: последната миля не е изграждането на функциите, а откриването на всичко, което се чупи чак когато най-накрая се озоват в една и съща стая.
Три неща, на които ме научи едно голямо издание
- Издание със 127 комита са две или три големи теми, а не сто малки. Намери нишките. Работата — и рискът — живеят в това как се преплитат, а не в броя.
- Сложи source of truth там, където казва договорът, още първия път. Изтрихме 680 реда, премествайки калибрирането от клиент на backend. Локалната пряка пътека е преработка, която си планирал предварително; архитектурата вече ти беше казала отговора.
- Интеграцията изважда наяве провали, които изолацията не може. Бурята от 429 живееше на шева между две коректни функции и се появи едва когато заработиха заедно. Заложи в бюджета интеграционен преход, а не само тестване по отделни функции.
Това е братовчед от ерата на v1 на история, която бихме разказали отново в много по-голям мащаб — виж какво всъщност изисква една версия 2: 206 комита от честни състояния (v2.0.0), където същата истина „голямо число всъщност са няколко големи идеи" се разиграва из целия v2 пренапис. За предишната глава в историята на v1, как да предаваш поточно доклад на живо без трептене (v1.6.13); а за цялата дъга, анатомията на доставянето на софтуер до съвършенство.
