7 najneugodnijih problema u programiranju

Govorilo se da su neistražena područja starih karata često bila označena zlokobnim upozorenjem: "Evo, budite zmajevi." Možda apokrifna, ideja je bila da nitko koji zaluta u ove nepoznate krajeve svijeta to ne smije činiti, a da nije spreman za bitku sa zastrašujućim neprijateljem. Sve se moglo dogoditi u tim tajanstvenim regijama, a često i da išta nije bilo dobro.

Programeri su možda malo civiliziraniji od srednjovjekovnih vitezova, ali to ne znači da suvremeni tehnički svijet nema svoj dio tehničkih zmajeva koji nas čekaju na nepredviđenim mjestima: Teški problemi koji čekaju dok krajnji rok ne prođe; komplikacije koje su pročitale priručnik i znaju što nije dobro određeno; zli zmajevi koji se znaju ušuljati u skrivene bugove i nepravodobne propuste, često odmah nakon što je kod počinjen.

Neki će se noću mirno odmarati, zagrijani svojim naivnim samopouzdanjem da su računala krajnje predvidljiva, usrdno izbacujući prave odgovore. Oh, kako malo znaju. Uz sav naporan rad dizajnera čipova, programera jezika i milijuna programera posvuda, još uvijek postoje trnovite šikare programskih problema koji čak i najmoćnije programere mogu baciti na koljena.

Evo sedam najgorih kutova svijeta programiranja gdje bismo stavili velike oznake s natpisom: "Evo, budite zmajevi."

Višenitnost

Zvučalo je kao dobra ideja: rastavite svoj program na neovisne odjeljke i pustite da ih OS pokreće poput zasebnih malih programa. Ako procesori imaju četiri, šest, osam ili čak više jezgri, zašto ne biste napisali svoj kod tako da može imati četiri, šest, osam ili više niti koristeći sve jezgre neovisno?

Ideja djeluje - kad su dijelovi zapravo potpuno odvojeni i nemaju nikakve veze jedni s drugima. Ali kad jednom trebaju pristupiti istim varijablama ili zapisati bitove u iste datoteke, sve oklade se isključuju. Jedna će nit prvo doći do podataka i ne možete predvidjeti koja će to nit biti.

Stoga stvaramo monitore, semafore i druge alate za organiziranje višetreadnog nereda. Kad rade, rade. Oni samo dodaju još jedan slojeviti sloj i čin spremanja podataka u varijablu pretvaraju u stavku koja zahtijeva malo više razmišljanja.

Kad ne rade, to je čisti kaos. Podaci nemaju smisla. Stupci se ne zbrajaju. Novac nestaje s računa s pufom. Sve su to komadići u memoriji. I sretno pokušavajući otkriti bilo što od toga. Većina vremena programeri zaključavaju velike dijelove podatkovne strukture tako da je može dodirnuti samo jedna nit. To može zaustaviti kaos, ali samo ubijanjem većine naopakih postojanja više niti koje rade na istim podacima. Mogli biste ga prepisati i kao program s jednim navojem.

Zatvaranja

Negdje na liniji netko je zaključio da bi bilo korisno prenositi funkcije kao da su podaci. To je dobro funkcioniralo u jednostavnim primjerima, ali programeri su počeli shvaćati da su problemi nastali kad funkcije dosegnu izvan njih i pristupe drugim podacima, često zvanim "slobodne varijable". Koja je verzija bila prava? Jesu li to podaci kada je pokrenut poziv funkcije? Ili je to bilo kad se funkcija zapravo pokrenula? To je posebno važno za JavaScript gdje između njih mogu biti velike praznine.

Rješenje, "zatvaranje", jedan je od najvećih izvora glavobolje programera JavaScript-a (a sada Java i Swift). Početnici, pa čak i mnogi veterani ne mogu shvatiti što se zatvara i gdje bi mogle biti granice takozvanog zatvaranja.

Ime ne pomaže - nije da je pristup trajno zatvoren poput trake koja najavljuje zadnji poziv. Ako je išta drugo, pristup je otvoren, ali samo kroz crvotočinu u kontinuumu podatkovnog vremena, čudan mehanizam za pomicanje vremena koji će na kraju iznjedriti znanstveno-fantastičnu TV emisiju. No, nazvati ga "Složenim mehanizmom za pristup stogu" ili "Žongliranje sustavom za kontrolu podataka" čini se predugim, pa smo zapeli s "zatvaranjem". Ne upuštajte me da li netko treba platiti neslobodne varijable.

Preveliki podaci

Kad se RAM počne puniti, sve počinje ići po zlu. Nije važno radite li novovjekovnu statističku analizu potrošačkih podataka ili radite li na dosadnoj, staroj proračunskoj tablici. Kad stroju ponestane RAM-a, on se pretvara u takozvanu virtualnu memoriju koja se izlijeva na prespori tvrdi disk. Bolje je nego potpuno srušiti se ili završiti posao, ali dječak sve usporava.

Problem je u tome što su tvrdi diskovi barem 20 ili 30 puta sporiji od RAM-a, a pogonski diskovi za masovno tržište često su sporiji. Ako neki drugi proces također pokušava zapisivati ​​ili čitati s diska, sve postaje dramatično gore jer pogoni istodobno mogu raditi samo jednu stvar.

Aktiviranje virtualne memorije pogoršava druge, skrivene probleme s vašim softverom. Ako postoje problemi s navojem, oni se počinju pucati puno brže jer niti koje su zaglavljene u virtualnoj memoriji tvrdog diska rade toliko sporije od ostalih niti. To, međutim, traje samo kratko razdoblje, jer se jednom niti cvijeta zamijene u memoriju, a druge niti prekidaju. Ako je kod savršen, rezultat je tek puno sporiji. Ako nije, nedostaci ga brzo dovedu do katastrofe. To je jedan mali primjer.

Upravljanje tim stvarnim je izazovom za programere koji rade s velikom hrpom podataka. Svatko tko postane pomalo traljav s izgradnjom rastrošnih podatkovnih struktura završava s kodom koji usporava i puzi u proizvodnji. Možda radi u redu s nekoliko testnih slučajeva, ali stvarna opterećenja šalju spiralno u neuspjeh.

NP-kompletan

Svatko tko ima sveučilišno obrazovanje iz računarstva zna za tajanstvene probleme umotane u kraticu koja se rijetko izriče: nedeterministički polinom potpun, zvan NP-cjelovit. Učenje pojedinosti često traje čitav semestar, pa čak i tada mnogi studenti CS-a izađu s maglovitom predodžbom da nitko ne može riješiti ove probleme jer su preteški.

Problemi s NP-om često su prilično teški - ako ih napadnete jednostavno grubom silom. Na primjer, "problem prodavača putnika" može trajati eksponencijalno dugo jer prodajni put uključuje sve više i više gradova. Rješavanje "problema s naprtnjačom" pronalaženjem podskupina brojeva koji su najbliži nekoj vrijednosti N rješava se isprobavanjem svih mogućih podskupova, što je vrlo velik broj. Svi trče sa strahom od ovih problema jer su savršeni primjer jednog od najvećih bauk u Silicijskoj dolini: algoritama koji se neće prilagoditi.

Škakljivo je to što je neke probleme s NP-om lako riješiti aproksimativno. Algoritmi ne obećavaju točno rješenje, ali se prilično približavaju. Možda neće pronaći savršenu rutu za putničkog trgovca, ali mogu doći do nekoliko postotnih bodova od ispravnog odgovora.

Postojanje ovih prilično dobrih rješenja zmajeve samo čini tajanstvenijima. Nitko ne može biti siguran jesu li problemi uistinu dovoljno teški ili laki ako ste spremni biti zadovoljni upravo dovoljno dobrim odgovorom.

Sigurnost

„Poznata su znanja; postoje stvari za koje znamo da ih znamo ”, rekao je svojedobno na tiskovnoj konferenciji Donald Rumsfeld, ministar obrane tijekom druge Bushove administracije. “Također znamo da postoje poznate nepoznanice; to znači da znamo da postoje neke stvari koje ne znamo. Ali postoje i nepoznate nepoznanice - one za koje ne znamo da ih ne znamo. "

Rumsfeld je govorio o ratu u Iraku, ali isto vrijedi i za računalnu sigurnost. Najveći su problemi rupe za koje ni sami ne znamo da su moguće. Svi razumiju da biste trebali otežati pogađanje lozinke - to je poznato poznato. No, kome je ikad rečeno da vaš mrežni hardver ima svoj vlastiti softverski sloj zakopan unutra? Mogućnost da netko može preskočiti hakiranje vašeg OS-a i umjesto toga usmjeriti ovaj tajni sloj nepoznata je nepoznanica.

Mogućnost takvog hakiranja možda vam sada nije nepoznata, ali što ako postoje drugi? Nemamo pojma možemo li očvrsnuti rupe za koje ni sami ne znamo da postoje. Možete zabiti lozinke, ali postoje pukotine koje ne možete niti zamisliti. To je zabava u radu s računalnom sigurnošću. A što se tiče programiranja, razmišljanje usmjereno na sigurnost postaje sve važnije. Ne možete prepustiti sigurnosnim profesionalcima da vam očiste nered.

Šifriranje

Šifriranje zvuči moćno i neprobojno kad službenici zakona prođu ispred Kongresa i zatraže službene rupe da to zaustave. Problem je u tome što se većina šifriranja gradi na maglovitom oblaku neizvjesnosti. Koji matematički dokazi imamo počivaju na nesigurnim pretpostavkama, kao što je teško računati stvarno velike brojeve ili izračunati diskretni dnevnik.

Jesu li ti problemi uistinu teški? Nitko nije javno opisao nijedan algoritam za njihovo razbijanje, ali to ne znači da rješenja ne postoje. Ako nađete način da prisluškivate svaki razgovor i upadnete u bilo koju banku, biste li to odmah obavijestili svijet i pomogli im da zapuše rupe? Ili biste šutjeli?

Pravi izazov je korištenje šifriranja u našem vlastitom kodu. Čak i ako vjerujemo da su osnovni algoritmi sigurni, puno toga treba učiniti na žongliranju lozinkama, ključevima i vezama. Ako pogriješite i ostavite lozinku nezaštićenom, sve postaje otvoreno.

Upravljanje identitetom

Svi vole onaj crtani film iz New Yorkera s punchline-om, "Na internetu nitko ne zna da ste pas." Čak ima i vlastitu stranicu Wikipedije s četiri složena odjeljka. (Na internetu nitko ne zna staru pilu o analizi humora i seciranju žaba.)

Dobra vijest je da anonimnost može biti oslobađajuća i korisna. Loša vijest je da nemamo pojma kako učiniti bilo što osim anonimnih komunikacija. Neki programeri govore o "dvofaktorskoj autentifikaciji", ali pametni prelaze na "autentifikaciju N-faktorom".

Nakon lozinke i možda tekstualne poruke na mobitel, nemamo baš puno stabilnog. Čitači otisaka prstiju izgledaju impresivno, ali čini se da je mnogo ljudi spremno otkriti kako ih se može hakirati (za početak pogledajte ovdje, ovdje i ovdje).

Nije puno toga važno za svijet besposlenih brbljanja na Snapchatu ili Redditu, ali tok hakiranih Facebook stranica pomalo zbunjuje. Ne postoji jednostavan način rješavanja ozbiljnih stvari poput imovine, novca, zdravstvene zaštite ili gotovo svega ostalog u životu, osim besmislenih razgovora. Bitcoin obožavatelji vole brbljati o tome koliko čvrst blockchain može biti, ali novčići se nekako stalno otkidaju (pogledajte ovdje i ovdje). Nemamo stvarnu metodu za rukovanje identitetom.

Mjerenje tvrdoće

Naravno, što se tiče programiranja, postoji li uopće način na koji možemo izmjeriti težinu problema? Nitko zapravo ne zna. Znamo da je neke probleme lako riješiti, ali potpuno je drugačije potvrditi jedan kao težak. NP-cjelovitost samo je jedan dio razrađenog pokušaja kodificiranja složenosti algoritama i analize podataka. Teorija je korisna, ali ne može pružiti nikakva jamstva. Primamljivo je reći da je teško uopće znati je li problem težak, ali dobro, shvatiš šalu.

Povezani članci

  • Preuzimanje: Vodič za razvoj karijere programera
  • Moć lijenog programiranja
  • 7 loših programskih ideja koje rade
  • 9 loših programskih navika koje potajno volimo
  • 21 vrući trend u programiranju - i 21 u hladnom
  • Preuzimanje: Vodič za poslovno preživljavanje profesionalnog programera
  • Preuzimanje: 29 savjeta za uspjeh kao neovisni programer
  • 7 programskih jezika koje volimo mrziti
  • Još 5 bezvremenskih lekcija programiranja 'sive brade'
  • 22 uvrede koje nijedan programer ne želi čuti
  • 9 predviđanja za budućnost programiranja
  • 13 vještina programera koje sada trebate svladati
  • Programirajte svijet: 12 tehnologija koje sada morate znati
  • Napad jednoslovnih programskih jezika