Apa itu Metafora Pemrograman yang bagus? [Tutup]

Saya mengacu pada menjelaskan kepada non-programmer apa pemrograman itu. Saya memastikan untuk mencari pertanyaan yang sama sebelum membuat yang ini, tetapi beberapa yang saya temukan tampaknya menghindari pertanyaan, dan saya secara khusus ingin melihat beberapa metafora atau analogi. Saya pribadi merasa lebih mudah untuk menjelaskan sesuatu yang teknis kepada seseorang melalui penggunaan metafora atau analogi.

Alasan saya tertarik pada ini adalah karena banyak orang menemukan pekerjaan seorang programmer setiap hari, tetapi jika Anda bertanya kepada orang kebanyakan apa seorang programmer itu atau tidak, mereka tidak benar-benar tahu. Ini mengarah pada situasi kesalahpahaman tertentu (mis. "[...] tapi saya pikir Anda pandai menggunakan komputer!")

Saya benar-benar ingin menemukan yang terbaik di luar sana. Saya ingin dapat dengan mudah menjelaskan kepada seseorang tentang pilihan karier saya. Tentu saja, paling tidak gagasan umum.

Saya pribadi tidak memiliki yang solid, tapi saya sudah lama memikirkannya dan saya biasanya tertarik pada metafora 'bahasa', di mana kita kebetulan mengetahui bahasa yang dimengerti komputer, dan oleh karena itu kami dapat memberi tahu komputer apa yang harus dilakukan. lakukan, atau "ajarkan" mereka, untuk menyelesaikan masalah kita.

Sebagai contoh:

Bayangkan bahwa dalam realitas alternatif, robot humanoid dengan kecerdasan buatan ada, dan beberapa orang dapat berkomunikasi dengan mereka melalui bahasa yang sama, yang merupakan variasi bahasa Inggris. Orang-orang ini yang dapat berkomunikasi dengan robot dapat mengajari mereka cara menyelesaikan masalah tertentu atau melakukan tugas tertentu, seperti melakukan tugas kami.

Yah, meskipun robot seperti itu belum ada, pemrogram pada zaman kita seperti orang-orang itu, tetapi alih-alih berkomunikasi dengan robot, mereka berkomunikasi dengan komputer. Pemrogram "mengajarkan" komputer bagaimana melakukan tugas-tugas tertentu atau memecahkan masalah tertentu dengan menggunakan perangkat lunak yang mereka buat dengan menggunakan "bahasa umum" ini.

Pemrogram dan "bahasa umum" ini adalah yang memberi kami hal-hal seperti email, situs web, video game, pengolah kata, ponsel pintar ( untuk membuatnya lebih sederhana ), dan banyak hal lain yang kami gunakan setiap hari.

Saya tidak bermaksud menempatkan pemrograman di atas takhta atau apa pun, itu hanya metafora terbaik yang bisa saya buat.

Saya yakin seseorang akan menemukan beberapa masalah dengan ini, mungkin agak dibuat-buat, tapi sekali lagi itu sebabnya saya menanyakan pertanyaan ini.

Ini seperti harus menulis petunjuk langkah demi langkah terperinci untuk cara mengemudi di suatu tempat. Tetapi Anda biasanya harus menambahkan rencana darurat untuk hal-hal seperti 'bagaimana jika ada kemacetan lalu lintas', atau 'bagaimana jika sebuah truk mogok di jalur belokan'.

Dan kadang-kadang Anda harus menyelam lebih dalam dan menjelaskan aturan jalan seperti sisi mana untuk mengemudi atau apa yang harus dilakukan pada lampu merah. Dan terkadang Anda bahkan perlu menjelaskan dengan tepat bagaimana setir atau pedal gas bekerja.

Dan biasanya, setelah Anda mendapatkan semua yang dijelaskan dalam detail yang pasti, pelanggan mengatakan "itu sempurna, kecuali itu harus bekerja untuk seseorang yang mengendarai hovercraft"

Saya menulis instruksi yang sangat, sangat rinci untuk mesin yang sangat, sangat bodoh.

Saya menggunakan metafora "Kami menulis resep rajutan " yang ramah nenek.

Alasan:

• Merajut adalah proses mekanis yang cukup sederhana di mana pada dasarnya Anda harus mengikuti instruksi terperinci dengan tepat untuk mendapatkan sesuatu darinya.
• Sebagian besar instruksi rajutan untuk berbagai ukuran. Ini memberi Anda ifpernyataan-dan matematika dan loop.
• Anda bisa menemukan kesalahan dalam resep ketika tentara nenek yang marah datang dengan sweater kereta mereka!

Analogi ini tidak terlalu bagus, tetapi ketika orang-orang mengatakan kepada saya untuk memperbaiki mesin mereka, saya berkata, "Saya adalah orang yang mendesain mobil. Saya bukan mekanik!"

Sebagai seorang anak, saya membaca deskripsi pemrograman yang sangat bagus: seperti memberi tahu robot cara melakukan tugas sehari-hari yang umum, seperti pergi ke sekolah. Jadi Anda bisa mengatakannya kepada "Pergi ke sekolah!", Tetapi tidak tahu caranya. Jadi Anda menyuruhnya "pergi ke luar, belok kiri, terus berjalan sampai Anda datang ke sekolah, ambil belok kiri, masuk, dan duduk". Tapi ada jalan di sana! Jadi Anda harus mengatakannya untuk "berhenti di jalan, periksa bahwa tidak ada lalu lintas, menyeberang jalan, dan terus berjalan" di suatu tempat di tengah sana. Dan bagaimana dengan pintu? Jadi Anda menambahkan "periksa apakah pintu sekolah terbuka. Jika tidak, buka saja." di sana. Akhirnya, Anda memiliki program yang dapat memberi tahu robot Anda bagaimana menuju ke sekolah dengan sendirinya.

Ini pas dengan Logo, di mana Anda menginstruksikan kura-kura dengan cara ini untuk membuat bentuk yang rumit.

Pemrograman seperti sekotak coklat . Kadang-kadang Anda menemukan apa yang Anda cari segera, tetapi sebagian besar waktu dibutuhkan banyak trial and error. Terkadang Anda mendapatkan kelapa.

Lampu lalu lintas . Mobil bisa bergerak atau berhenti. Satu lampu lalu lintas mudah dibayangkan diatur, tetapi apa yang terjadi jika Anda menambahkan yang lain? Bagaimana kalau sepertiga? Bagaimana dengan seluruh kota? Sistem transit terdiri dari ribuan lampu berhenti, masing-masingnya sederhana dengan sendirinya, tetapi ketika diambil secara keseluruhan, itu menjadi sistem yang kompleks. Jika salah satu lampu lalu lintas rusak atau mati hanya dalam beberapa detik, itu akan membuat seluruh sistem kacau. Jika semuanya tersinkronisasi, Anda cukup menikmati perjalanan.

Seorang pembicara motivasi menemukan kunci untuk membuka teka-teki motivasi, impian, dan ide orang. Setiap situasi, setiap orang berbeda. Apa yang berhasil di masa lalu mungkin tidak sesuai sekarang. Terkadang kunci dapat digunakan kembali, tetapi perlu disesuaikan dengan individu. Di lain waktu, kuncinya harus dibuat lagi. Apa yang paling bermanfaat adalah ketika orang itu telah dibuka dan Anda melihat mereka keluar dan menaklukkan dunia. Yang paling menghancurkan adalah ketika Anda merasa dekat, tetapi tidak mampu membuka potensi.

Sebuah cerita detektif , di mana detektif perlahan membangun kasusnya dengan mencari petunjuk dan mengumpulkan bukti. Metodis, cerdas, dan akurat akan memenangkan hari. Ceroboh, bodoh, dan malas akan menemui ajalnya. Akhirnya, pekerjaan itu akan berdiri atau jatuh di hadapan juri rekan-rekan.

Sebuah mesin slot . Anda memasukkan semua koin Anda dan menarik tuasnya. Terkadang Anda menang besar, terkadang Anda duduk di sana berjam-jam dan tidak ada yang terjadi. Terkadang orang lain berjalan begitu saja, menarik tuas sekali, dan memenangkan jackpot.

Musik . Satu nada cukup sederhana, tetapi ukurannya lebih kompleks. Lagu yang lengkap memiliki banyak ukuran dengan banyak catatan. Jika satu nada mati, itu dapat merusak seluruh kinerja. Jika setiap not disampaikan dengan sempurna, kinerja memudar ke latar belakang dan hanya musik yang ada.

Metafora terbaik untuk apa pun adalah dirinya sendiri. Apa pun yang berbeda akan kehilangan akurasi. Dengan demikian, memilih metafora terbaik tergantung pada apa, khususnya, yang ingin Anda tangkap tentang pemrograman. Karena akan ada banyak jawaban yang diberikan di sini tentang pengkodean metafora, saya akan menjawab dengan metafora klasik untuk proses pengembangan secara keseluruhan:

Konstruksi bangunan

Aspek paling umum dari metafora ini adalah bahwa seorang arsitek fisik agak analog dengan seorang arsitek perangkat lunak. Berikut adalah beberapa persamaan lainnya:

• Perubahan lebih murah dan lebih murah semakin awal Anda membuatnya. Artinya, Anda bisa memindahkan satu baris di atas kertas sekarang atau 10 ton semen nanti.
• Sebuah bangunan tanpa rencana yang tepat akan cenderung runtuh
• Pembangun berusaha mengimplementasikan apa yang diinginkan klien. Jika klien tidak secara akurat menggambarkan seperti apa bangunan itu (atau ada beberapa kegagalan dalam komunikasi), itu akan mahal untuk diubah.
• Ada hukum fisika tertentu yang tidak bisa dibengkokkan. Sama seperti cerita 2 selebar tiga ratus kaki tidak dapat dibangun di atas cerita 1 selebar 100 kaki, fitur X tidak dapat dibangun tanpa subsistem yang kuat Y.

Tentu saja, seperti metafora apa pun, ia memiliki keterbatasan. Beberapa kekurangan dengannya:

• Bangunan digunakan 1 kali; Anda membangunnya di suatu tempat, dan di sana ia tinggal. Anda tidak dapat menyalinnya satu juta kali untuk satu juta pengguna yang berbeda dengan satu juta kebutuhan yang berbeda tanpa biaya tambahan.
• Bangunan jauh lebih abadi daripada perangkat lunak.
• Tidak ada analogi yang jelas dengan biaya bahan bangunan. Baris kode tidak memerlukan biaya apa pun - hanya waktu yang diperlukan untuk memproduksinya biaya uang.
• Arsitektur tambahan yang (tergantung pada siapa yang Anda tanya) mungkin dengan perangkat lunak tidak mungkin dengan konstruksi, di mana Anda mendesainnya sekali, lalu membangunnya.

Jadi, seperti analogi apa pun, itu tergantung pada apa yang Anda coba jelaskan. Berhati-hatilah untuk terlalu mengandalkan satu metafora, atau pelanggan Anda akan mulai bertanya-tanya apa pajak properti pada sistem penggajian barunya.

Saya suka analogi Chris McMahon tentang pengembangan perangkat lunak seperti penciptaan musik, khususnya musik jazz.

Ini adalah Ella Fitzgerald dan Count Basie yang melakukan lagu One O'Clock Jump. Lagu ini adalah blues dua belas bar, yang setara dengan aplikasi database dengan UI. Maksud saya: sama seperti setiap programmer telah membangun aplikasi database dengan UI, setiap musisi Amerika telah memainkan dua belas bar blues. Ini adalah kerangka kerja di mana banyak banyak lagu digantung, dari Count Basie ke Jimi Hendrix ke Ramones.

Video khusus ini adalah contoh yang bagus dari latihan tangkas. Dengarkan bagaimana suara dan piano saling memengaruhi. Ini sangat mirip pemrograman pasangan, dan ini sangat mirip dengan TDD: suara melakukan sesuatu; piano merespons; piano melakukan sesuatu; suara merespon. Dan perhatikan kontak mata. Orang-orang ini sangat sadar akan apa yang terjadi dari waktu ke waktu. Mereka tidak memiliki lembaran musik (BDUF). Mereka terlibat dalam aktivitas yang membutuhkan konsentrasi dan keterampilan yang kuat, seperti halnya pengembangan perangkat lunak yang baik. Mereka juga jelas menyadari bahwa ada audiensi, seperti halnya pengembangan perangkat lunak yang baik harus menyadari kebutuhan orang-orang yang membayar tagihan.

Berikut tautan ke pos blog tempat ia membahasnya: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

Kadang-kadang saya menyebut pemrograman untuk mengendalikan zombie yang tidak berpikir . Ringkas posting blog saya tentang hal itu:

• Seperti zombie, komputer yang kami operasikan sangat bodoh. Sulit untuk memerintahkan mereka melakukan apa pun kecuali instruksinya terperinci
• Zombie itu agresif dan jika kita melewatkan detail kecil dalam instruksi, membiarkan makhluk itu tidak tertangani, ia dapat menghancurkan segalanya di sekitar dirinya. Sama halnya dengan komputer: kurangnya detail dalam instruksi dapat membuat program Anda macet dan menghancurkan data Anda.
• Anda harus tahu sihir jika Anda ingin mengendalikan zombie. Sama dengan pemrograman.
• Semakin banyak orang dengan otak berkumpul di satu tempat, semakin banyak komputer yang mereka miliki. Tampaknya otak menarik komputer - cara yang sama mereka menarik zombie.

Pemrograman seperti membangun sesuatu dengan Lego :

• Anda menempelkan banyak potongan kecil untuk membuat hal yang lebih besar
• Potongan kecil datang dalam jumlah terbatas pada bentuk dan ukuran
• Hal-hal kecil hanya dapat disatukan dalam cara-cara tertentu
• Bermain dengan barang-barang ini bisa sangat menyenangkan

Memprogram komputer seperti membesarkan anak ...

• Semua orang tidak setuju tentang cara yang benar untuk melakukannya
• Itu membuat Anda terjaga di malam hari
• Tidak pernah melakukan apa yang Anda katakan
• Tidak peduli berapa banyak buku yang Anda baca tentang topik tersebut, ketika Anda melakukannya, Anda merasa seperti tidak tahu apa yang sedang Anda lakukan
• Setelah beberapa saat Anda cenderung malas
• Anda mengharapkannya memiliki pengembalian besar di masa depan tetapi Anda akhirnya harus mempertahankannya sampai akhir hayatnya
• Tidak pernah sebersih, sepintar, atau seaman yang Anda inginkan
• Ketika Anda melihat kembali nanti, Anda bertanya-tanya apa sih yang Anda pikirkan
• Terlepas dari semua stres yang disebabkan Anda, Anda tetap menyukainya.

Perbedaan utama adalah bahwa kita menjadi kesal jika seseorang mencuri kode sumber kita, tetapi kita sering senang seseorang mengambil anak-anak kita dari tangan kita.

Pemrograman seperti membangun pabrik atau jalur perakitan.

Pikirkan perangkat lunak sebagai mesin atau jalur perakitan yang ada di dalam komputer. Beberapa bahan baku dan komponen dimasukkan ke dalam mesin, dan mengikuti serangkaian prosedur untuk memprosesnya menjadi beberapa produk akhir. Prosedur diatur untuk melakukan operasi tertentu pada beberapa bahan mentah atau komponen ke serangkaian parameter tertentu (misalnya, waktu, suhu, jarak, dll) dalam urutan tertentu. Jika detail operasi yang akan dilakukan salah, atau sensor mesin tidak dikalibrasi dengan benar, atau jika beberapa bahan baku atau komponen tidak sesuai dengan standar kualitas yang diharapkan, itu dapat mengubah hasil operasi dan produk tidak akan berubah seperti yang diharapkan.

Mesin seperti itu sangat kaku dalam operasinya dan input yang dapat diterima. Mesin tidak mempertanyakan kecerdasan desainer atau lingkungan operasinya saat ini. Itu akan terus mengikuti prosedur selama itu diarahkan. Bahkan jika perubahan bahan baku atau komponen dapat memiliki efek drastis pada apa yang terjadi pada operasi selanjutnya, mesin akan tetap melakukan prosedurnya. Proses ini perlu ditinjau untuk melihat perubahan apa pada prosedur yang diperlukan untuk mengkompensasi dan menghasilkan hasil yang diinginkan. Perubahan pada desain atau konfigurasi produk mungkin juga memerlukan perubahan signifikan pada operasi yang dilakukan atau pesanan mereka. Meskipun mereka yang bertanggung jawab atas produksi dengan cepat mempelajari pentingnya mengisolasi operasi sebanyak mungkin untuk mengurangi efek yang tidak diinginkan di antara mereka, banyak asumsi dibuat dari komponen kondisi saat mereka menjalani pemrosesan; asumsi yang mungkin tidak terdeteksi hingga produk akhir ada di tangan pengguna di beberapa lingkungan operasi yang berbeda.

Membantu seorang idiot cepat lulus kelas matematika yang membutuhkan esai tertulis.

Pemrograman komputer seperti bermain permainan catur di mana ukuran papan, jumlah potongan dalam permainan dan aturan yang mengatur potongan-potongan itu tumbuh dalam ukuran dan kompleksitas saat permainan berlangsung.

Software Menulis Seperti ... Menulis! ^^

Siswa baru ke kelas CS / Pemrograman, praktis, seperti pengguna non-pemrograman. Contoh robot itu bagus.

Kembali, di tahun 80-an, menggunakan Logo, Karel, (atau lingkungan pemrograman serupa), di mana pengguna belajar memprogram, menonton komputer seperti robot, sebagai gantinya, satu set TV dengan mesin tik, banyak membantu. Alat-alat itu biasa digunakan di SMP dan SMA.

Pemrograman praktis itu membantu para siswa untuk meminta keterampilan pemecahan masalah, bahkan jika itu tidak berhubungan dengan komputer !!!

Atau, bahkan jika siswa tidak menjadi programmer.

Beberapa Collegues dan Universitas juga menerapkan alat-alat itu dalam kursus tahun pertama.

Saya heran mengapa banyak sekolah menengah menjatuhkan Logo dan Karel ...

Saya suka analogi Fred Brooks, dari Mythical Man-Month, bahwa pemrograman itu seperti sulap.

Konstruk (()) program, tidak seperti kata-kata penyair, nyata dalam arti bahwa ia bergerak dan bekerja, menghasilkan output yang terlihat terpisah dari konstruk itu sendiri. Mencetak hasil, menggambar, menghasilkan suara, menggerakkan lengan. Keajaiban mitos dan legenda telah menjadi kenyataan di zaman kita. Satu mengetik mantra yang benar pada keyboard, dan tampilan layar menjadi hidup, menunjukkan hal-hal yang tidak pernah ada atau tidak mungkin terjadi. ...

(Satu) harus melakukan dengan benar. Komputer menyerupai keajaiban mitos dan legenda dalam hal ini juga. Jika satu karakter, satu jeda mantera tidak sepenuhnya dalam bentuk yang tepat, sihir tidak berfungsi. Manusia tidak terbiasa menjadi sempurna, dan beberapa bidang aktivitas manusia menuntutnya. Menyesuaikan dengan persyaratan untuk kesempurnaan, menurut saya, adalah bagian yang paling sulit dari belajar memprogram.

"[...] tapi kupikir kamu bagus dengan komputer!"

Ini biasanya merupakan upaya untuk menipu geek agar memperbaiki komputer (Anda merasa ingin membuktikan bahwa mereka salah?). Jawaban standar saya:
Saya seorang programmer. Itu seperti seorang insinyur mobil - dia mungkin tidak akan tahu cara memperbaiki rem Trabant Anda, 72 dan tentu saja tidak akan melakukannya jika dia tahu. Seorang mekanik akan melakukan itu!

Saya menyukai konsep resep untuk memasak.

Pemrograman seperti memegang kekuatan dalam jumlah besar. Anda dapat membuat komputer melakukan apa pun yang Anda inginkan. Anda hanya dibatasi oleh imajinasi Anda dan jumlah waktu yang ingin Anda investasikan.

Programmer seperti pembuat rumah. Kami dapat memberi tahu Anda segalanya tentang rumah yang telah kami buat. Namun, jika Anda bertanya kepada kami bertanya pada rumah acak kami kebetulan lewat di jalan, kemungkinan kita mungkin tidak akan tahu banyak tentang. Tetapi jika Anda membutuhkan sesuatu yang ditambahkan atau diubah pada rumah itu, kami dapat mewujudkannya asalkan pemiliknya mengizinkan kami.

Dalam salah satu artikel lama Chris Crawford tentang pemrograman, ia menyamakan program yang rumit dengan birokrasi, dengan banyak agensi yang berkomunikasi dengan memberikan memo bolak-balik. Saya telah menemukan bahwa menjadi metafora yang sangat berguna ketika menjelaskan pengembangan perangkat lunak.

Saya biasanya menyamakan pemrograman dengan puzzle.

Untuk membuat proyek baru - Anda memiliki banyak bagian, beberapa di antaranya bukan milik gambar ini, dan Anda tidak memiliki pratinjau seperti apa bentuk puzzle ketika itu selesai. Tapi Anda tahu ukuran dan warna umum, jadi perkiraan mungkin, tetapi belum tentu akurat.

Untuk memodifikasi proyek yang sudah ada - kucing datang dan menjatuhkan sebagian dari teka-teki yang sudah selesai. Ini akan memakan waktu, tetapi kerangka sudah ada di sana, jadi seharusnya tidak terlalu buruk (tergantung pada seberapa banyak yang perlu diubah).

Ini juga membantu untuk menggambarkan kemajuan. Salah satu proyek terakhir saya, pada satu titik saya bertanya-tanya bagaimana menggambarkannya sehingga orang non-teknis akan mengerti mengapa saya tidak tahu berapa lama lagi, dan saya datang dengan: Pikirkan teka-teki jigsaw di mana semua potongan perbatasan dilakukan, seperti juga sedikit lebih dari setengah bagian batin. Yang tersisa terpisah satu sama lain, yang harus saya lakukan sekarang adalah mengisi kekosongan.

Menyedihkan, tetapi pemrograman adalah pekerjaan yang hanya dapat dipahami dengan mempelajari cara melakukannya.

Pemrograman memiliki beberapa tingkat persepsi dan berbeda dari sisi yang berbeda.

Pada level rendah adalah "tulis instruksi yang sangat, sangat rinci untuk mesin yang sangat, sangat bodoh"

Pada level selanjutnya ia berurusan dengan kompleksitas. Membangun metafora baru untuk mempermudah pekerjaan. Seperti matematika yang lebih tinggi.

Dari sisi yang berbeda penggunaan teknologi tambahan seperti kontrol versi, kode yang didokumentasikan sendiri, pembangunan proyek dan pengujian.

Dari sisi lain membangun "pengguna" antarmuka (tidak secara harfiah, maksudku API juga UI), memprediksi kemungkinan kesalahan (dilakukan oleh pengguna, data atau bahkan sendiri) dan benar bereaksi terhadap kesalahan.

Dan akhirnya.

Metafora untuk pemrograman adalah literatur. Pertama-tama perlu mempelajari alfabet. Tetapi menulis novel di ini bahkan tidak dimulai.