7 visnepatīkamākās problēmas programmēšanā

Ir teikts, ka veco karšu nezīmētās teritorijas bieži tika apzīmētas ar draudīgu brīdinājumu: "Šeit ir pūķi". Varbūt apokrifs, ideja bija tāda, ka nevienam, kurš klīst šajos nezināmos pasaules nostūros, tas jādara, nebūdams gatavs cīnīties ar drausmīgu ienaidnieku. Šajos noslēpumainajos reģionos varēja notikt jebkas, un bieži vien viss nebija labi.

Programmētāji var būt nedaudz civilizētāki nekā viduslaiku bruņinieki, taču tas nenozīmē, ka mūsdienu tehniskajā pasaulē nav sava daļa tehnisko pūķu, kas mūs gaida neparedzētās vietās: sarežģītas problēmas, kas gaida līdz termiņa beigām ir minūtes; komplikācijas, kas ir izlasījušas rokasgrāmatu un zina, kas nav precīzi norādīts; ļaunie pūķi, kuri zina, kā ielīst collas kļūdās un nelaikā, parasti uzreiz pēc koda izdošanas.

Būs daži, kas naktīs mierīgi atpūšas, apsildīti ar savu naivo pašpārliecinātību, ka datori ir pilnīgi paredzami, nopietni sakustinot pareizās atbildes. Ak, cik maz viņi zina. Par visu čipu dizaineru, valodu izstrādātāju un miljonu programmētāju smago darbu visur joprojām pastāv sarežģītas programmēšanas problēmu biezokņi, kas pat visvarenākos programmētājus var nogāzt uz ceļiem.

Šeit ir septiņi no visgrūtākajiem programmēšanas pasaules nostūriem, kur mēs ievietotu lielus marķierus ar tekstu: "Šeit ir pūķi".

Daudzsavienojums

Tas izklausījās kā laba ideja: sadaliet programmu atsevišķās sadaļās un ļaujiet OS palaist tās kā atsevišķas mazas programmas. Ja procesoriem ir četri, seši, astoņi vai pat vairāk kodolu, kāpēc gan nerakstīt kodu tā, lai tajā varētu būt četri, seši, astoņi vai vairāk pavedieni, neatkarīgi izmantojot visus kodolus?

Ideja darbojas - kad daļas faktiski ir pilnīgi atsevišķas un tām nav nekā kopīga. Bet, tiklīdz viņiem ir jāpiekļūst vieniem un tiem pašiem mainīgajiem vai jāraksta biti vieniem un tiem pašiem failiem, visas likmes tiek izslēgtas. Viens no pavedieniem vispirms nonāks pie datiem, un jūs nevarat paredzēt, kurš pavediens tas būs.

Tādējādi mēs izveidojam monitorus, semaforas un citus rīkus, lai organizētu daudzšķiedru putru. Kad viņi strādā, viņi strādā. Viņi tikai pievieno vēl vienu sarežģītības slāni un datu mainīgajā glabāšanu pārvērš par vienumu, kas prasa mazliet vairāk pārdomāt.

Kad viņi nedarbojas, tas ir tīrs haoss. Dati nav jēgas. Kolonnas netiek summētas. Nauda pazūd no kontiem ar poof. Tas viss ir atmiņā. Un veiksmi, mēģinot kaut ko no tā izdibināt. Lielāko daļu laika izstrādātāji galu galā bloķē lielus datu struktūras gabalus, lai tikai viens pavediens varētu tai pieskarties. Tas var apturēt haosu, bet tikai nogalinot lielāko daļu no tā, ka vairākiem pavedieniem ir vienādi dati. Jūs to varētu arī pārrakstīt kā “viena pavediena” programmu.

Slēgumi

Kaut kur pa līniju kāds nolēma, ka būtu lietderīgi apiet funkcijas, it kā tie būtu dati. Tas labi darbojās vienkāršos gadījumos, taču programmētāji sāka saprast, ka problēmas radās, kad funkcijas sasniedza sevi un piekļuva citiem datiem, kurus bieži sauc par “brīvajiem mainīgajiem”. Kura versija bija pareizā? Vai tie bija dati, kad tika uzsākts funkcijas izsaukums? Vai arī tas bija tad, kad funkcija faktiski darbojās? Tas ir īpaši svarīgi JavaScript gadījumā, ja starp tiem var būt garas nepilnības.

Risinājums, “slēgšana”, ir viens no lielākajiem JavaScript (un tagad Java un Swift) programmētāju galvassāpju avotiem. Iesācēji un pat daudzi veterāni nevar saprast, kas tiek slēgts un kur varētu būt tā sauktās slēgšanas robežas.

Nosaukums nepalīdz - nav tā, ka piekļuve būtu pastāvīgi slēgta kā josla, kas paziņo par pēdējo zvanu. Ja kaut kas, piekļuve ir atvērta, bet tikai caur tārpa caurumu datu laika kontinuumā, dīvainā laika pārslēgšanas mehānismā, kas galu galā radīs zinātniskās fantastikas TV šovu. Bet to nosaukt par "sarežģītu kaudzes piekļuves mehānismu" vai "datu kontroles žonglēšanas sistēmu" šķiet pārāk ilgi, tāpēc mēs esam iestrēguši ar "slēgšanu". Neuzsāciet, vai kādam ir jāmaksā par mainīgajiem, kas nav bezmaksas.

Pārāk lieli dati

Kad RAM sāk piepildīties, viss sāk noiet greizi. Nav svarīgi, vai veicat jaunu datu statistisko analīzi par patērētāju datiem vai strādājat ar garlaicīgu, vecu izklājlapu. Kad mašīnai beidzas RAM, tā pārvēršas par tā saukto virtuālo atmiņu, kas izplūst superslow cietajā diskā. Tas ir labāk nekā pilnībā sabrukt vai izbeigt darbu, bet zēns dara visu, kas palēninās.

Problēma ir tā, ka cietie diski ir vismaz 20 vai 30 reizes lēnāki nekā RAM, un lielapjoma diskdziņi bieži ir lēnāki. Ja kāds cits process arī mēģina rakstīt vai lasīt no diska, viss kļūst dramatiski sliktāks, jo diski vienlaikus var veikt tikai vienu lietu.

Virtuālās atmiņas aktivizēšana saasina citas slēptas problēmas ar jūsu programmatūru. Ja ir vītņu kļūmes, tās sāk izlauzties daudz ātrāk, jo pavedieni, kas ir iestrēguši cietā diska virtuālajā atmiņā, darbojas tik daudz lēnāk nekā citi pavedieni. Tomēr tas ilgst tikai īsu laiku, jo vienreizējie sienaspuķu pavedieni tiek nomainīti atmiņā un pārējie pavedieni tiek pakārti. Ja kods ir ideāls, rezultāts ir tikai daudz lēnāks. Ja tā nav, trūkumi to ātri noved pie katastrofas. Tas ir viens mazs piemērs.

To pārvaldīt ir īsts izaicinājums programmētājiem, kuri strādā ar lielām datu kaudzēm. Ikviens, kurš kļūst mazliet paviršs ar izšķērdīgu datu struktūru izveidi, nonāk ar kodu, kas palēninās līdz ražošanas pārmeklēšanai. Ar dažiem testa gadījumiem tas var darboties lieliski, bet reālas slodzes to spirālē pārvērš neveiksmē.

NP-pabeigts

Ikviens, kuram ir augstākā izglītība datorzinātnēs, zina par noslēpumainajām problēmām, kas ietvertas akronīmā, kas tiek reti izrunāts: nedeterministisks polinoms pilnīgs, pazīstams arī kā NP-pilnīgs. Detaļu apgūšanai bieži nepieciešams viss semestris, un pat tad daudziem CS studentiem rodas miglains priekšstats, ka neviens nevar atrisināt šīs problēmas, jo viņiem ir pārāk grūti.

NP pilnīgas problēmas bieži ir diezgan sarežģītas - ja jūs tām uzbrūkat vienkārši ar rupju spēku. Piemēram, “ceļojošā pārdevēja problēma” var aizņemt eksponenciāli ilgu laiku, jo pārdošanas ceļš ietver arvien vairāk pilsētu. “Muguras problēmas” atrisināšana, atrodot skaitļu apakškopu, kas ir vistuvāk kādai vērtībai N, tiek atrisināta, izmēģinot visas iespējamās apakškopas, kas ir ļoti liels skaitlis. Visi baidās no šīm problēmām, jo tie ir ideāls piemērs vienam no lielākajiem silīcija ielejas bēgļiem: algoritmi, kas netiks mērogoti.

Sarežģītā daļa ir tā, ka dažas NP-pabeigtas problēmas ir viegli atrisināt ar tuvinājumu. Algoritmi nesola precīzu risinājumu, taču tie ir diezgan tuvu. Viņi, iespējams, neatrod ideālu maršrutu ceļojošajam pārdevējam, taču var nonākt dažu procentu punktu robežās no pareizās atbildes.

Šo diezgan labo risinājumu esamība padara pūķus tikai noslēpumainākus. Neviens nevar būt pārliecināts, vai problēmas patiešām ir pietiekami smagas vai vieglas, ja jūs esat gatavs apmierināt ar pietiekami labu atbildi.

Drošība

“Ir zināmi zināmi; ir lietas, kuras mēs zinām, ka mēs zinām, ”preses konferencē savulaik teica otrās Buša administrācijas aizsardzības ministrs Donalds Ramsfelds. “Mēs arī zinām, ka ir zināmi nezināmi; tas ir, mēs zinām, ka ir dažas lietas, kuras mēs nezinām. Bet ir arī nezināmi nezināmi - tie, kurus mēs nezinām, nezinām. "

Ramsfelds runāja par karu Irākā, bet tas pats attiecas arī uz datoru drošību. Lielākās problēmas ir caurumi, par kuriem mēs pat nezinām, ka tie ir iespējami. Visi saprot, ka paroli ir grūti uzminēt - tā ir zināma. Bet kam kādreiz ir teikts, ka jūsu tīkla aparatūrai ir apglabāts savs programmatūras slānis? Iespēja, ka kāds varētu izlaist jūsu OS uzlaušanu un tā vietā mērķēt uz šo slepeno slāni, nav zināma.

Iespējams, ka šāda veida uzlaušana jums tagad nav zināma, bet ko darīt, ja ir citi? Mums nav ne jausmas, ja mēs varam nostiprināt caurumus, par kuriem mēs pat nezinām. Jūs varat nolaist paroles, taču ir plaisas, kuras jūs pat nevarat iedomāties. Tas ir prieks, strādājot ar datoru drošību. Un, runājot par programmēšanu, uz drošību vērsta domāšana kļūst arvien svarīgāka. Jūs nevarat atstāt drošības jomas profesionāļu tīrīšanu.

Šifrēšana

Šifrēšana izklausās spēcīgi un necaurejami, kad likumsargi ierodas Kongresa priekšā un lūdz oficiālas nepilnības, lai to apturētu. Problēma ir tā, ka lielākā daļa šifrēšanas ir balstīta uz miglainu nenoteiktības mākoni. Kādi matemātiskie pierādījumi mums ir, balstoties uz neskaidriem pieņēmumiem, piemēram, ir grūti ņemt vērā patiešām lielus skaitļus vai aprēķināt diskrētu žurnālu.

Vai šīs problēmas ir patiešām smagas? Neviens nav publiski aprakstījis algoritmus to laušanai, taču tas nenozīmē, ka risinājumu nav. Ja jūs atrastu veidu, kā noklausīties katru sarunu un ielauzties jebkurā bankā, vai jūs nekavējoties pastāstītu pasaulei un palīdzētu tām aizbāzt caurumus? Vai arī jūs klusētu?

Patiesais izaicinājums ir šifrēšanas izmantošana mūsu pašu kodā. Pat ja mēs ticam, ka pamata algoritmi ir droši, daudz jāstrādā, žonglējot ar parolēm, atslēgām un savienojumiem. Ja izdarāt vienu kļūdu un atstājat paroli neaizsargātu, viss tiek atvērts.

Identitātes pārvaldība

Visiem patīk šī Ņujorkas karikatūra ar štancēšanas līniju: "Internetā neviens nezina, ka tu esi suns." Tam pat ir sava Wikipedia lapa ar četrām sarežģītām sadaļām. (Internetā neviens nezina veco zāģi par humora analīzi un vardīšu sadalīšanu.)

Labā ziņa ir tā, ka anonimitāte var būt atbrīvojoša un noderīga. Sliktā ziņa ir tā, ka mums nav ne jausmas, kā kaut ko darīt, izņemot anonīmu saziņu. Daži programmētāji runā par “divfaktoru autentifikāciju”, bet gudrie pāriet uz “N faktora autentifikāciju”.

Pēc paroles un, iespējams, īsziņas uz mobilo tālruni, mums nav daudz, kas ir ļoti stabils. Pirkstu nospiedumu lasītāji izskatās iespaidīgi, taču šķiet, ka daudzi cilvēki ir gatavi atklāt, kā viņus var uzlauzt (skatīt šeit, šeit un šeit iesācējiem).

Sliktā pļāpāšanas pasaulei Snapchat vai Reddit tas nav daudz, taču uzlauzto Facebook lapu straume ir nedaudz satraucoša. Dzīvē nav vienkāršu veidu, kā risināt tādas nopietnas lietas kā īpašums, nauda, veselības aprūpe vai gandrīz viss pārējais, izņemot bezjēdzīgas mazās sarunas. Bitcoin fanbois mīl muldēt par to, cik ciets var būt blokķēde, bet kaut kā monētas turpina noplēst (skatīt šeit un šeit). Mums nav reālas metodes, kā rīkoties ar identitāti.

Cietības mērīšana

Protams, runājot par programmēšanu, vai ir kāds veids, kā mēs varam izmērīt problēmas grūtības? Neviens to īsti nezina. Mēs zinām, ka dažas problēmas ir viegli atrisināt, taču ir pilnīgi atšķirīgi to sertificēt kā grūti. NP pilnīgums ir tikai viena daļa no sarežģīta mēģinājuma kodificēt algoritmu un datu analīzes sarežģītību. Teorija ir noderīga, taču tā nevar piedāvāt nekādas garantijas. Ir vilinoši teikt, ka grūti pat zināt, vai problēma ir grūta, bet labi, jūs saprotat joku.