4 kontroly, než náš kód zamíří do produkce

Napsat kód je jen jeden dílek vývoje. Stejně důležité je ověřit, na co všechno má daná změna dopad.

Vezměme běžný požadavek: do e-shopu má přibýt nový stav objednávky, třeba částečně expedováno. Doplnit ho do administrace je práce na chvíli. Jenže s tím stavem musí umět pracovat i sklad, musí na něj reagovat notifikace zákazníkovi, musí ho správně zařadit export do účetnictví a musí se objevit ve filtrech a reportech.

Když se na jedno z těch míst zapomene, nemusí to být na první pohled patrné. Projeví se to až později: objednávka se neobjeví v exportu, zákazník nedostane zprávu, kterou čeká. Odhalit všechny takové vazby bývá i pro zkušeného vývojáře obtížné, zvlášť u systému, který roste roky.

Proto jsme cestu každé změny rozdělili do čtyř kontrol a tři z nich svěřili nástrojům. Prochází jimi úplně všechno, od nové funkce po opravu textu na tlačítku.

1. Statická analýza a testy před odesláním

První kontrola proběhne ještě předtím, než vývojář svoji práci odešle do repozitáře. Lokálně se mu spustí statická analýza a sada automatizovaných testů, konkrétní nástroje se liší podle technologie projektu.

Statická analýza čte kód, aniž by aplikaci spouštěla, a hledá v něm nesrovnalosti: nekonzistentní datové typy, neošetřené stavy, situace, se kterými kód nepočítá. Testy pak ověřují chování na stovkách předem popsaných scénářů, například že zlevněné zboží se slevovým kupónem má vyjít na konkrétní částku.

Dokud obojí neproběhne čistě, změna se do repozitáře vůbec nedostane. Zůstává u vývojáře, dokud ji neopraví.

Do dalších kontrol tak vstupuje kód, který už prošel základním ověřením, a revize se můžou věnovat obsahu místo formalit.

2. Automatická revize kódu nástrojem CodeRabbit

Jakmile změna dorazí do repozitáře jako návrh ke schválení, pustí se na ni CodeRabbit. Přečte si ji v kontextu celého projektu a zaměří se na kvalitu kódu: jestli se něco neřeší zbytečně složitě, jestli není nějaká část napsaná špatně nebo duplicitně a jestli jsou ošetřené i okrajové situace, na které se při psaní snadno zapomene.

Samostatnou kategorií je bezpečnost. Tady je nástroj spolehlivější než člověk, protože typické zranitelnosti hledá u každé jednotlivé změny a nikdy je nepřeskočí: neošetřený vstup od uživatele, chybějící kontrolu oprávnění, citlivé údaje v logu nebo v odpovědi rozhraní, knihovnu se známou zranitelností.

S CodeRabbitem se přitom dá o připomínkách diskutovat přímo v komentářích: obhájit vlastní řešení, doptat se na důvod, vyžádat si alternativu. Je to plnohodnotná odborná revize, na kterou se nečeká, až si na ni kolega vyhradí čas mezi vlastními úkoly. Proběhne během minut.

Součástí CodeRabbitu je i Change Stack, rozhraní pro procházení změny. Místo abecedního seznamu souborů poskládá úpravu do skupin podle toho, co spolu souvisí, a seřadí je v pořadí, ve kterém se to dobře čte: nejdřív ukáže, jak se změnila samotná data, a teprve pak místa, která s nimi pracují. Ke každému úseku napíše shrnutí běžným jazykem a kde to dává smysl, doplní i diagram. Ocení to hlavně člověk, který dělá závěrečné review a nemusí si dohledávat, co s čím souvisí.

Aby byly jeho připomínky k věci, museli jsme si nejdřív pořádně nadefinovat vlastní konvence a standardy. Ty jsme mu popsali a průběžně je doplňujeme, takže dnes měří přesně tou laťkou, kterou si nastavujeme.

3. Obchodní revize agentem Nordee

Pro třetí kontrolu jsme si vytvořili vlastního agenta. Nordee staví na Hermesu napojený na AI model a dostane zadání úkolu i hotovou změnu. Nezabývá se kvalitou kódu, tu má změna za sebou z předchozích kontrol, ale business logikou. Řeší jedinou otázku: odpovídá odvedená práce tomu, co se mělo udělat?

Ptá se tedy jinak než technická revize. Pokrývá změna celé zadání, nebo jen jeho část? Když do systému přibyl nový stav objednávky, počítá s ním i sklad, notifikace a účetní export? Nevzniká někde nesoulad mezi dvěma místy, která mají počítat totéž? Když si Nordee není jistý, položí otázku a čeká na odpověď. I s ním se dá o připomínkách diskutovat a doplnit mu kontext, který nemá.

Tuhle otázku si běžně klade až produkťák nebo klient při přebírání hotové práce. Když se tam ukáže, že něco nesedí se zadáním, vrací se změna na začátek. Nordee tuhle otázku položí hned po dokončení práce, takže se případný nesoulad vyřeší ještě před předáním a samotné převzetí je pak rychlejší.

Důvěřujeme, ale prověřujeme

Poslední kontrolu dělá jeden z nás. Díky Change Stacku nezačíná u prázdného seznamu souborů, ale u změny poskládané do souvislostí a s připomínkami z předchozích kontrol na svém místě. Nezůstává ale jen u čtení: úpravu si spustí a vyzkouší, jestli se chová tak, jak má. Teprve pak rozhoduje, jestli ji schválí, nebo vrátí k dopracování.

Žádný z nástrojů v předchozích třech kontrolách nic sám neschvaluje ani nenasazuje. Jejich úkolem je odbavit rutinu a upozornit na rizika.

Jaké jsou hlavní přínosy?

• Kratší cesta k nasazení. Rutinní připomínky odbaví nástroje během minut a šetří čas.
• Stejná laťka pro každou změnu. Drobná oprava projde stejně rozsáhlou kontrolou jako komplexní nová funkce.
• Bezpečnost u každé změny. Neřeší se nárazově při auditu, ale průběžně, protože každá nová funkce je nová plocha k prověření.

Za tímhle procesem stojí jednoduchá úvaha. Čím dřív se na nesrovnalost přijde, tím snáz se řeší, a nejlepší je ta, která se do produkce vůbec nedostane. O to nám jde především: řešit takové věci před nasazením, ne až po něm.

Chcete se na svůj projekt podívat společně s námi? Ozvěte se na info@nordbrains.cz a domluvíme nezávaznou konzultaci.