7 věcí, které byste měli vědět o své aplikaci

1. Základní identita

Název, krátký popis, autor a licence — to jsou první údaje, které chcete mít po ruce. Pokud jste v aplikaci, kterou neznáte, pomůže vám toto rychlé seznámení se ihned zorientovat. Jednoduše zjistíte, jestli jde o interní nástroj, komerční produkt nebo cizí kód, který jen udržujete.

2. Jak aplikace vznikla

Pokud vznikla (i jen zčásti) s pomocí AI nástroje, uložte si odkazy na AI projekt nebo archív promptů. Usnadní to pozdější rozhodování a pokud váš AI agent zdrojový kód dostatečně dobře nekomentuje, vyčtete z původních promptů i funkčnost, kterou jste po AI chtěli vytvořit.

Zadávací dokumentace, úvodní studie, analýzy, architektonická rozhodnutí — všechny tyto informace jsou zrádné v tom, že v době jejich vzniku jsou všechny samozřejmé. Pokud vše pečlivě dokumentujete, máte téměř vyhráno. Zajistěte snadnou dostupnost dokumentace všem zainteresovaným stranám. A podstatná je i informace, že dokumentace existuje, i když k ní nemáte přístup!

3. Zdrojový kód a architektura

Odkaz na repozitář nebo repozitáře, různé pomocné skripty a nástroje, které projekt využívá.

Vývojář toto ví vždy, vždy umí najít projekt v Githubu, Azure DevOps, Gitlabu nebo jiném hostingu. Ale pokud spravujete desítky nebo stovky projektů, které mají různé kódové označení nebo původní pracovní názvy, může být orientace v repozitáři složitá a s časem se situace jen zhoršuje. Když si repo připojíte přímo k aplikaci, zjednodušíte si život a ušetříte si čas a nervy.

4. Dokumentace a API

Technická dokumentace, specifikace a popis API — ne proto, aby existovaly formálně, ale aby je někdo skutečně našel, když je potřebuje.

Jasně, Swagger přece stačí, když k základní URL přidáme `/swagger`. A taky všechno máme v Postmanu, takže stačí otevřít správnou kolekci. Ale co když udržujete více verzí API, dokumentace je v externí službě a zrovna u tohoto projektu jste již použili Bruno namísto Postmana, protože plánujete přejít? Přidáním odkazů k aplikaci zamezíte nejasnostem a zmatkům.

5. Kde a v jakých prostředích běží

Produkce, staging, testovací prostředí — kde běží, kdo je hostuje a jaká verze je zrovna nasazená.

Pokud nasazujete na více prostředí, ať už ručně nebo pomocí CI/CD, tyto informace už zcela určitě máte. Respektive vaši DevOps je mají. A měli by je mít i vaši zákazníci, kolegové z podpory a další, kteří s aplikací pracují. Usnadňuje to totiž řešení problémů, plánování nových funkcí a kontrolu, že všichni mají tu správnou verzi. A věřte nebo ne, je krásné, když z jednoho místa vidíte, jaké všechny verze máte nasazené na všech prostředích všech vašich zákazníků.

6. Úkoly, podpora, monitoring

Kam se hlásí brouci (bugy), kde se sleduje backlog a kam se obrací uživatel s problémem?

Odkazy na dashboard monitorovacího systému, systému na správu úkolů a podporu uživatelů - i kdyby se jednalo jen o aplikaci pro interní potřebu a používalo ji jen pár lidí ve firmě, přidejte do aplikace alespoň e-mail nebo libovolný kontakt na tu správnou osobu. A pokud máte Jiru, YouTrack nebo jiný helpdesk, doplňte do aplikace rovnou odkaz na zadání nového požadavku.

7. Zabezpečení, právo a byznys

Pokud publikujete aplikaci veřejně, nevyhnete se GDPR, obchodním podmínkám a různým dalším popisům provozu aplikace.

Má aplikace specifické bezpečnostní požadavky? Jaké jsou právní podmínky provozu? Jaké jsou obchodní podmínky a licenční ujednání? Kdo je zodpovědný za provoz a údržbu aplikace? Tyhle informace se vyplatí mít po ruce, je to jako mít pojistku — neoceníte ji každý den, ale když nastane problém, budete rádi, že ji máte.