Steven
Steven6 мин четене

Какво всъщност представлява едно издание със 127 комита

GeekBye v1.7.0 бяха 127 комита за единайсет дни. Отвън това изглежда като сто дребни неща. Отвътре бяха две големи функции, преплетени една в друга — и едната от тях беше изградена на грешното място, после изтръгната и построена наново по средата на изданието. Ето анатомията на едно голямо издание.

Инженерство
Издание
Архитектура
Издания на GeekBye
Какво всъщност представлява едно издание със 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, който умишлено извиква ефектите двойно в разработка, за да извади наяве бъгове, удвои това отново. Резултатът беше от четири до осем идентични заявки за калибриране, изстрелвани при всяка смяна на екран, достатъчно, за да задействат ограничителя на честотата на сървъра. Поправката консолидира извличането до няколко заявки при монтиране.

Не би могъл да откриеш този бъг, тествайки само калибрирането или само навигацията. Той съществува единствено на шева — там, където се срещат две независимо коректни функции. Това е данъкът, който едно голямо издание налага: последната миля не е изграждането на функциите, а откриването на всичко, което се чупи чак когато най-накрая се озоват в една и съща стая.

Три неща, на които ме научи едно голямо издание

  1. Издание със 127 комита са две или три големи теми, а не сто малки. Намери нишките. Работата — и рискът — живеят в това как се преплитат, а не в броя.
  2. Сложи source of truth там, където казва договорът, още първия път. Изтрихме 680 реда, премествайки калибрирането от клиент на backend. Локалната пряка пътека е преработка, която си планирал предварително; архитектурата вече ти беше казала отговора.
  3. Интеграцията изважда наяве провали, които изолацията не може. Бурята от 429 живееше на шева между две коректни функции и се появи едва когато заработиха заедно. Заложи в бюджета интеграционен преход, а не само тестване по отделни функции.

Това е братовчед от ерата на v1 на история, която бихме разказали отново в много по-голям мащаб — виж какво всъщност изисква една версия 2: 206 комита от честни състояния (v2.0.0), където същата истина „голямо число всъщност са няколко големи идеи" се разиграва из целия v2 пренапис. За предишната глава в историята на v1, как да предаваш поточно доклад на живо без трептене (v1.6.13); а за цялата дъга, анатомията на доставянето на софтуер до съвършенство.

Свързани статии

Изваждане на backend-а от пътя на качването
Steven
Steven8 мин четене

Изваждане на backend-а от пътя на качването

GeekBye записва екрана ти и запазва видеото в твоя Google Drive. Първата версия прекарваше всеки запис през собствените сървъри на GeekBye по пътя натам; едно издание по-късно, файлът тръгваше директно от машината ти към Drive, а backend-ът беше понижен до това да държи един-единствен указател. Интересната част е колко малко код всъщност съдържа „директната, resumable" версия — защото resumability дойде от изтриването на един proxy, не от написването на такъв.

Инженерство
Архитектура
Desktop
Една кодова база, две приложения: как да направиш white-label без fork
Steven
Steven5 мин четене

Една кодова база, две приложения: как да направиш white-label без fork

GeekBye и Pavleur са две различно брандирани десктоп приложения, изградени от едно-единствено хранилище — без fork, без дублирана кодова база. Ето машинарията по време на build, която компилира една кодова база в два продукта, и бъгът от един ред, заради който второто ни приложение се представяше с грешното име.

Инженерство
Архитектура
Build
Тишината беше носеща
Steven
Steven7 мин четене

Тишината беше носеща

Последните две издания на GeekBye v1 са за една и съща неудобна истина: транскрипцията в реално време през реална мрежа не е без загуби, а честният ход е да спреш да се преструваш, че е. v1.8.20 запази на диска копие на всеки аудио фрагмент, преди да го изхвърли по време на повторно свързване, и започна да маркира на глас пропуските в транскрипцията. v1.9.0 спря да изпраща тишина, за да пести честотна лента — и откри, че тишината беше точно сигналът, който транскрайбърът използваше, за да знае, че изречението е свършило. Две издания за цената на изхвърлянето на неща.

Инженерство
Audio
Надеждност