Moje odkazy
Obsah článku:
Komplexita softwaru: Co to je a proč představuje problém?
vydáno: 29. 2. 2020 23:45, aktualizováno: 10. 11. 2023 01:05
Když dělník kope příkop nebo zedník staví zeď, má se za to, že každý metr představuje část hotové práce a budoucí užitek. Jistě, občas se stane, že se příkop nebo zeď udělají někde jinde, než měly být, nicméně to není moc časté a tyto chyby se obvykle rychle odhalí. Ale když programátor píše (či jinak vnáší) kód zapojený do výsledného produktu, nemůžeme říci, že bychom se s každým dalším řádkem kódu blížili cíli. Spojitost mezi množstvím kódu a budoucí užitečností je velice nejistá.
Ba naopak – množství zdrojového kódu je třeba vnímat spíše jako negativní hodnotu a budoucí náklad, než jako hotový díl práce (pozitivní hodnota). Pokrok můžeme měřit množstvím implementovaných požadavků, ale určitě ne množstvím kódu.
Co je to komplexita?
Složitost programu, informačního systému nebo obecně softwaru má více podob. Základní a snadno měřitelnou veličinou je počet řádků kódu (anglicky source lines of code – SLOC, LOC). Jednoduše projdeme zdrojové soubory, spočítáme řádky kódu, prázdné řádky a řádky komentářů a výsledek seskupíme podle programovacích jazyků. Samozřejmě to nebudeme dělat ručně a použijeme nějaký nástroj jako třeba příkaz cloc. Jeho výstup vypadá např. takto:
-------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- C/C++ Header 14 305 328 1261 C++ 4 79 132 335 Java 2 59 63 334 Bourne Again Shell 10 125 190 279 XML 2 5 34 140 Bourne Shell 2 24 38 127 make 1 8 14 19 CMake 2 7 33 19 -------------------------------------------------------------------------------- SUM: 37 612 832 2514 --------------------------------------------------------------------------------
Existují i metodiky a nástroje, které se snaží z těchto hodnot odhadnout množství investovaných člověkoroků a náklady na vytvoření daného softwaru. Takovým nástrojem je např. příkaz sloccount, jehož výstup může vypadat takto:
Categorizing files. Finding a working MD5 command.... Found a working MD5 command. Computing results. SLOC Directory SLOC-by-Language (Sorted) 1212 src_top_dir cpp=1212 1077 streamlet-examples cpp=384,sh=359,java=334 140 nbproject xml=140 54 top_dir sh=54 0 license (none) Totals grouped by language (dominant language first): cpp: 1596 (64.28%) sh: 413 (16.63%) java: 334 (13.45%) xml: 140 (5.64%) Total Physical Source Lines of Code (SLOC) = 2,483 Development Effort Estimate, Person-Years (Person-Months) = 0.52 (6.24) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.42 (5.01) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 1.24 Total Estimated Cost to Develop = $ 70,205 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL. SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to redistribute it under certain conditions as specified by the GNU GPL license; see the documentation for details. Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
Tento příkaz má řadu parametrů, kterými lze upravit jeho chování, nicméně odhad nákladů vynaložených v minulosti nepovažuji za až tak zajímavý. I kdybychom software prodávali, má na jeho cenu mnohem větší vliv jeho budoucí užitečnost, než dříve investované náklady. Ta odhadnutá částka může mít smysl tak leda pro ověření, zda někdo příliš nenadhodnocuje svoje aktiva. Ale to už je trochu mimo záběr tohoto článku – nás zde zajímá komplexita z pohledu budoucího rozvoje softwaru a jeho vlastností.
Metoda počítání řádků je poměrně nedokonalá a nepřesná. Jednak jde o to, že většina jazyků umožňuje zapsat na jeden řádek více příkazů (takový Perl je svými one-linery vyloženě slavný), takže pouhou změnou formátování lze podstatně ovlivnit výsledek měření, aniž by došlo k nějakým faktickým změnám. Pokud např. jeden programátor rád používá ternární operátory nebo píše if/else větve a for cykly na jeden řádek, budou jeho počty řádků vypadat jinak, než u programátora, který rád všechno odsadí a píše na samostatné řádky, přestože komplexita jejich programů bude srovnatelná. Mimochodem, ve svojí bakalářce na téma Získávání informací ze systémů na správu verzí jsem upozorňoval právě na riziko, že pokud by byli programátoři hodnoceni podle množství kódu, mohlo by to ovlivnit jejich styl psaní a nic dobrého by to nepřineslo.
Problém s odlišnými styly a formátováním můžeme vyřešit tím, že místo řádků kódu budeme počítat tzv. cyklomatickou složitost. Tato metoda vyžaduje, aby nástroj rozuměl danému programovacímu jazyku a zdrojový kód rozebral a sestavil z něj strom uzlů (větvení, cykly, volání funkcí…). Program, který neobsahuje žádné větvení ani cyklus a lze ho projít jen jedním způsobem, má složitost 1. S rostoucím počtem uzlů a hran v grafu složitost programu roste. Při použití této metody je pak jedno, jak kdo kód naformátoval a kolik příkazů vměstnal na jeden řádek. Na druhou stranu výpočet cyklomatické složitosti je výrazně náročnější operace než prosté spočítání řádků.
Další problém pak spočívá v tom, že počty řádků je těžké srovnávat napříč jazyky. Např. těchto osm řádků v SQL:
SELECT
table_catalog AS catalog,
table_schema AS schema,
table_name AS name,
table_type = 'BASE TABLE' AS is_table,
is_insertable_into = 'YES' AS is_insertable
FROM information_schema.tables
WHERE table_schema NOT IN ('pg_catalog', 'information_schema');
představuje nenáročný a snadno čitelný kód. Zatímco nad těmito pěti řádky v jazyce C je potřeba přemýšlet o něco déle:
if ( !strchr(string, '"') && !strchr(string, ',') && !strchr(string, '\n')
&& string[0] != ' ' && string[strlen(string)-1] != ' ' ) {
strcpy( csv, string );
return csv;
}
Z tohoto důvodu můžeme chtít počty řádků násobit nějakými koeficienty pro daný jazyk, abychom získali srovnatelnější čísla. Případně můžeme používat i různé koeficienty pro různé knihovny, frameworky, různě starý kód nebo kód různých autorů či týmů.
Nicméně pro získání hrubé představy nemusíme počítat ani cyklomatickou složitost ani používat koeficienty a stačí nám prosté zjištění počtu řádků kódu.
Daleko důležitější je zohlednit složitost závislostí. V době sestavení závisí program na kompilátoru (např. GCC nebo OpenJDK) a v době běhu závisí typicky na standardní knihovně případně běhovém prostředí. To jsou běžně minimální závislosti. Kromě toho programy často závisí na různých knihovnách a frameworcích, na externích komponentách, síťových službách či konfiguraci. Pokud nějaký program vyčlení část svého kódu do samostatné knihovny, celková komplexita se tím bezprostředně nesníží – při hodnocení je potřeba počítat jak komplexitu samotného programu, tak knihoven (resp. všech jeho závislostí). V našem zájmu je minimalizovat závislosti a tím snížit komplexitu. Na druhou stranu jedno ze základních doporučení softwarového inženýrství je: znovupoužitelnost. Kód by se pokud možno neměl opakovat a kopírovat, ale měl by se napsat jen jednou a opakovaně používat tam, kde řešíme stejnou úlohu. O tom, jak skloubit oboje dohromady, ještě bude řeč.
Existují závislosti, kterých se nemusíme příliš obávat. Do této kategorie patří jednak knihovny s velmi nízkou komplexitou a jednak velmi rozšířené knihovny (či obecně software) od známých autorů. Záviset na knihovně, která má v lepším případě pár stovek, v horším pár tisíc, řádků, není velký problém, protože i kdyby v ní byly chyby a i kdyby o ni původní autor ztratil zájem, můžeme vývoj převzít a chyby opravovat sami. S rostoucí komplexitou knihovny je potřeba pečlivěji zvažovat, zda nám případná práce a riziko stojí za to. Naopak u knihoven a programů, které jsou hodně rozšířené, je riziko, že bychom vývoj museli táhnout sami, poměrně malé. Pokud stejný software jako my používá i mnoho bank, velkých podniků a institucí, široká internetová komunita atd., tak se nemusíme příliš obávat, že by vývoj takového programu jen tak skončil. Naopak můžeme předpokládat, že zde bude velký tlak na hledání chyb a jejich následnou opravu. V takovém případě můžeme být tolerantnější k vyšší komplexitě. Byť i tady se vyplatí přemýšlet a nepoužívat složitý software lehkovážně, jen proto, že ho „přece používají všichni“. A i zde se najdou výjimky, kdy nějaká chyba v hojně používaném softwaru hnije dlouhé roky, aniž by na ni někdo upozornil (ale možná o ní někdo ví a zneužívá ji – pak ale stejný problém mají i ty banky, velké podniky a státní instituce a jsme s nimi tzv. na jedné lodi).
Na druhé straně jsou pak závislosti, kterým bychom se měli raději vyhnout: komplexnější software od méně známých autorů či méně používaný. Jeho vývoj bychom rozhodně nechtěli přebírat (trávit čas studiem velkého množství kódu) a zároveň ani nemůžeme čekat, že by nám s tím někdo pomohl (jsme jedni z mála uživatelů daného softwaru). Také riziko, že původní autor skončí s vývojem, je vyšší.
Kromě počtu řádků (či uzlů a hran grafu) jsou tu i další faktory ovlivňující komplexitu resp. to, jak náročná práce s daným kódem bude. Dobře strukturovaný program s rozumnou architekturou bude stravitelnější – stačí pochopit základní koncepty a následně v něm už budeme nacházet opakující se návrhové vzory, u kterých nemusíme kód detailně zkoumat, abychom měli představu, co dělá a na co autor při jeho psaní myslel. Oproti tomu nekoncepční kód psaný nesourodým stylem či různými autory resp. nedisciplinovaným týmem, bude záludnější a hůře proniknutelný (i kdyby měl méně řádek). I taková poměrně kosmetická věc jako konvence psaní kódu (formátování, názvy atd.) hraje roli.
Na škodu je i příliš velká pestrost a různorodost technologií. Ono je sice fajn používat pro každou úlohu ten nejvhodnější nástroj či programovací jazyk (např. dotazy do databáze budeme radši psát v deklarativním SQL než v procedurálním céčku), ale na druhé straně je vyšší množství technologií překážkou a zvyšuje nároky na toho, kdo má s kódem pracovat. Udržovat program psaný v pěti různých jazycích bude náročnější a budeme na to hůř shánět lidi, ve srovnání s programem psaným třeba jen ve dvou jazycích. Totéž platí o různých frameworcích či knihovnách – každá další technologie navíc zvyšuje komplexitu, a je proto nežádoucí (neplatí to absolutně, ale měli bychom mít jistotu, že zvýšení komplexity je vyváženo odpovídajícími přínosy).
Proč představuje problém?
Komplexita systému má řadu negativních dopadů. Obvykle se projevují nepřímo a se zpožděním a nebývá jednoduché si je spojit s konkrétní příčinou. To někdy vede k falešným nadějím v řešení, která ve skutečnosti řešením nejsou (např. přidání dalšího nástroje či technologie) a problém spíše prohlubují.
Začneme otázkou bezpečnosti: program může obsahovat záměrně vložené chyby tzv. zadní vrátka, která do něj vložil autor – ať už z vlastní vůle nebo na nátlak někoho jiného (tajné služby, nadřízení atd.). Čím komplexnější program je, tím je větší šance, že se tuto vadu podaří utajit a útočník ji bude moci zneužívat proti uživatelům. Jakkoli to může znít paranoidně, tohle se skutečně děje.
Dále se pak v programech vyskytují neúmyslné chyby, které lze použít k DoS útoku nebo třeba k eskalaci práv či vzdálenému spuštění kódu. Autor je tam nedal schválně, ale bezpečnostní riziko je to stejné. Komplexní software je jednak náchylnější ke vzniku takových chyb a jednak se v něm tyto chyby hůře hledají. Bezpečnostní audit komplexního systému bude dražší.
I když nejde o bezpečnost, komplexita zvyšuje chybovost, což pro uživatele znamená např. nestabilitu, ztrátu dat nebo nesprávné výpočty. Bezpečnostní a jiné chyby se nevyhýbají ani hardwaru, jako jsou komplexní procesory.
Oprava chyby může často spočívat v úpravě jednoho jediného řádku kódu – ale hledáním toho správného řádku můžeme klidně strávit dlouhé dny. Čím je program složitější, tím déle typicky nalezení daného místa v kódu trvá. V důsledku to znamená dražší opravy chyb. Stejně tak k implementování nového změnového požadavku či nové funkce je potřeba přečíst a pochopit větší množství kódu – tzn. dražší rozvoj.
Počítače obvykle považujeme za deterministické stroje – měly by se chovat předvídatelně a na stejný vstup vracet vždy stejnou odpověď. Oproti tomu takový hod kostkou považujeme za náhodný. Z pohledu laika tohle úplně neplatilo nikdy – uživatelé občas nechápou, co se uvnitř děje a tvrdí, že si počítač dělá, co chce. Nicméně stačí, aby přišel zkušenější administrátor nebo přinejhorším programátor, a dokáže situaci analyzovat, chování systému rozklíčovat a vysvětlit. Takový systém můžeme stále považovat za deterministický – je v lidských silách ho v rozumném čase pochopit a chování objasnit. Je ale hod kostkou skutečně náhodný? Pokud bychom kostkou házeli vždy pod stejným úhlem, stejnou silou, na podložku ze stejného materiálu a i další předpoklady jako např. proudění a složení vzduchu by byly stejné, mělo by padat pořád stejné číslo. Pokud bychom dokázali zajistit dokonale stejné vstupy, byl by i hod kostkou deterministický. Koncept náhody je tak vlastně jen jakási naše abstrakce a zkratka – místo toho, abychom zkoumali všechny vstupy (čehož u té kostky buď nejsme schopní nebo se nám to nechce dělat), tak prohlásíme daný systém za náhodný, nedeterministický. S rostoucí komplexitou počítačových systémů se posouváme směrem k tomu hodu kostkou – vstupů a vnitřních stavů bude tolik, že přestane být v lidských silách situaci v rozumném čase analyzovat a systém prohlásíme za nedeterministický. Ona známá věta „Zkoušeli jste to vypnout a zapnout?“ je předzvěstí této změny – i odborník rezignuje na hledání příčiny a restartem se pokouší dostat systém do známého stavu. Variací tohoto přístupu je naformátování disku a přeinstalace systému. V některých případech je to správné řešení (např. když zaměstnanec vrací počítač, který pak chceme dát někomu dalšímu – nebudeme zkoumat, co tam dotyčný prováděl, a vracet to zpátky – raději uděláme čistou instalaci). Ale neměl by se z toho stát obecný princip nebo dokonce jediná možnost. Neustálé zvyšování komplexity je nejlepší způsob, jak posunout náš obor od exaktní vědy směrem k jakési mytologii či náboženství, kdy budeme kolem počítačů zapalovat svíčky, pořádat obřady a modlit se, protože nám nic jiného nezbude – protože racionální a exaktní prozkoumání všech vstupů a vnitřního stavu nebude v rozumném čase možné. Teoreticky by mohla pomoci umělá inteligence, která by mohla některé části analýzy počítačových systémů řešit rychleji než člověk, ale tím akorát celý problém posouváme ještě o úroveň dál. (nicméně i toto se už dnes děje a AI se někdy používá k řešení problémů, které by šlo řešit snížením komplexity a zjednodušením systémů)
A na závěr tu máme vyšší hardwarové nároky. Ačkoli dnes nejde o prvořadý problém (v 80. a 90. letech byly výkonnostní optimalizace mnohem důležitější i u relativně jednoduchých programů) a dnešní HW zvládne provozovat i velmi komplexní a ledabyle napsané aplikace uspokojivě rychle, neměli bychom tento aspekt úplně ignorovat. Stačí se podívat, jak moc vzrostla velikost pamětí, takty procesoru, počty jader, velikosti disků či rychlosti sítí atd. od takových 80. let (procesor 386 pochází z roku 1985), a zamyslet se, zda pomocí dnešních počítačů řešíme skutečně o tolik řádů složitější úlohy (někdy ano, často ne). Nevolám po předčasných optimalizacích a dokud hardwaru stačí dech, tak je lepší upřednostnit správnost, bezpečnost a čitelnost před rychlostí. Ale když nám začne např. po spuštění pár „desktopových“ (ve skutečnosti zamaskovaných webových) aplikací docházet paměť i ve výkonné pracovní stanici nebo baterka v notebooku, jedná se už o reálný problém způsobený nadměrnou komplexitou (která, jak jsme si uvedli výše, neprospívá ani té bezpečnosti a čitelnosti/udržovatelnosti).
Proč by komplexita měla zajímat i neprogramátory?
Většina neprogramátorů o nadbytečné komplexitě počítačových systémů vůbec neví, nepovažuje ji za problém, nebo k tomu přistupuje stylem: neumím programovat a program dlouhý tisíc řádků je pro mne stejně nečitelný, jako program dlouhý milion řádků, takže je to vlastně jedno. Ale ono to jedno není. Neprogramátoři (uživatelé) mají nějaká očekávání a nároky na informační systémy. A aby je mohli realizovat, jsou odkázáni na pomoc programátorů, kterým musí za jejich práci buď zaplatit nebo je motivovat jinak. Tudíž, pokud je něco (komplexita) problém pro programátora, bude to v konečném důsledku problém i pro neprogramátora – bude muset za úpravu, opravu či rozšíření softwaru zaplatit víc peněz a čekat delší dobu.
Co se týče té jiné motivace: ve světě svobodného softwaru dostanou uživatelé řadu oprav a vylepšení jen tak a zadarmo. Viz také Motivy pro psaní svobodného softwaru. Nicméně pokud bude software příliš komplexní a opravy či vylepšení příliš pracné, bude tato motivace nižší, a tím pádem je menší pravděpodobnost, že uživatel dostane něco zadarmo (protože programátor by to udělal jen tak nebo v rámci nějaké jiné práce, kterou dělá nezávisle na tom).
Časová dimenze
Význam komplexity se může v průběhu životního cyklu produktu zásadně proměnit a to, co bylo v určitých fázích přijatelné nás může později paralyzovat. U jednoho zákazníka jsem se např. setkal se systémem, který vznikal před zhruba dvaceti lety. Když ho tehdy vyvíjeli, měli stabilní tým několika vývojářů, kteří se tomuto projektu věnovali naplno. I po letech bylo pod historickým nánosem vidět, že původní architektura byla celkem slušná a že ten systém navrhoval někdo inteligentní, kdo nad věcmi přemýšlel. Zároveň z toho návrhu byl ale cítit i jakýsi implicitní předpoklad toho, že mají svůj stabilní tým a velké ambice, předpokládají, že se produkt bude dobře prodávat a průběžně rozvíjet a že se díky tomu ten tým udrží a bude na produktu stále několik lidí pracovat naplno. Kdyby vývoj pokračoval v tomto režimu, tak by bylo vše v pořádku a ten sofistikovanější komplexnější návrh by přinášel svoje ovoce, úspory z rozsahu a další výhody. Situace se ale postupně měnila (což mohlo souviset spíš obchodní politikou či stavem trhu, než s produktem jako takovým), nových zákazníků moc nepřibývalo a ti stávající nepoptávali příliš mnoho nových funkcí. V důsledku toho se tým redukoval, z původních lidí tam nezůstal nikdo a nakonec na projektu nepracoval naplno ani jeden vývojář (protože změnových požadavků bylo málo), tudíž produkt ani nikdo pořádně neznal a nerozuměl mu. Když už nějaká poptávka na změnu přišla (třeba jednou či dvakrát do roka), musel se hledat vývojář, který se v kódu zorientuje a změnu do něj zapracuje. I kdyby to byl pokaždé ten samý člověk (ve skutečnosti to byl spíš náhodný vývojář z jiného projektu), tak by stejně při této frekvenci změn vždy pozapomněl, co se naučil minule, a pracoval by neefektivně. Implementace i poměrně triviálních požadavků tak byla drahá a trvala dlouho, což zase vedlo k tomu, že zákazníci poptávali méně změn. Jinak řečeno: snížení počtu změnových požadavků vedlo k nižší efektivitě vývoje – a neefektivní vývoj zase vedl ke snížení počtu změnových požadavků. Tím se kruh uzavřel resp. roztočila se spirála a produkt šel ke dnu (byť v nějaké podobě přežívá dodnes, ale žádná sláva ani radost to není).
Ponaučení, které z toho plyne, je, že při návrhu softwaru je potřeba zohlednit i předpokládaný budoucí styl a rozsah vývoje a přizpůsobit mu komplexitu návrhu. Pokud např. máme na začátku pět geniálních programátorů, kteří si hravě poradí i s vysoce komplexním systémem, neznamená to, že bychom měli jít až nadoraz a dotáhnout komplexitu na maximum, kterého jsou daní lidé schopní. Chceme-li vytvořit systém, který tu bude i za deset či dvacet let a bude se úspěšně rozvíjet (ne jen přežívat), tak musíme počítat s tím, že tu budou i období, kdy se danému produktu nebude trvale věnovat nikdo a bude potřeba si půjčovat náhodné vývojáře z jiných projektů, nebo že se tým obmění a budou na produktu pracovat méně zkušení vývojáři. Tohle má šanci ustát software, jehož návrh stojí nohama na zemi a nelétá hlavou někde v oblacích a u kterého jsme se nevykašlali na dokumentaci a nenechali si přerůst technologický dluh přes hlavu (tzn. průběžně investovat do údržby a ne jen krátkozrace implementovat momentální požadavky). Sám vím, že udržet v počáteční fázi kreativitu na uzdě a nenechat se strhnout radostí z nových technologií a nástrojů není úplně lehké. Nicméně měli bychom si tohoto fenoménu být vědomi a umět s ním pracovat.
Poznámka: Vedle toho existují i jiné druhy softwaru – pokud např. vyrábíte věci, které se za půl roku či za rok zahodí a nikdo si na ně už nevzpomene, tak tam je to asi jedno a nemusíte se těmito otázkami trápit. Mne ale zajímá spíš trvanlivější dlouhodobě udržitelný software, a tak píši primárně z jeho pohledu.
Komplexita v jiných oborech
Postavit dům, který má dva metry široké zdi asi dnes jen tak někoho nenapadne. Stejně tak asi nikdo nebude spojovat dva kusy železa pomocí dvaceti šroubů, když stačí čtyři. Taky asi nikdo nebude bezdůvodně přidávat do barvy zlato nebo na sebe vrstvit dvacet různých nátěrů, když to nemá na výsledné vlastnosti výrobku zásadní pozitivní dopad. V materiálních oborech, jako je stavebnictví nebo strojnictví, je přirozený tlak na zjednodušování výrobků a postupů, protože každá cihla nebo šroub něco stojí, stejně tak každé vrtání díry nebo nanášení nátěru představuje bezprostřední náklady.
Oproti tomu v nemateriálních oborech, jako je softwarové inženýrství, tato přirozená regulace chybí. Kód se dá kopírovat zadarmo, komplexitu lze zvyšovat a přidávat závislosti či vazby, aniž by to přineslo bezprostřední náklady, kterých by si někdo všiml a zastavil to. Ty vyšší náklady se projeví až v následném provozu a při údržbě, kdy už je ale na zjednodušení systému pozdě a zpětně ho nelze snadno provést.
Podobně funguje i právo – právní či daňový řád nebo smluvní podmínky lze snadno rozšiřovat a zvyšovat jejich komplexitu – potištěný papír skoro nic nestojí a soubory na disku jsou ještě levnější. Právníci tak zamořují naše prostředí dalšími a dalšími texty a zvyšují komplexitu systému, což přináší celé společnosti náklady (a právníkům práci). A stejně jako v softwaru můžou být (neúmyslné i úmyslné) bezpečností chyby, tak i v zákonech a smlouvách bývají díry, které lze zneužívat. Čím komplexnější systém je, tím je šance na odhalení takových chyb menší.
Závěr a pokračování
Gratuluji, pokud jste toto komplexní a nekonstruktivní lamentování nad komplexitou dočetli až sem. Brzy vyjdou další dva díly – druhý díl bude věnován příčinám vzniku komplexity a třetí díl možným řešením a prevenci. Předem varuji, že jednoduchá řešení tohoto problému neexistují a rychlé recepty nefungují. Některá doporučení jdou proti sobě a je třeba mezi nimi hledat rovnováhu. Celá tato trojice článků je tedy koncipována spíše jako podklad k dalšímu přemýšlení než jako přímočarý postup řešení, který by stačilo mechanicky aplikovat.
Témata: [počítačová bezpečnost] [softwarové inženýrství] [softwarová architektura]
Komentáře čtenářů
Zacal jsem cist web a pak mne zaujala reklama. Nalepka na rozpad EU. A tim moje cteni vlastne skoncilo. Dal uz cist nebudu. Jeste jsem se premohl abych napsal tento komentar ale dekuji. Ne. Clovek co nedokaze rozlisit politiku od prace a necha se zvyklat ruskou propagandou asi nebude moct odbornik ani na jine veci.
Kde je reklama na zrušení EU? Bohužel ji nikde nevidím, což mne mrzí. Ne že bych se až tak zanášel myšlenkami na likvidaci Unie, ale líbí se mi, když někdo projeví svůj názor, je mi to sympatické.