Анатомията на изпращането на софтуер до съвършенство: как прегледът на кода улови това, което тестовете не можаха

За няколко седмици GeekBye изпрати девет издания — от v2.0.0 до v2.0.11 — и тази поредица разказа историята на всяко от тях. Прочетете ги заедно и изпъква модел, който е по-интересен от коя да е отделна грешка: отново и отново дадена поправка минаваше всеки тест на машината на разработчика, а прегледът на кода доказваше, че тя би се провалила за почти всеки друг.

Тази пропаст — между „при мен работи“ и „работи“ — е там, където всъщност живее надеждността. Това е работният процес, който я затваря, и указателят към всяко издание, което той произведе.

Моделът: зелени тестове, грешен отговор

Ето три от най-ясните случаи от поредицата, защото те правят абстрактното конкретно.

• В поправката за заснемане на много монитори (v2.0.10) първата реализация закотвяше заснемането на екрана върху наслагващия прозорец на приложението. Тя минаваше тестването — на машина за разработка с един монитор. Прегледът разсъди къде всъщност живее това наслагване (винаги на основния дисплей, освен ако физически не го издърпаш) и доказа, че „поправката“ би сочила право обратно към грешния монитор за почти всеки реален потребител. Правилната котва — курсорът — излезе от този спор, а не от изпълнение на тест.
• В изданието с резервния вариант през WebSocket (v2.0.8) прегледът установи, че точно тази 403, която връща блокиращо прокси, беше класифицирана като фатална грешка при удостоверяване — така резервният вариант, заради който съществуваше функцията, никога не можеше да се задейства. Функцията щеше да бъде изпратена, да мине тестовете за щастливия път и да не направи нищо за реалната си аудитория.
• В поправката за таймаута при бездействие (v2.0.9) първата версия отбелязваше часовника „все още жив“ вътре в път от кода, който част от транскриптите законно пропускат — този на другия говорещ. Прегледът улови, че бъдеща промяна би могла тихо да върне точно поправяната грешка, и отметката беше преместена някъде безусловно, с тест, който да я държи там.

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

Трите части на портата

Работният процес зад поредицата не е сложен. Той се състои от три навика, прилагани без изключение.

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

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

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

Защо това има по-голямо значение за AI приложение

Има причина тази дисциплина да е неподлежаща на компромис специално за инструмент като GeekBye. Няколко от най-неприятните грешки в поредицата бяха тихо грешни, а не шумно крашещи: снимка на екрана, която подаваше грешния монитор на AI-я (v2.0.10), транскрипция, изкривена към боклукчийски термини, така че „speak“ излизаше като име (v2.0.11), асистент, отговарящ в грешен режим без начин това да се види (v2.0.3 + v2.0.5). Когато приложението ви подава контекст на модел, грешен вход произвежда уверено грешен изход и никаква грешка никъде. Не можете да се измъкнете чрез тестове от провали, които не хвърлят изключение. Трябва да се измъкнете чрез разсъждаване — което е точно за това служи портата на прегледа.

Поредицата, по ред

Всяка от тях е самостоятелен казус за едно издание. Прочетени от началото до края, те са анатомията на превръщането на един продукт от „работи“ в „заслужаващ доверие“.

1. Какво всъщност изисква версия 2: 206 комита честни състояния — v2.0.0. Основата: никога не показвай състояние, което не е вярно.
2. Денят, в който приложението ни DDoS-на само себе си — v2.0.1 + v2.0.4. Изоставане на качванията при стартиране, което смачка собствения ни бекенд, и стълбата на живост, която то наложи.
3. Спокоен софтуер: поправката на трептенето и чипът за режима на отговор — v2.0.3 + v2.0.5. Издания без нови функции, които спечелиха доверие детайл по детайл.
4. Вашето Mac приложение забравя достъпа до микрофона при всяко стартиране — v2.0.6. App Translocation в macOS и изпращането на диагностиката преди поправката.
5. Една CSS променлива, пет кръга преглед и Swift верига от инструменти, която лъжеше — v2.0.7. Равномерна полупрозрачност и двоичен файл, който смени размера си, защото документацията не се съгласяваше със скрипта за налагане.
6. Транскрипция на живо, когато защитната стена блокира WebSockets — v2.0.8. Резервен вариант само през HTTPS и 403, която би го скрила от самия него.
7. Защо вашият AI бележник спира да записва по средата на срещата — v2.0.9. Таймер за бездействие, който можеше да чува само вас, и краш, който можеше да заключи работния ви плот.
8. Защо записът на екрана заснема грешния монитор — v2.0.10. Грешката с грешния дисплей и поправката, която минаваше на един монитор и би се провалила на два.
9. Защо AI транскрипцията разчита погрешно технически термини — v2.0.11. Изкривяване на разпознаването на речта към вашия речник — и регресията, която го влоши, преди да го подобри.

Изводът

Съвършенството не е състояние, което достигаш; то е порта, която поддържаш. Девет издания и същите три въпроса при всяко от тях: за кой случай не се сетихте, приковава ли тест точния провал и излезе ли наистина реален подписан билд? Нищо от това не е бляскаво. Всичко от него е причината GeekBye v2 да усеща като спокоен. Ако изграждате софтуер — AI или друг — преносимата част не е коя да е отделна поправка. Тя е навикът да третираш зелен набор от тестове като началото на спора, а не като неговия край.

Всяко издание по-горе е активно чрез автоматично обновяване. За продукта, до който тези поправки се сумират, вижте какво ново в GeekBye v2.