Apakah boleh untuk hidup tanpa mengetahui cara kerja program yang Anda buat?

Maksud saya, ada lib yang sangat berguna yang dapat menyelesaikan masalah saat Anda macet dan tidak tahu bagaimana menyelesaikan ini atau itu dengan pengetahuan Anda tentang bahasa pemrograman yang Anda gunakan ... Misalnya, Tingkatkan untuk C ++ atau JQuery untuk JavaScript atau Musim Semi untuk Java ... Mereka memecahkan masalah dalam hitungan detik dan Anda tidak benar-benar peduli bagaimana mereka melakukannya (meskipun mereka ditulis dalam bahasa yang sama dengan pemrograman Anda) ... Jadi saya ingin tahu apakah saya sendirian menggunakan libs sementara tidak sedang mampu menulis solusi untuk masalah saya dari awal atau apakah itu praktik standar?

Apakah boleh untuk tidak memahami cara menyelesaikan masalah sendiri, dan menggunakan perpustakaan sebagai gantinya?

Secara umum, tidak, tidak.

Pustaka dapat menyelamatkan Anda dari pekerjaan (keras!) Untuk mencari tahu bagaimana menyelesaikan masalah, dan kemudian men-debug solusi, dan kemudian, mempertahankannya. Tetapi, jika Anda akan menggunakannya, Anda sebaiknya memastikan Anda memahami cara kerjanya - mengapa solusi tersebut benar-benar menyelesaikan masalah. Anda tidak perlu tahu cara membuat mobil, dan mesin, dan robot yang membangun mesin mobil, jika Anda bekerja sebagai mekanik - tetapi Anda akan lebih memahami bagaimana bagian-bagiannya bekerja, apa yang mereka semua lakukan, dan bagaimana mereka bertaut!

Inilah alasan mengapa Anda akan melihat banyak orang menjadi sangat terspesialisasi - sering kali hanya belajar bagaimana bekerja dengan satu bahasa, satu platform, satu kerangka kerja dan sekumpulan perpustakaan.

Yang sedang berkata, hanya ada begitu banyak Anda akan punya waktu untuk belajar. Terkadang Anda harus mengambil jalan pintas - ambil saja, tetapi ketahuilah itu jalan pintas. Mungkin Anda hanya cukup membaca tentang perpustakaan untuk mengetahui Anda bisa mengetahuinya, jika Anda punya waktu. Atau mungkin Anda hanya mengetahui dua fungsi yang sebenarnya perlu Anda panggil, dan hanya cukup untuk melakukan panggilan dengan benar. Itu jalan pintas, yang akan dikenakan biaya - biasanya nanti, ketika seseorang (mungkin yang lebih tua, dan lebih berpengalaman, Anda) harus memperbaiki kode.

Pernah computerworld.com.au bertanya kepada Bjarne Stroustrup, "Apakah Anda punya saran untuk programmer yang akan datang?"
Dan dia menjawab"Ketahui dasar-dasar ilmu komputer: algoritma, arsitektur mesin, struktur data, dll. Jangan hanya menyalin teknik dari aplikasi ke aplikasi secara membabi buta. Ketahui apa yang Anda lakukan, itu berhasil, dan mengapa itu bekerja. Jangan pikir Anda tahu apa yang akan menjadi industri dalam waktu lima tahun atau apa yang akan Anda lakukan kemudian, jadi kumpulkan portofolio keterampilan umum dan berguna. Cobalah untuk menulis kode yang lebih baik, lebih berprinsip. Bekerja untuk membuat "pemrograman" lebih dari kegiatan profesional dan kurang dari aktivitas "peretasan" tingkat rendah (pemrograman juga merupakan keahlian, tetapi tidak hanya keahlian). Belajarlah dari klasik di lapangan dan buku teks canggih yang lebih baik; jangan puas dengan "cara" yang mudah dicerna. panduan dan dokumentasi online - dangkal. "Programmer sejati dan apa yang diperlukan
Semoga ini akan menjelaskan keraguan Anda tentang apa yang diperlukan untuk bagi siapa pun untuk menjadi satu.

Ya - dan kita semua melakukannya!

Mari kita ambil, misalnya, bug yang sangat sederhana yang saya perbaiki di beberapa kode grafis terkait Mac. Kode di sekitar bug melibatkan beberapa langkah:

1. Pertama, metode Objective C mengalokasikan buffer pixel menggunakan malloc (), dan menempelkannya ke objek Objective C-nya.
2. Kemudian, sesuatu terjadi, dan rutin C mengirimkan pesan ke objek Objective C dan mengambil buffer pixel.
3. Rutin C mengompresi konten buffer piksel menggunakan jpeglib, dan mengirimkannya melalui koneksi TCP / IP.

Ada banyak hal buruk yang terjadi di sana! Berikut ini beberapa hal:

• Pengalokasi memori yang dinamis untuk mengimplementasikan malloc (), yang mengasumsikan memori secara fisik bersebelahan dan linear dialamatkan.
• Sistem memori virtual kernel Darwin yang mendasari untuk memetakan kedua RAM fisik yang terfragmentasi, dan ruang disk (yang merupakan perangkat fisik yang berbeda dari RAM), menjadi sesuatu yang tampak bagi pengalokasi memori dinamis seperti itu secara fisik berdekatan dan RAM yang dapat dialamatkan secara linear.
• Sistem objek Objective C
• Sistem perpesanan runtime Mac OS, dan caranya berinteraksi dengan objek Objective C
• Implementasi pustaka jpeglib tentang standar kompresi gambar raster lossy JPEG, yang menggunakan algoritma diskrit cosine transform
• Rangkaian jejaring userspace untuk mengirimkan data, yang memanggil berbagai implementasi protokol TCP dan IP, yang pada gilirannya memanggil ke dalam kernel OS. Kemudian tergantung pada apa yang Anda miliki dihidupkan untuk jaringan Anda, itu mungkin memanggil driver untuk port Ethernet, chip wi-fi, atau yang lebih luar biasa driver USB atau Firewire.

Apakah Anda memahami semua perincian tentang bagaimana semua hal itu benar-benar dilaksanakan? Saya yakin tidak! Saya ragu ada sangat banyak orang di planet ini yang melakukannya - mungkin bahkan tidak ada. Jadi saya tidak khawatir tentang itu.

Tapi itu hal yang baik untuk penasaran, dan untuk belajar setidaknya sedikit tentang perpustakaan dan alat yang Anda gunakan. Ketika saya pertama kali memulai pemrograman, saya tahu kompiler dan sistem operasi tidak mungkin ajaib, tetapi mereka tampaknya seperti itu bagi saya. Dengan memanjakan keingintahuan saya tentang hal-hal itu, saya telah belajar banyak hal yang buruk dan memiliki karier yang hebat sejauh ini.

Saya menemukan alasan utama kami menggunakan perpustakaan adalah untuk tidak "menemukan kembali roda" sepanjang waktu, mengabstraksi masalah yang ingin mereka selesaikan. Anda bisa mencoba menyelesaikan masalah sendiri, tetapi itu akan memakan waktu lebih lama.

Namun saya merasa bahwa kita juga perlu tahu atau menebak bagaimana masalahnya diselesaikan oleh perpustakaan. Ini biasanya didokumentasikan dalam dokumentasi pengguna perpustakaan dan dengan perangkat lunak sumber terbuka, Anda selalu dapat melihat kode itu sendiri.

Juga kami biasanya menyelesaikan masalah dengan mengabstraksikan bagian-bagian yang sulit, jadi mengapa tidak ok?

Perpustakaan ada di sana untuk memberikan solusi untuk masalah umum. Anda perlu memutuskan apakah mereka memecahkan masalah tertentu yang sedang Anda pecahkan. Mereka BUKAN pengganti untuk tidak tahu bagaimana menyelesaikan masalah. Misalnya, jika aplikasi Anda memerlukan tabel hash, Anda harus memiliki pengetahuan yang cukup untuk memahami masalah apa yang diselesaikan oleh tabel hash. Anda harus dapat mengevaluasi kinerja perpustakaan yang Anda gunakan untuk memutuskan apakah itu akan berfungsi dalam aplikasi Anda. Saya percaya menggunakan perpustakaan untuk menutupi pengetahuan teknis yang tidak memadai bukanlah kasus penggunaan yang benar. Keputusan untuk menggunakan perpustakaan harus berputar apakah menggunakan perpustakaan akan mempercepat pengembangan dan memberikan solusi yang teruji dan andal. Keputusan untuk menggunakan perpustakaan tidak boleh berputar di sekitar ketidakmampuan programmer untuk memecahkan masalah yang diberikan.

Terserah Anda, sungguh .

Semakin baik Anda memahami alat yang Anda gunakan, semakin baik Anda memanfaatkannya.

Sebagai contoh, saya jarang menggunakan jQuery, tetapi ketika saya harus tahu apa yang harus saya manfaatkan darinya, dan bagaimana saya bisa membuatnya berdampingan dengan kerangka kerja lain seperti Mootools.

Juga, segera saya akan berpetualang ke gamedev dengan UDK, dan saya yakin semakin saya memahaminya, semakin saya bisa membengkokkannya pada keinginan jahat saya, tetapi saya juga bisa mengikuti tutorial tanpa otak. Saya memilih yang pertama, hanya sedikit waktu ekstra dan siklus otak dan saya akan mendapatkan hasil yang lebih baik dan lebih mudah .

Penting untuk mengetahui wilayah Anda, dan bagian Anda dari proses tersebut.

Misalnya, Anda menggunakan pustaka pemrosesan gambar. Apakah Anda benar-benar perlu tahu semua tentang kekaburan gaussian, transformasi, dan ruang warna? Tidak. Tapi Anda harus tahu mengapa Anda menggunakan perpustakaan di tempat pertama. Atau fungsi penyortiran kerangka kerja. Apakah Anda perlu mengetahui algoritma penyortiran aktual yang digunakan? Dalam kebanyakan kasus, tidak. Tetapi Anda perlu tahu mengapa Anda perlu mengurutkan data.

Di sisi lain, jika Anda menulis kompiler, Anda harus lebih tahu cara kerja kompiler, karena itulah bagian Anda dalam proses.

Kerangka kerja tertentu seperti jQuery abstrak banyak. Apakah Anda perlu tahu bagaimana tepatnya mereka bekerja? Tetapi memiliki pemahaman yang kuat dan mendasar tentang apa yang dilakukan perpustakaan akan sangat bermanfaat bagi Anda ketika Anda menulis kode karena Anda akan lebih memahami mengapa kerangka dibuat seperti itu, dan dapat menggunakannya dengan potensi penuhnya. .

Berdasarkan pengalaman saya: karena Anda tidak dapat menghilangkan ketergantungan perpustakaan, Anda dan tim Anda harus cukup tahu untuk menyelesaikan masalah.

Sebagai programmer, kita punya sedikit waktu, jadi kita harus memilih yang memiliki prioritas tertinggi. Masalahnya harus diselesaikan, secepat dan selembut mungkin. Hanya alasan inilah yang membuat "mempelajari segala sesuatu berjalan lancar" agak berlebihan.

Yang ingin saya tambahkan di sini adalah "ketergantungan". Sebagai sebuah komunitas, kita semua tergantung pada orang lain. Kami mendukung Giants untuk membangun aplikasi kami: Java, .NET, API ... Dan kami percaya pada Giants tentang pekerjaan mereka; karena itu bekerja untuk banyak orang. Jika Anda memiliki masalah tentang kerangka kerja, atau API, ada peluang bagus bahwa orang lain menghadapinya di suatu tempat, dan ada solusi / penyelesaiannya.

Satu-satunya masalah di sini: mungkin, di suatu tempat, dalam kriteria terbatas Giants runtuh.Misalnya, flash tidak didukung di beberapa OS, dan ada banyak hal yang tidak dapat kami lakukan tanpanya. Kemungkinan ini lebih dari nol, tetapi dalam hal ini kita memiliki hal-hal kecil yang dapat kita lakukan. Hanya dalam kasus-kasus ini, pengetahuan tentang "apa yang ada di balik tudung" terbukti bermanfaat, karena menunjukkan di mana masalahnya sebenarnya dan dapat menciptakan penyelesaian yang besar; tapi saya tidak yakin waktu yang kita investasikan benar-benar sepadan.

Untuk mengatasi kemungkinan itu, saya pikir ada solusinya: karena sebagian besar programmer dapat dengan mudah menangkap "pekerjaan permukaan" perpustakaan, dan hanya kadang-kadang kita benar-benar membutuhkan seseorang yang sangat paham: biarkan membagi tim untuk melakukan itu. Mencoba untuk membentuk sebuah tim yang masing-masing telah ahli tentang 1,2 perpustakaan / alat / "keahlian" yang berguna yang terlibat : seseorang memiliki pengalaman yang baik tentang jQuery, seseorang telah berspesialisasi dalam database, ... Ini akan banyak membantu dalam meminimalkan risiko.

Pandangan lain adalah keamanan. Ketika Anda menggunakan perpustakaan yang Anda tidak tahu cara kerja yang tepat, maka Anda membuat asumsi tentang apa yang sebenarnya terjadi. Setiap asumsi yang gagal dapat membuka vektor serangan untuk penyerang jahat.

Saat memanggil Quicksort, maka Anda harus mengetahui tentang perilaku terburuk. Jika tidak, penyerang mungkin dapat menyuntikkan data kasus terburuk dan melakukan DoS.

Saat memanggil perpustakaan kompresi, maka Anda harus menyadari bahwa ketika beberapa data kompres menjadi lebih sedikit byte, maka harus ada data yang "kompres" menjadi lebih banyak byte daripada yang asli. Jadi, ketika asumsi Anda adalah bahwa buffer output hanya perlu ukuran data input karena kompres [menjadi lebih sedikit byte], maka ada buffer overflow yang menunggu untuk terjadi.

Anda harus cukup mengetahui dasar-dasar tentang hal-hal yang akan Anda lakukan, untuk dapat membuktikan asumsi Anda benar. Lain perpustakaan harus secara eksplisit mengurus hal ini, misalnya melempar pengecualian ketika buffer output yang disediakan tidak cukup besar.

Boleh-boleh saja tidak mengerti semua yang Anda gunakan selama Anda yakin itu berhasil. Setelah Anda digigit oleh bug di lib maka ada waktu untuk melihat cara kerjanya, mengapa ia bekerja dan mengapa tidak. Tentu saja Anda selalu disambut dan didorong untuk mencari di bawah tenda bahkan jika Anda tidak perlu.

Salah satu hal sulit dalam pemrograman adalah mengatasi godaan untuk menyelesaikan semua masalah sendiri.

Tidak apa-apa tapi berbahaya. Sebagai praktik umum, orang harus tahu bekerja dari apa yang telah dikembangkannya.

Agak...

Tidak masalah selama Anda mendapatkan inti umum dari apa yang coba dilakukan oleh perpustakaan atau kerangka kerja. Adapun bagian internal dan apa yang tidak, tidak. Ambil pendekatan pragmatis. Berhasil, itu melakukan apa yang saya inginkan, oke.

Intinya adalah untuk tidak boggle down dengan banyak detail kecil dan hanya menerapkan ide sialan Anda.

Saya kira, intinya adalah, Anda tidak akan tahu segalanya. Serius, Anda hanya punya sedikit waktu untuk menyelidiki semuanya, karena itu akan mengalihkan Anda dari tujuan utama Anda untuk menciptakan ide Anda. Sedikit demi sedikit, mungkin, Anda dapat mengatur waktu luang di akhir pekan untuk membaca satu bab atau lebih pada subjek.

Tapi jangan mencoba untuk mencari tahu semuanya, kecuali jika Anda memiliki banyak waktu luang ... Lihatlah dengan cara ini. Alasan untuk bahasa pemrograman adalah perisai kami dari melakukan kode rakitan, alasan untuk kode rakitan adalah untuk melindungi kami dari melakukan angka 1 dan 0. Saya tidak berpikir Anda perlu tahu setiap detail yang baik tentang mekanisme di baliknya, tetapi hanya tahu intinya. Seperti seorang pengumpul sampah, saya tahu itu akan berurusan dengan pointer / memori saya, saya tidak peduli apa pun algoritma rapi yang digunakannya, saya hanya tahu itu berfungsi (untuk apa yang saya butuhkan) dan tidak melakukan hal lain. Mungkin menipu tapi meh. Kecuali tentu saja Anda berada di bidang di mana Anda harus menghadapinya. Maka Anda tidak akan menanyakan pertanyaan ini karena itu bagian dari pekerjaan Anda haha.