Sedm nejvíce otravných problémů v programování

Bylo řečeno, že nezmapovaná území starých map byla často označena zlověstným varováním: „Tady buďte draci.“ Možná apokryfní, myšlenka byla, že nikdo, kdo se potuluje do těchto neznámých koutů světa, by to neměl dělat, aniž by byl připraven bojovat s děsivým nepřítelem. V těchto tajemných oblastech se mohlo stát cokoli a často to nebylo dobré.

Programátoři mohou být o něco civilizovanější než středověcí rytíři, ale to neznamená, že moderní technický svět nemá svůj podíl technických draků, kteří na nás čekají na nepředvídaných místech: Obtížné problémy, které čekají na konečný termín o pár minut; komplikace, které si přečetly příručku a vědí, co není přesně specifikováno; zlí draci, kteří vědí, jak se vplížit do vyvolávajících chyb a předčasných závad, často hned po spáchání kódu.

Budou takoví, kteří v noci tiše odpočívají, zahřátí naivním sebevědomím, že počítače jsou naprosto předvídatelné a vážně chrlí správné odpovědi. Jak málo toho vědí. Přes veškerou tvrdou práci návrhářů čipů, vývojářů jazyků a milionů programátorů všude stále existují trnité houštiny programovacích problémů, které mohou i ty nejsilnější programátory srazit na kolena.

Tady je sedm z nejkrutějších koutů světa programování, kam bychom umístili velké značky s nápisem „Tady buďte draci“.

Multithreading

Znělo to jako dobrý nápad: Rozdělte svůj program do samostatných sekcí a nechte je OS běžet jako samostatné malé programy. Pokud mají procesory čtyři, šest, osm nebo dokonce více jader, proč nenapsat svůj kód tak, aby mohl mít čtyři, šest, osm nebo více vláken pomocí všech jader nezávisle?

Myšlenka funguje - když jsou části ve skutečnosti zcela oddělené a nemají spolu nic společného. Ale jakmile potřebují přístup ke stejným proměnným nebo zápis bitů do stejných souborů, všechny sázky jsou vypnuté. Jedno z vláken se nejprve dostane k datům a nemůžete předvídat, o které vlákno se bude jednat.

Proto vytváříme monitory, semafory a další nástroje pro organizaci vícevláknového nepořádku. Když pracují, pracují. Pouze přidají další vrstvu složitosti a přemění akt ukládání dat do proměnné na položku, která vyžaduje trochu více přemýšlení.

Když nepracují, je to čistý chaos. Data nedávají smysl. Sloupce se nesčítají. Peníze z účtů mizí. Je to všechno v paměti. A hodně štěstí při pokusu něco z toho zjistit. Většinu času vývojáři nakonec uzamknou velké bloky datové struktury, aby se jí mohl dotknout pouze jeden podproces. To může zastavit chaos, ale pouze tím, že zabijete většinu narušení fungování více vláken pracujících na stejných datech. Můžete jej také přepsat jako „jednovláknový“ program.

Uzávěry

Někde v řadě se někdo rozhodl, že by bylo užitečné předávat funkce, jako by šlo o data. V jednoduchých případech to fungovalo dobře, ale programátoři si začali uvědomovat, že nastaly problémy, když se funkce dostaly mimo sebe a přistupovaly k jiným datům, často nazývaným „volné proměnné“. Která verze byla ta správná? Byla to data, když bylo zahájeno volání funkce? Nebo to bylo, když funkce skutečně běží? To je zvláště důležité pro JavaScript, kde mohou být mezi nimi dlouhé mezery.

Řešení, „uzavření“, je jedním z největších zdrojů bolesti hlavy pro programátory JavaScriptu (nyní Java a Swift). Nováčci a dokonce ani mnozí veteráni nemohou přijít na to, co se uzavírá a kde mohou být hranice takzvaného uzavření.

Název nepomůže - není to tak, že přístup je trvale uzavřen jako lišta oznamující poslední hovor. Pokud je to možné, přístup je otevřený, ale pouze prostřednictvím červí díry v datovém kontinuu, podivného mechanismu posunu času, který nakonec vyvine sci-fi televizní show. Ale nazývat jej „Komplexním mechanismem přístupu k zásobníku“ nebo „Systémem kontroly dat“ se zdá být příliš dlouhý, takže jsme uvízli nad „uzávěry“. Nechápejte mě, jestli někdo musí platit za nesvobodné proměnné.

Příliš velká data

Když se RAM začne plnit, všechno se začne zhoršovat. Nezáleží na tom, zda provádíte novou statistickou analýzu spotřebitelských dat nebo pracujete na nudné staré tabulce. Když zařízení dojde RAM, změní se na takzvanou virtuální paměť, která se rozlije na superpevný pevný disk. Je to lepší než úplné zhroucení nebo ukončení práce, ale chlapec všechno zpomaluje.

Problém je v tom, že pevné disky jsou nejméně 20 nebo 30krát pomalejší než RAM a diskové jednotky na velkém trhu jsou často pomalejší. Pokud se o zápis nebo čtení z disku pokouší také nějaký jiný proces, všechno se dramaticky zhorší, protože disky mohou dělat pouze jednu věc najednou.

Aktivace virtuální paměti zhoršuje další skryté problémy s vaším softwarem. Pokud existují závity závitu, začnou se zlomit mnohem rychleji, protože vlákna, která jsou zaseknutá ve virtuální paměti pevného disku, běží mnohem pomaleji než ostatní vlákna. To však trvá jen krátké období, protože jednou se závity wallflower vymění do paměti a ostatní vlákna zavěsí. Pokud je kód dokonalý, výsledek je pouze mnohem pomalejší. Pokud tomu tak není, nedostatky ho rychle pošlou do katastrofy. To je jeden malý příklad.

Správa je skutečnou výzvou pro programátory, kteří pracují s velkými hromadami dat. Kdokoli, kdo bude trochu nedbalý s budováním nehospodárných datových struktur, skončí s kódem, který zpomalí procházení produkce. S několika testovacími případy to může fungovat dobře, ale skutečná zátěž jej posílá spirálovitě do selhání.

NP-kompletní

Každý, kdo má vysokoškolské vzdělání v oboru výpočetní techniky, ví o záhadných problémech zabalených do zkratky, která je zřídka vysvětlena: nedeterministický polynom úplný, alias NP úplný. Podrobnosti se často učí celý semestr, a dokonce i tehdy mnoho studentů CS přichází s mlhavou představou, že tyto problémy nikdo nedokáže vyřešit, protože jsou příliš tvrdé.

NP-úplné problémy jsou často docela obtížné - pokud na ně zaútočíte jednoduše hrubou silou. Například „problém obchodního cestujícího“ může trvat exponenciálně dlouho, protože trasa prodeje zahrnuje stále více měst. Řešení „batohu“ nalezením podmnožiny čísel, která se nejvíce blíží nějaké hodnotě N, se vyřeší vyzkoušením všech možných podmnožin, což je velmi velké číslo. Každý má z těchto problémů strach, protože je dokonalým příkladem jednoho z největších strašidel v Silicon Valley: algoritmy, které se nebudou měnit.

Složitá část spočívá v tom, že některé NP-úplné problémy lze snadno vyřešit aproximací. Algoritmy neslibují přesné řešení, ale dost se blíží. Možná nenajdou ideální cestu pro obchodního cestujícího, ale mohou se dostat do několika procentních bodů od správné odpovědi.

Existence těchto docela dobrých řešení dělá draky ještě tajemnějšími. Nikdo si nemůže být jistý, zda jsou problémy skutečně dost těžké nebo snadné, pokud jste ochotni se uspokojit odpovědí, která je dost dobrá.

Bezpečnostní

"Jsou známa známá; existují věci, o kterých víme, že víme, “řekl jednou na tiskové konferenci ministr obrany Donald Rumsfeld během druhé Bushovy administrativy. "Víme také, že existují známé neznámé; to znamená, že víme, že existují věci, které nevíme. Existují však také neznámé neznámé - ty, které neznáme, neznáme. “

Rumsfeld hovořil o válce v Iráku, ale totéž platí pro počítačovou bezpečnost. Největším problémem jsou díry, o kterých ani nevíme, že jsou možné. Každý chápe, že byste měli heslo těžko uhodnout - to je známé známé. Ale komu kdy bylo řečeno, že váš síťový hardware má uvnitř zakopanou vlastní softwarovou vrstvu? Možnost, že by někdo mohl přeskočit hackování vašeho OS a místo toho cílit na tuto tajnou vrstvu, je neznámá neznámá.

Možnost takového hackování vám teď nemusí být neznámá, ale co když existují další? Nemáme ponětí, jestli dokážeme ztvrdnout díry, o kterých ani nevíme, že existují. Sesbírat hesla můžete, ale existují trhliny, které si ani nedokážete představit. To je zábava z práce s počítačovým zabezpečením. A pokud jde o programování, myšlení zaměřené na bezpečnost je stále důležitější. Nemůžete to nechat na bezpečnostních profesionálech, aby vám uklidili nepořádek.

Šifrování

Šifrování zní mocně a neproniknutelně, když se donucovací orgány dostanou před Kongres a požádají o oficiální mezery, aby to zastavily. Problém je v tom, že většina šifrování je postavena na mlhavém oblaku nejistoty. Jaké matematické důkazy máme, spočívají na nejistých předpokladech, jako je těžké vypočítat opravdu velká čísla nebo vypočítat diskrétní protokol.

Jsou tyto problémy opravdu těžké? Nikdo veřejně nepopsal žádné algoritmy pro jejich porušení, ale to neznamená, že řešení neexistují. Pokud jste našli způsob, jak odposlouchávat každou konverzaci a proniknout do jakékoli banky, okamžitě byste to řekli světu a pomohli byste jim zaplnit díry? Nebo byste mlčel?

Skutečnou výzvou je použití šifrování v našem vlastním kódu. I když věříme, že základní algoritmy jsou zabezpečené, je třeba udělat ještě hodně práce se žonglováním s hesly, klíči a připojeními. Pokud uděláte jednu chybu a necháte heslo nechráněné, vše se otevře.

Správa identit

Každý má rád tuto newyorskou karikaturu s pointou: „Na internetu nikdo neví, že jsi pes.“ Má dokonce vlastní stránku Wikipedia se čtyřmi komplikovanými částmi. (Na internetu nikdo nezná starou pilu o analýze humoru a pitvání žab.)

Dobrou zprávou je, že anonymita může být osvobozující a užitečná. Špatnou zprávou je, že nemáme ponětí, jak dělat cokoli jiného, než anonymní komunikaci. Někteří programátoři hovoří o „dvoufaktorovém ověřování“, ale ti inteligentní přejdou na „ověřování N-faktorem“.

Po hesle a možná i textové zprávě na mobilní telefon nemáme toho moc stabilního. Čtečky otisků prstů vypadají působivě, ale zdá se, že spousta lidí je ochotných prozradit, jak mohou být hacknuti (pro začátečníky zde, zde a zde).

Na světě nečinného chatování na Snapchatu nebo Redditu toho moc nezáleží, ale proud hackovaných stránek na Facebooku je trochu znepokojující. Neexistuje snadný způsob, jak řešit vážné záležitosti, jako je majetek, peníze, zdravotní péče nebo skoro všechno ostatní v životě, kromě nesmyslných malých řečí. Bitcoinové fanbois se rádi plíží o tom, jak blockchain může být pevný, ale mince se nějak vytrhávají (viz zde a zde). Nemáme žádnou skutečnou metodu zacházení s identitou.

Měření tvrdosti

Samozřejmě, pokud jde o programování, existuje vůbec způsob, jak můžeme měřit obtížnost problému? Nikdo opravdu neví. Víme, že některé problémy lze snadno vyřešit, ale je úplně jiné certifikovat jeden jako těžký. Úplnost NP je pouze jednou částí komplikovaného pokusu o kodifikaci složitosti algoritmů a analýzy dat. Tato teorie je užitečná, ale nemůže poskytnout žádné záruky. Je lákavé říci, že je těžké vůbec vědět, zda je problém těžký, ale vtip pochopíte.