Index udržovatelnosti (MI) je jednou z nejpoužívanějších kompozitních metrik v měření kvality softwaru. Shrnuje tři strukturální vlastnosti kódu: velikost, složitost a objem, do jediného číselného skóre, které předpovídá, jak těžké bude kód změnit. U moderních programovacích jazyků jsou vzorec, prahové hodnoty a nástroje dobře zavedené. U COBOLu je situace složitější a většina týmů buď použije obecný vzorec bez úprav, nebo kvantitativní měření zcela opustí, protože skóre se nezdá odpovídat tomu, co vývojáři skutečně zažívají.
Oba přístupy vedou k zavádějícím výsledkům. Aplikace standardního vzorce MI na COBOL bez pochopení toho, jak se jeho komponenty chovají v syntaktickém kontextu COBOLu, vede ke systematicky zkresleným skóre, která vykreslují vysoce kvalitní programy jako marginální a nekvalitní programy jako přijatelné. Úplné opuštění měření ponechává rozhodnutí o modernizaci bez kvantitativního základu, který potřebují k obhajobě pro zainteresované strany v podnikání a k upřednostnění sanačních prací před portfoliem tisíců programů.
Získejte kompletní přehled metrik COBOLu
SMART TS XL seřazuje každý program v COBOLu podle složitosti, fan-in a hloubky závislostí JCL současně.
Více informacíSprávná cesta vede k pochopení toho, co konkrétně vzorec MI měří v COBOLu, kde podhodnocuje a kde nadhodnocuje kvalitu, jaké doplňkové metriky korigují jeho specifická slepá místa v COBOLu a jak kalibrovat prahové hodnoty vůči vašemu skutečnému portfoliu, spíše než vůči generickým benchmarkům odvozeným z moderních jazykových kódových základen. Tato příručka pokrývá všechny čtyři aspekty s dostatečnou technickou hloubkou pro implementaci programu COBOL MI a dostatečným praktickým návodem k jeho použití při modernizačních rozhodnutích.
Poslední bod před mechanikou: Index udržovatelnosti se snaží poskytnout holistický pohled na relativní zátěž údržby pro různé části projektu tím, že kombinuje řadu různých metrik. Tento holistický pohled je cenný pro portfolia COBOL právě proto, že žádná jednotlivá metrika nezachycuje celý obraz. Udržovatelnost je výchozím bodem, nikoli celým příběhem, ale tím správným místem, kde začít.
Proč je měření udržovatelnosti pro COBOL důležitější než pro moderní jazyky
Měření udržovatelnosti v kódové základně Javy nebo Pythonu, která je dva roky stará, dobře otestovaná a udržovaná týmem, který ji napsal, poskytuje užitečné informace, ale zřídka je naléhavá. Kód je pro své autory čitelný. Logika je zdokumentovaná nebo odvoditelná z testů. Náklady na změnu jsou omezeny znalostí kódu týmu.
Portfolia COBOL v regulovaných odvětvích se liší ve třech ohledech, díky nimž kvantitativní měření udržovatelnosti není postupem kvality, ale provozní nutností.
Mezera ve znalostech. Většina kódu COBOL obsahuje obchodní logiku, která nikdy nebyla formálně zdokumentována. Dávkové úlohy napsané před desítkami let kódují pravidla, která si nikdo nepamatuje. Vývojáři, kteří dokáží plynně číst kód a přesně odhadnout náklady na změny, odcházejí do důchodu. Vývojáři, kteří zůstávají, mají částečné znalosti o některých částech portfolia. Bez kvantitativních metrik závisí odhad nákladů na změny výhradně na tom, kterého vývojáře se zeptáte, a variabilita těchto odhadů je dostatečně vysoká, aby plánování projektů bylo nespolehlivé.
Problém s rozsahem. Typické portfolio v COBOLu obsahuje tisíce programů, z nichž mnohé nebyly roky dotčeny. Žádný tým nemůže ručně posoudit tisíce programů před zahájením modernizačního programu. Metriky, které lze automaticky vypočítat v celém portfoliu během několika hodin, nahrazují týdny ruční kontroly.
Požadavek obchodního případu. Modernizační programy vyžadují investiční odůvodnění. Vedoucí pracovníci, kteří schvalují modernizační rozpočty v řádu milionů dolarů, chtějí kvantitativní důkazy o tom, že investice je oprávněná. Skóre MI, poměry technického dluhu odvozené z MI a odhady nákladů na změny, které odkazují na prahové hodnoty MI, poskytují tyto důkazy ve formě, kterou lze prezentovat i netechnickým zainteresovaným stranám.
Vzorec MI a jeho komponenty specifické pro COBOL
Nejčastěji používaný vzorec pro výpočet indexu udržovatelnosti je:
MI = 171 - 5.2 × ln(Halstead Volume) - 0.23 × (Cyclomatic Complexity) - 16.2 × ln(Lines of Code)Ohraničená varianta od Microsoftu, používaná většinou komerčních nástrojů, to mapuje na stupnici 0–100:
MI (bounded) = max(0, (171 - 5.2 × ln(HV) - 0.23 × CC - 16.2 × ln(LOC)) × 100 / 171)Každá komponenta má specifické aspekty relevantní pro COBOL.
Řádky kódu v COBOLu
Zdrojové soubory COBOLu obsahují čtyři části: IDENTIFIKACE, PROSTŘEDÍ, DATA a PROCEDURE. DĚLENÍ IDENTIFIKACE identifikuje program. DĚLENÍ PROSTŘEDÍ popisuje jeho běhové prostředí. DĚLENÍ DATA definuje jeho datové struktury. Pouze DĚLENÍ PROCEDURE obsahuje spustitelné příkazy.
Otázka měření: měl by LOC počítat všechny řádky napříč všemi čtyřmi divizemi, nebo pouze příkazy PROCEDURE DIVISION?
Pro účely MI počítání všech řádků (včetně deklarací dat) výrazně zvyšuje LOC bez odpovídajícího zvýšení složitosti provádění. Program v COBOLu se 400 řádky DATA DIVISION definujícími rozvržení záznamů a 100řádkovým PROCEDURE DIVISION má odlišné charakteristiky udržovatelnosti od programu se 100 řádky DATA DIVISION a 400řádkovým PROCEDURE DIVISION, ale nezpracovaná LOC s nimi zachází identicky.
Nejlepší postup: Pro výpočet MI v COBOLu použijte počet příkazů PROCEDURE DIVISION (bez prázdných řádků, řádků komentářů a záhlaví dělení/sekcí/odstavců) namísto celkového počtu řádků zdrojového kódu. To vede k hodnotám LOC, které lépe odpovídají složitosti spustitelného souboru.
Problém s členem COPY: Příkazy COPY zahrnují externí zdrojové členy během kompilace. Příkaz COPY, který se rozšiřuje na 200 řádků definic dat, přispívá do zdrojového souboru jedním řádkem, ale do kompilovaného programu 200 řádky. Některé nástroje počítají logické LOC (rozšíření po kopírování); jiné počítají fyzické zdrojové řádky. Rozdíl může být řádově velký u programů s intenzivním využitím COPY.
Pozor: Pokud váš nástroj MI počítá fyzické zdrojové řádky, programy s rozsáhlým využitím COPY se budou jevit menší a lépe udržovatelné, než ve skutečnosti jsou. Vždy ověřte, zda je LOC ve vašem nástroji expandováno před nebo po kopírování.
Cyklomatická složitost v COBOLu
Cyklomatická složitost je metrika kvality kódu, která měří srozumitelnost a udržovatelnost kódu měřením počtu nezávislých cest tímto kódem. V jazyce COBOL zahrnují rozhodovací struktury, které vytvářejí nezávislé cesty:
| Konstrukce COBOL | Dopad cyklomatické složitosti |
|---|---|
IF ... END-IF | +1 za IF |
IF ... ELSE ... END-IF | +1 za každý IF (ELSE nepřidává další cestu) |
EVALUATE ... WHEN | +1 za každou klauzuli WHEN |
PERFORM UNTIL condition | +1 za každou podmínku UNTIL |
PERFORM VARYING ... WITH TEST BEFORE/AFTER | +1 za VARYING |
AT END klauzule o READ | +1 |
ON EXCEPTION / NOT ON EXCEPTION | +1 za každou obslužnou rutinu výjimky |
ON OVERFLOW / NOT ON OVERFLOW | +1 za obslužnou rutinu přetečení |
ON SIZE ERROR | +1 na obslužnou rutinu chyb velikosti |
Slepé místo 88 úrovní: Názvy podmínek na 88 úrovních v COBOLu vytvářejí logické podmínky, které se objevují v příkazech IF a EVALUATE, ale jsou definovány v DATA DIVISION. Program s dvaceti 88 úrovněmi podmínek, z nichž každá je odkazována ve více rozhodovacích strukturách, má výrazně větší behaviorální složitost, než naznačuje počet příkazů v PROCEDURE DIVISION. Cyklomatická složitost počítá rozhodovací body, ale nedokáže zachytit sémantické vztahy mezi 88 úrovněmi názvů a logikou, která je testuje.
PROVEĎTE SI Implicitní složitost: PERFORM SECTION-A THRU SECTION-Z provede všechny odstavce mezi SEKCÍ A a SEKCÍ Z. Počet odstavců a rozhodovací struktury v nich jsou součástí efektivní složitosti příkazu PERFORM, ale CC vypočítaná na úrovni příkazu zachází PERFORM THRU jako jediná cesta bez ohledu na to, co leží mezi nimi.
Halsteadův objem v COBOLu
Halsteadův objem je míra velikosti a složitosti programu na základě počtu operátorů a operandů. V COBOLu:
Operátory jsou slovesa a klíčová slova v COBOLu: MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN atd.
Operandy jsou názvy dat, literály a obrazné konstanty: datové položky definované v DATA DIVISION, číselné a řetězcové literály a obrazné konstanty COBOLu (MEZERY, NULY, VYSOKÉ HODNOTY, NÍZKÉ HODNOTY).
Faktor výřečnosti: COBOL je pro ekvivalentní logiku výrazně obsáhlejší než moderní jazyky. Výraz v Javě total = quantity * unitPrice * (1 - discount) je jeden řádek se čtyřmi operátory a čtyřmi operandy. Ekvivalent v COBOLu:
cobol
COMPUTE WS-TOTAL = WS-QUANTITY * WS-UNIT-PRICE
* (1 - WS-DISCOUNT)To je zhruba ekvivalentní v operátorech a operandech, ale uvažujme složitější výpočet, který v Javě může použít tři řádky. V COBOLu to může vyžadovat pět nebo více řádků kvůli absenci řetězení výrazů a požadavku na použití mezilehlých pracovních paměťových polí. Halsteadův svazek bude pro COBOL odpovídajícím způsobem vyšší než pro ekvivalentní Javu, jednoduše proto, že COBOL vyjadřuje stejný výpočet s více jazykovými tokeny.
Praktický důsledek: Programy v COBOLu budou mít vyšší Halsteadovy objemy (Halstead Volumes) než programy v moderních jazycích s ekvivalentní logikou. Vyšší Halsteadův objem snižuje MI (Mi). Programy v COBOLu proto budou systematicky skórovat nižší MI než programy v moderních jazycích s ekvivalentní složitostí, ne proto, že by se obtížněji udržovaly, ale proto, že COBOL je syntakticky obsáhlejší.
Kde Standard MI selhává pro COBOL: Čtyři slepá místa
I při správném výpočtu standardní vzorec MI opomíjí čtyři dimenze udržovatelnosti v COBOLu, které mají významný dopad na reálné náklady na změny.
1. KOPIE Spojení prutů
COBOLský sešit zahrnutý ve 300 programech je závislost údržby, která ovlivňuje všech 300 programů, když je v něm provedena jakákoli změna. Toto propojení se neobjevuje v žádné komponentě vzorce MI. Program, který obsahuje dvacet sešitů, má 300 implicitních závislostí, které MI považuje za ekvivalent programu bez sešitů.
Doplňková metrika: Počet závislostí kopírovaných členů, počet unikátních příkazů COPY v DATOVÉ DIVISION programu. Programy s vysokou vazbou COPY vyžadují před jakoukoli změnou analýzu dopadu, aby se zjistilo, které další programy sdílejí stejné definice copybooku.
2. Počet volajících (Fan-In)
Podprogram v COBOLu volaný 150 dalšími programy představuje vysoce rizikový cíl změny bez ohledu na jeho skóre MI. Vysoce udržovatelný podprogram (MI = 85), který je volán 150 programy, je obtížnější bezpečně změnit než špatně udržovatelný nástroj (MI = 45), který nikdo nevolá. Vzorec MI nezohledňuje, jak široce je program používán.
Doplňková metrika: Fan-in, počet odlišných programů, které volají daný program prostřednictvím CALL nebo dynamického odesílání. Fan-in je primárním faktorem rizika změn u podprogramů nezávisle na jejich vnitřní složitosti.
3. Hloubka závislostí JCL
Program v COBOLu volaný úlohou JCL, která má patnáct následných závislých úloh, tedy úloh, které běží po ní a jsou závislé na jejím výstupu, nese operační riziko, které je zcela mimo rozsah MI. Program s MI = 55, který běží samostatně, je méně riskantní pro úpravu než program s MI = 80, který se nachází uprostřed složitého řetězce závislostí v dávkách.
Doplňková metrika: Hloubka závislostí JCL, hloubka následného řetězce závislostí v síti úloh JCL. Programy s vysokou hloubkou závislostí JCL vyžadují širší rozsah testování pro jakoukoli změnu, bez ohledu na jejich interní skóre MI.
4. Inflace mrtvého kódu
Mrtvé odstavce a sekce, kód v COBOLu, který je definován, ale nikdy nevolán žádnou spouštěcí cestou, nafukují LOC a Halsteadův objem, aniž by přispívaly ke zvýšení zátěže údržby živého kódu. Program s 600 řádky mrtvého kódu a 200 řádky živého kódu má MI, který ho penalizuje za mrtvý kód, i když mrtvý kód je irelevantní pro změnu nákladů.
Doplňková metrika: Procento mrtvého kódu, podíl příkazů PROCEDURE DIVISION, které jsou nedosažitelné z jakékoli produkční cesty. Vysoké procento mrtvého kódu naznačuje, že hodnota LOC a objem Halstead vypočítané MI jsou výrazně nadsazené.
Kompletní sada metrik COBOL
Žádná samostatná metrika nezachycuje udržovatelnost COBOLu. Následující sada metrik, použitá společně, poskytuje kompletní obraz:
| metrický | Co to měří | Poznámka specifická pro COBOL | Primární použití |
|---|---|---|---|
| Index udržitelnosti | Celková snadná údržba (kompozit) | Použít pro příkazy PROCEDURE DIVISION; ověřit zpracování COPY | Základní skóre kvality; pořadí portfolia |
| Cyklomatická složitost | Počet nezávislých cest provádění | Zahrnout VYHODNOCENÍ KDY, PROVÁDĚNÍ DO, NA KONCI, PŘI VÝJIMCE | Změna úsilí na program; odhad počtu testovacích případů |
| Halsteadův svazek | Výpočetní zátěž (operátory + operandy) | Očekávejte vyšší hodnoty než ekvivalentní moderní jazykové programy | Součást MI; porovnání mezi programy v rámci portfolia COBOL |
| Počet členů KOPIE | Propojení závislostí prostřednictvím sdílených definic | Programy s >15 členy COPY vyžadují analýzu dopadu před jakoukoli změnou | Klasifikace rizika změny |
| Fan-In (zavolaný) | Kolik programů tohle nazývá | Hlavním faktorem rizika změn u podprogramů | Sekvence migrace; změna prahu autorizace |
| % nefunkčního kódu | Procento nedosažitelných kódů procedur | Nafoukněte LOC/HV, pokud není vyloučeno; vyloučit z rozsahu konverze | Zmenšení rozsahu modernizace |
| Hloubka závislostí JCL | Hloubka řetězce dávkových úloh pro následné úlohy | Nelze vypočítat pouze ze zdrojového kódu COBOL; vyžaduje analýzu JCL | Riziko provozních změn; rozsah testování |
| Vnořená hloubka PERFORM | Maximální úroveň vnoření volání PERFORM | Hluboké vnoření naznačuje strukturální složitost, kterou CC nezachycuje | Priorita refaktoringu |
Kalibrace prahových hodnot pro COBOL
Standardní prahové hodnoty MI jsou odvozeny z moderních jazykových kódových základen a nevztahují se přímo na COBOL. Níže uvedená tabulka porovnává standardní prahové hodnoty s ekvivalenty vhodnými pro COBOL a vysvětluje důvody úpravy.
| Rozsah skóre | Standardní interpretace | Interpretace COBOLu | zdůvodnění |
|---|---|---|---|
| 85-100 | Vysoce udržovatelný | Vysoce udržovatelná (konzistentní) | Nejlepší programy v COBOLu se umístily v tomto rozsahu, čistá struktura, vhodná velikost |
| 65-84 | Středně udržovatelné | Středně snadno udržovatelné, zkontrolujte COPY spojku a zapojení ventilátoru | Standardní prahová hodnota platí, ale doplňkové metriky zde důležitější jsou. |
| 50-64 | Špatné, potřeba refaktoring | Marginální, posuzovat v kontextu | Mnoho dobře strukturovaných programů v COBOLu zde dosahuje bodů už jen díky výřečnosti; k rozlišení skutečných problémů od syntaktických artefaktů použijte CC a fan-in. |
| 25-49 | Velmi špatné | Špatný, pravděpodobně vysoký CC a/nebo nadměrná LOC | Programy v tomto rozsahu spolehlivě indikují strukturální problémy, nejen výřečnost COBOLu |
| 0-24 | Kritický, zásadní refaktoring | Kritické, nejvyšší priorita pro sanaci nebo vyřazení | V souladu se standardní interpretací |
Klíčové pokyny pro kalibraci: Před nastavením prahových hodnot specifických pro daný program spusťte MI napříč celým portfoliem COBOL. Vypočítejte medián portfolia a interkvartilový rozsah. Nastavte si prahovou hodnotu „požadované pozornosti“ na 25. percentil vašeho vlastního portfolia, programy v dolním kvartilu vaší specifické kódové základny, nikoli programy, které dosáhly skóre pod prahovou hodnotou odvozenou z programů v Javě. Tento přístup je samokalibrační a zohledňuje systematický efekt výřečnosti COBOLu.
Využití MI pro modernizační rozhodnutí
Skóre MI se stávají nejcennějšími, když informují o konkrétních provozních rozhodnutích. Zde jsou hlavní aplikace.
Sekvence migračních vln. Programy s vysokým skóre MI (dobře udržované, nízká složitost) jsou nejlepšími kandidáty pro rané migrační vlny. Snazší je validovat, je méně pravděpodobné, že obsahují nezdokumentované okrajové případy a nesou nižší riziko neočekávaného chování v migrovaném prostředí. Programy s nízkým skóre MI by měly migrovat v pozdějších vlnách, poté, co si tým vybuduje zkušenosti a sebevědomí a po důkladné extrakci obchodní logiky.
Prioritizace údržby. Programy s MI pod 25. percentilem, které mají zároveň vysokou míru zadlužení (volá je mnoho programů) nebo vysokou hloubku závislosti na JCL, představují kombinaci s nejvyšším rizikem: strukturálně složité programy, na kterých závisí mnoho dalších programů. Tyto programy s největší pravděpodobností způsobí vady související se změnami a jejich náprava je v případě vzniku nejdražší. Měly by být prvními cíli programu na snižování technického dluhu.
Rozhodnutí o sestavení vs. koupi. Při hodnocení, zda dlouhodobě udržovat program v COBOLu, nebo jej nahradit SaaS či moderní alternativou, poskytují skóre MI a historie nákladů na změny kvantitativní základ pro výpočet sestavení vs. koupě. Program s MI = 30, který byl v posledních třech letech patnáctkrát upraven, přičemž každá úprava trvala výrazně déle, než se odhadovalo, má zdokumentované náklady na údržbu, které lze porovnat s náklady na výměnu.
Prahové hodnoty pro autorizaci změn. Některé organizace používají skóre MI k určení požadované úrovně autorizace změn. Programy pod určitou prahovou hodnotou MI vyžadují před nasazením do produkčního prostředí přísnější kontrolu, nezávislé testování a dodatečné schválení. Tím se vytváří proces řízení změn s ohledem na kvalitu, aniž by bylo nutné každou změnu manuálně posuzovat.
Jedna věc, kterou MI nedokáže: předpovědět dopad změny na podnikání. Program s MI = 85, který provádí výpočty regulatorního kapitálu, vyžaduje alespoň stejné testování a validaci jako program s MI = 40, který provádí funkci reportingu s nízkými sázkami. MI měří úsilí o změnu, nikoli důsledky změny. Pro úplné posouzení rizik jsou nutné oba rozměry.
Jak SMART TS XL Stanovuje a sleduje metriky udržovatelnosti COBOLu
Výpočet MI pro jeden program v COBOLu je přímočarý. Jeho přesný výpočet pro portfolio tisíců programů, zohlednění rozšiřování COPY, identifikace mrtvého kódu a doplnění MI o další metriky, které MI chybí, vyžaduje automatizovanou analýzu ve velkém měřítku.
SMART TS XLJe statická analýza kódu Vypočítává celou sadu metrik COBOL popsanou v této příručce pro celé portfolio současně. MI se vypočítává pomocí počtu příkazů PROCEDURE DIVISION, nikoli celkového počtu řádků zdrojových kódů, přičemž před analýzou se provádí expanze COPY, aby se zajistilo správné přiřazení definic sdílených dat. Cyklomatická složitost zohledňuje klauzule EVALUATE WHEN, podmínky PERFORM UNTIL a větve obslužných rutin výjimek, nikoli pouze příkazy IF. Halstead Volume se vypočítává z COBOL sloves a datových operandů v PROCEDURE DIVISION.
Rozhodující je, SMART TS XL doplňuje MI o metriky, které vzorec postrádá. mapování závislostí aplikací vytváří hodnoty fan-in, počty volání, pro každý program v portfoliu a identifikuje programy s vysokým rizikem bez ohledu na jejich skóre MI. Expanze JCL Tato funkce poskytuje hloubku závislostí JCL pro každý program a propojuje analýzu MI na úrovni COBOLu s kontextem operačního rizika, který dokáže odhalit pouze analýza JCL.
Identifikace mrtvého kódu z analýzy dopadu označuje odstavce a sekce bez vstupních cest pro spuštění, což umožňuje vyloučení mrtvého kódu z výpočtu MI a poskytuje metriku procenta mrtvého kódu, která určuje, zda nízké skóre MI programu odráží skutečnou složitost nebo nadsazenou ztrátu funkčnosti (LOC).
Funkce podnikového vyhledávání umožňuje dotazování na kompletní datovou sadu metrik: v jediném dotazu napříč miliony řádků jazyka COBOL lze nalézt všechny programy s MI pod 40 a fan-in nad 20, seřazené podle hloubky závislostí JCL, cíle nápravy s nejvyšší prioritou v portfoliu. Tento dotazovatelný inventář metrik je základem pro prioritizaci údržby, sekvencování migrací a aplikace autorizace změn popsané výše.
Nakonec MI sledovaný v čase, přepočítávaný po každém cyklu významné změny, ukazuje, zda se program zlepšuje nebo zhoršuje. SMART TS XLAnalýza se spouští na aktuálním zdroji, nikoli na snímcích uložených v mezipaměti, což zajišťuje, že metriky odrážejí skutečný stav kódové základny v době každé analýzy, nikoli hodnocení k určitému bodu v čase, které je zastaralé.
Metriky odpovídající jazyku
Index udržovatelnosti (MI) je platná a cenná metrika pro portfolia COBOL, ale pouze pokud se aplikuje s pochopením toho, jak syntaktické charakteristiky COBOLu interagují s jeho komponentami. Aplikování generických prahových hodnot na programy v COBOLu vede k zavádějícím výsledkům. Doplnění MI o metriky, které postrádá, jako je propojení kopírování (COPY coupling), fan-in, hloubka závislostí JCL a procento mrtvého kódu, vytváří obraz, který odpovídá tomu, co vývojáři skutečně zažívají při práci s portfoliem COBOL.
Organizace, které tyto metriky efektivně využívají, jsou ty, které je vnímají jako výchozí bod pro informovanou diskusi, nikoli jako konečný verdikt o kvalitě programu. Skóre MI je signál. Signál stojí za to sledovat, důsledně ukazuje na programy, jejichž změny jsou drahé, jejichž úpravy jsou riskantní a které stojí za to řešit před zahájením modernizace. MI nemůže nahradit úsudek vývojáře, který čte kód, ani nahradit strukturální analýzu, která odhaluje závislosti a obchodní logiku, kterou žádná jednotlivá metrika nedokáže zachytit.
