7 Masalah Paling Menjengkelkan Dalam Pemrograman

Dikatakan bahwa wilayah peta lama yang belum dipetakan sering kali ditandai dengan peringatan yang tidak menyenangkan: "Ini naga." Mungkin apokrif, idenya adalah bahwa tidak seorang pun yang berkeliaran ke sudut dunia yang tidak diketahui ini harus melakukannya tanpa siap untuk melawan musuh yang menakutkan. Apa pun bisa terjadi di wilayah misterius ini, dan seringkali ada yang tidak baik.

Programmer mungkin sedikit lebih beradab daripada kesatria abad pertengahan, tetapi itu tidak berarti dunia teknis modern tidak memiliki bagian naga teknis yang menunggu kita di tempat-tempat yang tidak terduga: Masalah sulit yang menunggu sampai tenggat waktu hanya beberapa menit; komplikasi yang telah membaca manual dan mengetahui apa yang tidak dirinci dengan baik; naga jahat yang tahu cara menyelinap di bug kecil dan gangguan sebelum waktunya, seringkali tepat setelah kode dilakukan.

Akan ada beberapa orang yang beristirahat dengan tenang di malam hari, dihangatkan oleh keyakinan diri mereka yang naif bahwa komputer benar-benar dapat diprediksi, dengan sungguh-sungguh memberikan jawaban yang benar. Oh, betapa sedikit yang mereka ketahui. Untuk semua kerja keras perancang chip, pengembang bahasa, dan jutaan pemrogram di mana-mana, masih ada rumpun masalah pemograman yang dapat membuat pemrogram terkuat pun bertekuk lutut.

Berikut adalah tujuh sudut paling rumit dari dunia pemrograman tempat kami memberi penanda besar bertuliskan, "Inilah naga."

Multithreading

Kedengarannya seperti ide yang bagus: Bagi program Anda menjadi beberapa bagian independen dan biarkan OS menjalankannya seperti program kecil yang terpisah. Jika prosesor memiliki empat, enam, delapan, atau bahkan lebih inti, mengapa tidak menulis kode Anda sehingga dapat memiliki empat, enam, delapan, atau lebih utas menggunakan semua inti secara independen?

Ide ini berhasil — ketika bagian-bagiannya benar-benar terpisah dan tidak ada hubungannya satu sama lain. Tetapi begitu mereka perlu mengakses variabel yang sama atau menulis bit ke file yang sama, semua taruhan dibatalkan. Salah satu utas akan mendapatkan data terlebih dahulu dan Anda tidak dapat memprediksi utas mana itu.

Jadi, kami membuat monitor, semaphore, dan alat lainnya untuk mengatur kekacauan multithread. Saat mereka bekerja, mereka bekerja. Mereka hanya menambahkan lapisan kompleksitas lain dan mengubah tindakan menyimpan data dalam variabel menjadi item yang membutuhkan lebih banyak pemikiran.

Saat mereka tidak bekerja, itu murni kekacauan. Datanya tidak masuk akal. Kolom tidak bertambah. Uang menghilang dari akun dengan poof. Itu semua bit dalam memori. Dan semoga sukses mencoba menjabarkan semua itu. Sebagian besar waktu pengembang akhirnya mengunci potongan besar struktur data sehingga hanya satu utas yang dapat menyentuhnya. Itu mungkin menghentikan kekacauan, tetapi hanya dengan membunuh sebagian besar keuntungan dari memiliki beberapa utas yang mengerjakan data yang sama. Anda mungkin juga menulis ulang sebagai program "single-threaded".

Penutupan

Di suatu tempat di sepanjang garis, seseorang memutuskan akan berguna untuk menyebarkan fungsi seolah-olah itu adalah data. Ini bekerja dengan baik dalam contoh sederhana, tetapi pemrogram mulai menyadari bahwa masalah muncul ketika fungsi mencapai di luar dirinya dan mengakses data lain, sering disebut "variabel bebas". Versi mana yang benar? Apakah itu data saat pemanggilan fungsi dimulai? Atau apakah saat fungsi benar-benar berjalan? Ini sangat penting untuk JavaScript yang mungkin memiliki celah panjang di antaranya.

Solusinya, "penutupan", adalah salah satu sumber masalah terbesar bagi pemrogram JavaScript (dan sekarang Java dan Swift). Pemula dan bahkan banyak veteran tidak tahu apa yang ditutup dan di mana batas-batas yang disebut penutupan itu.

Namanya tidak membantu — bukan berarti akses ditutup secara permanen seperti bilah yang mengumumkan panggilan terakhir. Jika ada, akses terbuka tetapi hanya melalui lubang cacing dalam kontinum waktu-data, mekanisme pergeseran waktu yang aneh yang pada akhirnya akan menelurkan acara TV fiksi ilmiah. Namun menyebutnya sebagai "Mekanisme Akses Tumpukan Kompleks" atau "Sistem Juggling Kontrol Data" tampaknya terlalu lama, jadi kami terjebak dengan "penutupan". Jangan biarkan saya memulai apakah ada yang perlu membayar untuk variabel non-gratis.

Data terlalu besar

Saat RAM mulai terisi, semuanya mulai salah. Tidak masalah jika Anda melakukan analisis statistik model baru dari data konsumen atau mengerjakan spreadsheet lama yang membosankan. Ketika mesin kehabisan RAM, itu berubah menjadi apa yang disebut memori virtual yang tumpah ke hard disk superslow. Ini lebih baik daripada benar-benar gagal atau mengakhiri pekerjaan, tetapi anak laki-laki melakukan semuanya dengan lambat.

Masalahnya adalah hard disk setidaknya 20 atau 30 kali lebih lambat dari RAM dan disk drive pasar massal sering kali lebih lambat. Jika beberapa proses lain juga mencoba untuk menulis atau membaca dari disk, semuanya menjadi jauh lebih buruk karena drive hanya dapat melakukan satu hal pada satu waktu.

Mengaktifkan memori virtual memperburuk masalah tersembunyi lainnya dengan perangkat lunak Anda. Jika ada gangguan threading, mereka mulai rusak lebih cepat karena utas yang tersangkut di memori virtual hard disk berjalan jauh lebih lambat daripada utas lainnya. Itu hanya berlangsung dalam waktu singkat, karena utas yang pernah menjadi bunga dinding ditukar ke memori dan utas lainnya menutup telepon. Jika kodenya sempurna, hasilnya akan jauh lebih lambat. Jika tidak, kekurangannya dengan cepat membuatnya menjadi bencana. Itu satu contoh kecil.

Mengelola ini adalah tantangan nyata bagi pemrogram yang bekerja dengan banyak data. Siapa pun yang menjadi sedikit ceroboh dengan membangun struktur data yang boros akan berakhir dengan kode yang melambat hingga perayapan dalam produksi. Ini mungkin berfungsi dengan baik dengan beberapa kasus uji, tetapi beban nyata mengirimnya berputar ke dalam kegagalan.

NP-complete

Siapa pun dengan pendidikan universitas di bidang ilmu komputer tahu tentang masalah misterius yang dibungkus dengan akronim yang jarang dijabarkan: polinomial nondeterministik lengkap, alias NP-complete. Detailnya sering memakan waktu satu semester untuk dipelajari, dan bahkan kemudian, banyak siswa CS keluar dengan gagasan berkabut bahwa tidak ada yang bisa menyelesaikan masalah ini karena terlalu sulit.

Masalah NP-complete seringkali cukup sulit — jika Anda menyerangnya dengan kekerasan. Misalnya, “masalah salesman keliling”, dapat memakan waktu yang sangat lama karena rute penjualan mencakup lebih banyak kota. Memecahkan “masalah knapsack” dengan mencari subset dari angka yang paling mendekati nilai N diselesaikan dengan mencoba semua subset yang mungkin, yang merupakan angka yang sangat besar. Semua orang takut akan masalah ini karena mereka adalah contoh sempurna dari salah satu momok terbesar di Silicon Valley: algoritme yang tidak dapat diskalakan.

Bagian yang sulit adalah bahwa beberapa masalah NP-complete mudah dipecahkan dengan pendekatan. Algoritme tidak menjanjikan solusi yang tepat, tetapi hampir mendekati. Mereka mungkin tidak menemukan rute yang tepat untuk penjual keliling, tetapi mereka bisa mendapatkan beberapa poin persentase dari jawaban yang benar.

Adanya solusi yang cukup bagus ini hanya membuat komodo semakin misterius. Tidak ada yang bisa memastikan apakah masalahnya benar-benar sulit atau cukup mudah jika Anda bersedia dipuaskan dengan jawaban yang cukup baik.

Keamanan

“Ada yang diketahui; ada hal-hal yang kami tahu kami tahu, ”Donald Rumsfeld, Menteri Pertahanan selama pemerintahan Bush kedua, suatu kali mengatakan pada konferensi pers. “Kami juga tahu ada hal-hal yang tidak diketahui; Artinya kita tahu ada beberapa hal yang tidak kita ketahui. Tapi ada juga yang tidak diketahui yang tidak diketahui — yang tidak kita ketahui tidak kita ketahui. ”

Rumsfeld berbicara tentang perang di Irak, tetapi hal yang sama berlaku untuk keamanan komputer. Masalah terbesar adalah lubang yang bahkan tidak kita ketahui mungkin terjadi. Semua orang memahami bahwa Anda harus membuat sandi Anda sulit ditebak — itu sudah diketahui. Tetapi siapa yang pernah diberitahu bahwa perangkat keras jaringan Anda memiliki lapisan perangkat lunaknya sendiri yang terkubur di dalamnya? Kemungkinan bahwa seseorang dapat melewati peretasan OS Anda dan malah menargetkan lapisan rahasia ini adalah hal yang tidak diketahui.

Kemungkinan peretasan semacam itu mungkin tidak Anda ketahui sekarang, tetapi bagaimana jika ada yang lain? Kami tidak memiliki petunjuk apakah kami dapat mengeraskan lubang yang bahkan tidak kami ketahui keberadaannya. Anda dapat meringkas kata sandi, tetapi ada celah yang bahkan tidak dapat Anda bayangkan. Itulah kesenangan bekerja dengan keamanan komputer. Dan dalam hal pemrograman, pemikiran yang mengutamakan keamanan menjadi semakin penting. Anda tidak dapat menyerahkannya kepada profesional keamanan untuk membersihkan kekacauan Anda.

Enkripsi

Enkripsi terdengar kuat dan tidak bisa ditembus ketika petugas penegak hukum menghadap Kongres dan meminta celah resmi untuk menghentikannya. Masalahnya adalah sebagian besar enkripsi dibangun di atas awan ketidakpastian yang berkabut. Bukti matematis apa yang kita miliki berdasarkan asumsi yang tidak pasti, seperti sulit untuk memfaktorkan angka yang sangat besar atau menghitung log diskrit.

Apakah masalah itu benar-benar sulit? Tidak ada yang secara terbuka menjelaskan algoritme apa pun untuk memecahnya, tetapi itu tidak berarti solusinya tidak ada. Jika Anda menemukan cara untuk menguping setiap percakapan dan masuk ke bank mana pun, apakah Anda akan segera memberi tahu dunia dan membantu mereka menutup lubang? Atau apakah Anda akan tetap diam?

Tantangan sebenarnya adalah menggunakan enkripsi dalam kode kita sendiri. Bahkan jika kami percaya bahwa algoritme dasar aman, ada banyak pekerjaan yang harus dilakukan untuk menyulap kata sandi, kunci, dan koneksi. Jika Anda membuat satu kesalahan dan membiarkan kata sandi tidak terlindungi, semuanya akan terbuka.

Manajemen identitas

Semua orang menyukai kartun New Yorker dengan kalimat lucunya, "Di internet, tidak ada yang tahu Anda seekor anjing." Ia bahkan memiliki halaman Wikipedia sendiri dengan empat bagian yang rumit. (Di internet, tidak ada yang tahu cara lama tentang menganalisis humor dan membedah katak.)

Kabar baiknya adalah anonimitas bisa membebaskan dan berguna. Kabar buruknya adalah kita tidak tahu bagaimana melakukan apapun kecuali komunikasi anonim. Beberapa programmer berbicara tentang "autentikasi dua faktor", tetapi yang cerdas beralih ke "Autentikasi faktor-N".

Setelah kata sandi dan mungkin pesan teks ke ponsel, kami tidak memiliki banyak yang sangat stabil. Pembaca sidik jari terlihat mengesankan, tetapi banyak orang tampaknya bersedia membocorkan bagaimana mereka dapat diretas (lihat di sini, di sini, dan di sini untuk permulaan).

Tidak banyak dari hal ini yang penting bagi dunia obrolan kosong di Snapchat atau Reddit, tetapi aliran halaman Facebook yang diretas agak membingungkan. Tidak ada cara mudah untuk menangani masalah serius seperti properti, uang, perawatan kesehatan, atau hampir semua hal lain dalam hidup ini kecuali obrolan ringan yang tidak berarti. Penggemar bitcoin suka mengoceh tentang betapa kokohnya blockchain itu, tetapi entah bagaimana koin itu terus dirampok (lihat di sini dan di sini). Kami tidak memiliki metode nyata untuk menangani identitas.

Mengukur kekerasan

Tentu saja, dalam hal pemrograman, apakah ada cara untuk mengukur tingkat kesulitan suatu masalah? Tidak ada yang tahu. Kami tahu bahwa beberapa masalah mudah diselesaikan, tetapi sangat berbeda untuk menyatakan masalah sulit. NP-complete hanyalah satu bagian dari upaya rumit untuk mengkodifikasi kompleksitas algoritma dan analisis data. Teori ini membantu, tetapi tidak bisa memberikan jaminan apa pun. Sangat menggoda untuk mengatakan bahwa sulit untuk mengetahui apakah suatu masalah itu sulit, tetapi Anda mengerti leluconnya.

Artikel terkait

  • Unduh: Panduan pengembangan karier pengembang
  • Kekuatan pemrograman malas
  • 7 ide pemrograman buruk yang berhasil
  • 9 kebiasaan buruk pemrograman yang diam-diam kami sukai
  • 21 tren pemrograman populer — dan 21 menjadi dingin
  • Unduh: Panduan kelangsungan hidup bisnis programmer profesional
  • Unduh: 29 tip untuk sukses sebagai pengembang independen
  • 7 bahasa pemrograman yang sangat kami benci
  • 5 pelajaran pemrograman yang lebih tak lekang oleh waktu 'greybeards'
  • 22 penghinaan yang tidak ingin didengar oleh pengembang
  • 9 prediksi untuk masa depan pemrograman
  • 13 keterampilan pengembang yang perlu Anda kuasai sekarang
  • Programkan dunia: 12 teknologi yang perlu Anda ketahui sekarang
  • Serangan bahasa pemrograman satu huruf